Subject: Re: ps /proc changes (CVS commit: src)
To: Bernd Ernesti <>
From: Brian C. Grayson <>
List: tech-userlevel
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
method only.