Re: [PATCH][RFC] Make /proc/<pid> chmod'able
From: Bodo Eggert
Date: Tue Mar 15 2005 - 16:06:50 EST
(refiled the CC list)
On Tue, 15 Mar 2005, Albert Cahalan wrote:
> On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
> > On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > > On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
> > > > On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > > This really isn't about security.
> > Information leakage is a security aspect.
> If you will go to such extremes, Linux is poorly suited.
> A user can detect activity on the computer by examining
> the performance of their own activity.
Way to go, better start walking.
> > > Privacy may be undesirable.
> > May. That's why I suggested the min/max sysctl.
> > > With privacy comes anti-social behavior.
> > With anti-social behavior comes the admin and his LART.
> > BTW: If the users want to be anti-social, they'll just rename setiathome
> > to something like -bash or soffice.
> This does not matter: "Rene, your soffice program is eating
> too much CPU time. Find some other place to run it."
That's ok for _some_ environments.
> > > Supposing that the
> > > users do get privacy, perhaps because the have paid for it:
> > Vservers,
> > > Xen, UML, VM, VMware, separate computers
> > >
> > > Going with separate computers is best.
> > If you like wasting space and energy. If the user's demands don't exceed
> > one percent of a historic PC, there is no point in buying more hardware.
> Sure there is:
> a. info leakage (way more than just /proc)
> b. admin control
> c. budget control
> d. downtime hits fewer users
no central administration, higher expenses.
The battle has ben fought since the early days, and there is still no
> > > Don't forget to use
> > > network traffic control to keep users from being able to
> > > detect the network activity of other users.
> > Like that:?
> > $ netstat
> > Active Internet connections (w/o servers)
> > Proto Recv-Q Send-Q Local Address Foreign Address State
> > /proc/net/tcp: Permission denied
> Nope. If you really care about information leakage, you'll
> be concerned about the ability to detect network congestion.
Those who should be are able to see the network usage.
On the other hand, the privileged user might open and close ports to
signal information to less privileged users.
> Hey, if you're going to be paranoid about %CPU and %MEM, you
> have to be paranoid about %NET too. This requires traffic
> control unless you have separate networks.
Traffic shaping is available.
> > > > > Users who want privacy can get their
> > > > > own computer. So, these need to work:
> > > > >
> > > > > ps [...]
> > > > > w
> > > > > top
> > > >
> > > > Works as intended. Only pstree breaks, if init isn't visible.
> > >
> > > They work like they do with a rootkit installed.
> > > Traditional behavior has been broken.
> > They are as broken as finger or ls are if the home directory is chmodded.
> Probably something should be done to deal with the problem of
> a chmodded home directory. It's not ls that matters though.
> It's du that matters. On a normal shared system, a user should
> be able to see where all the disk blocks and inodes are going.
> Filenames need not be visible. Then: "Rene, you're being kind
> of greedy about the disk space aren't you? You're using 666 GB."
That's what quota is for.
If at first you don't succeed call in an air-strike.
Friß, Spammer: consequently@xxxxxxxxxxxxxxx lXBimztfVI8w@xxxxxxxxxxxx
jJb@xxxxxxxxxx jGgn@xxxxxxxxxxxxxxxxxxxxxxxx admin@xxxxxxxxxxxxxxx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/