Subject: Re: ps /proc changes (CVS commit: src)
To: Bernd Ernesti <firstname.lastname@example.org>
From: Brian C. Grayson <email@example.com>
Date: 03/27/1999 10:51:51
On Sat, Mar 27, 1999 at 10:44:19AM +0100, Bernd Ernesti wrote:
> I think that is not enough. You have to check that /proc is an procfs.
> It is just to easy to fake processes for an intruder without replacing ps.
How about a getmntinfo() call, followed by a check that:
a) a "procfs" is mounted on /proc
b) nothing else has a mount point beginning with /proc.
Can we be any more sure than that? I'm not an FS guru or even
FS knowledgeable, and I haven't tried these out, but aren't
these security holes:
1. If an intruder has write access to /dev/kmem, they could fake
a type string by changing it to procfs after, say an FFS
was mounted on /proc.
2. Or they could add another entry to vfs_list that does
FFS, but with the vfs_name of procfs, (and change the
existing "procfs" entry to "procfs_die") and then mount an
FFS filesystem with the type string "procfs", that
appears to the kernel to be a "procfs" on the surface.
It _appears_ to me (now -- thanks for pointing this out!) that
/kern and /proc are inherently insecure, no matter what you do.
sysctl is the One True Way, unfortunately. :)
> There is no way to disable the /proc search when there is a problem between
> the ps binary and the kernel.
Okay, I'll add an option for that: -K, for do KVM-based