On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote: > On Mon, 14 Mar 2005, Albert Cahalan wrote: > > On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote: > > > Albert Cahalan wrote: > > > > 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. > > NACK, the admin (and with the new inherited capabilities all users with > cap_???_override) can see all processes. Only users who don't need to know > won't see the other user's processes.
Capabilities are too broken for most people to use. Normal users do not get CAP_DAC_OVERRIDE by default anyway, for good reason. > > Note that the admin hopefully does not normally run as root. > > su1 and sudo exist. This is a pain. Now every user will need sudo access, and the sudoers file will have to disable requesting passwords so that scripts will work without hassle. > > 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. > > Privacy is important, too. Imagine each user can see the CEO (or the > admin) executing "ee nakedgirl.jpg". Obviously, he likes to have users see him do this. He'd use a private machine if he wanted privacy. > > > > 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. > > I used unpatched procps 3.1.11, and it worked for me, except pstree. It does not work correctly. Look, patches with this "feature" are called rootkits. Think of the headlines: "Linux now with built-in rootkit". > > > 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. > > e.g. the buffer overflow in sendmail? Or all the open relays? :) > > The demands to security and privacy have increased. Linux should be able > to provide the requested privacy. This really isn't about security. Privacy may be undesirable. With privacy comes anti-social behavior. Supposing that the users do get privacy, perhaps because the have paid for it: Xen, UML, VM, VMware, separate computers Going with separate computers is best. Don't forget to use network traffic control to keep users from being able to detect the network activity of other users. > > 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 > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
