Subject: Re: [PATCH][RFC] Make /proc/<pid> chmod'able
From: Albert Cahalan <albert@users.sf.net>
To: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>,
       Andrew Morton OSDL <akpm@osdl.org>,
       viro@parcelfarce.linux.theplanet.co.uk, pj@engr.sgi.com, 7eggert@gmx.de
In-Reply-To: <42355C78.1020307@lsrfire.ath.cx>
References: <1110771251.1967.84.camel@cube>
	 <42355C78.1020307@lsrfire.ath.cx>
Content-Type: text/plain
Date: Mon, 14 Mar 2005 11:13:23 -0500
Message-Id: <1110816803.1949.177.camel@cube>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3182
Lines: 85

On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
> Albert Cahalan wrote:
> > This is a bad idea. Users should not be allowed to
> > make this decision. This is rightly a decision for
> > the admin to make.
> 
> Why do you think users should not be allowed to chmod their processes' 
> /proc directories?  Isn't it similar to being able to chmod their home 
> directories?  They own both objects, after all (both conceptually and as 
> attributed in the filesystem).

This is, to use your own word, "cloaking". This would let
a bad user or even an unauthorized user hide from the admin.
Why should someone be able to hide a suspicious CPU hog?
Maybe they are cracking passwords or selling your CPU time.

Note that the admin hopefully does not normally run as root.
The admin should be using a normal user account most of the
time, to reduce the damage caused by his accidents.

Even if the admin were not running as a normal user, it is
expected that normal users can keep tabs on each other.
The admin may be sleeping. Social pressure is important to
prevent one user from sucking up all the memory and CPU time.

> > Note: I'm the procps (ps, top, w, etc.) maintainer.
> > 
> > Probably I'd have to make /bin/ps run setuid root
> > to deal with this. (minor changes needed) The same
> > goes for /usr/bin/top, which I know is currently
> > unsafe and difficult to fix.
> > 
> > Let's not go there, OK?
> 
> I have to admit to not having done any real testing with those 
> utilities.  My excuse is this isn't such a new feature, Openwall had 
> something similar for at least four years now and GrSecurity contains 
> yet another flavour of it.  Openwall also provides one patch for 
> procps-2.0.6, so I figured that problem (whatever their patch is about) 
> got fixed in later versions.

If I haven't seen that patch, to Hell with 'em.

It appears that Openwall is using procps-2.0.7 now. Oooh, they've
upgraded to something that's only 4.5 years old! Anybody using a
4-year-old procps is uninterested in security.

> Why do ps and top need to be setuid root to deal with a resticted /proc? 
>     What information in /proc/<pid> needs to be available to any and all 
> users?

Anything provided by traditional UNIX and BSD systems
should be available. Users who want privacy can get their
own computer. So, these need to work:

ps -ef
ps -el
ps -ej
ps axu
ps axl
ps axj
ps axv
w
top

Note that /proc does provide a bit more info than required.
This could be changed; it requires new /proc files or a
non-proc source of data.

> > If you restricted this new ability to root, then I'd
> > have much less of an objection. (not that I'd like it)
> 
> How about a boot parameter or sysctl to enable the chmod'ability of 
> /proc/<pid>, defaulting to off?  But I'd like to resolve your more 
> general objections above first, if possible. :)

This at least avoids breaking the traditional ability of
non-root users to spot abuse.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/