Re: [PATCH][RFC] Make /proc/pid chmod'able
Xen, UML, VM, VMware, separate computers http://linux-vserver.org/ would also seem to be an excellent match. - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
(snipped the CC list - hope that's ok)
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:
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
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.
That's being fixed, the new semantics will allow a wrapper.
Note that the admin hopefully does not normally run as root.
su1 and sudo exist.
This is a pain.
mv ps ps.bin # -+ or just ln -s /usr/bin/us1 ~admin/bin/ps instead
ln -s su1 ps # /
echo $'\nask never\nalias ps /bin/ps\nallow admin prefix ps' /etc/su1.priv
# ore use * instead of admin, if all users are supposed to see everyone.
Or use the sysctl I described. It won't hurt more than the originally
suggested flag, and it's much more powerfull.
Now every user will need sudo access,
and the sudoers file will have to disable requesting
passwords so that scripts will work without hassle.
Is sudo _that_ bad? Seems it was a good decision to avoid sudo.
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.
UNIX and linux are supposed to be a multi-user-systems unlike Win98.
Information leakage is usurally considered {\HUGE BAD}, and some security
models demand closing all information leakages from privileged users to
less privileged users. Restricted proc is one more step towards secure
systems, unless you're depending on peer review.
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.
Using another PC will hide the processes. Therefore using another PC is
like using a rootkit. NOT.
Maybe you'll want to print a note about inaccessible proc entries, but
that's a different issue.
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.
Information leakage is a security aspect.
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.
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.
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
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.
--
Top 100 things you don't want the sysadmin to say:
13. Ooohh, lovely, it runs SVR4
-
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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
Albert Cahalan wrote: 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. Openwall and GrSecurity solved this by having a special group that can see everything, just like root. E.g. we could add a proc.gid kernel boot option for that purpose. 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. IANAL, but creating a user profile (who ran what when, used how many resources etc.) without the user's consent is illegal at least here in Germany. As an admin I'd like to be able to prevent a user from even trying to spy on another user. 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 If with work you mean show info about all users then the patch becomes pointless. The programs work in the sense that they do *not* should cloaked processes, which is intended. :) OK, I understand that you need to be able to turn this feature off and I also don't want non-root admins to suddenly go blind. Would adding a proc.gid kernel parameter and an off-switch be sufficient for you? Thanks, Rene - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
(snipped the CC list - hope that's ok) No - it's not ok. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote: (snipped the CC list - hope that's ok) 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. 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. 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 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. Example #1 A spy sends packets from time to time. He measures the delay and packet loss to determine if the network is busy. When the network suddenly becomes busy, he can guess that you have started some operation that requires heavy network traffic. Example #2 A spy sends packets from time to time. He measures the delay and packet loss to determine if the network is busy. Over time, he learns when workers are busy. From this he can determine an appropriate time to sneak into your building. 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. Assign a fixed portion of bandwidth to any user that you wish to hide info from. Be sure to consider latency as well. 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. - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
(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) selinux, rsbac,. 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 winner. 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. [examples] 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: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
Albert Cahalan wrote: This really isn't about security. Privacy may be undesirable. I agree, privacy is not security. My patch tries to enhance privacy without giving up security. You think losing the social pressure that comes with mutual surveillance results in loss of security, I don't. Now I think Linux should support both ways and those writing security policies should make the decision. 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. That would work, but it requires a *lot* of administrative and computing overhead. Note that separate computers alone is not sufficient because most places with more than a few machines have some kind of single signon and run SSH or similar. [ps, w, top] They work like they do with a rootkit installed. Traditional behavior has been broken. That's one way to put it; you could also say those tools now provide enhanced privacy. ;) I also think things have changed in the last few years. Since the advent of special data processing laws privacy is taken more serious. Privacy certainly was no real concern when UNIX was young. I also guess it's a cultural thing, its importance being different from country to country. It's easily visible in the style of public toilets: in some contries you have one big room with no walls in between where all men or women merrily shit together, in other countries (like mine) every person can lock himself into a private closet. Both ways work, there's nothing too special about using a toilet, but I'm simply used to the privacy provided by those thin walls. I assure you, I don't do anything evil in there. :] - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
On Mar 15, 2005, at 16:18, Rene Scharfe wrote: It's easily visible in the style of public toilets: in some contries you have one big room with no walls in between where all men or women merrily shit together, in other countries (like mine) every person can lock himself into a private closet. Both ways work, there's nothing too special about using a toilet, but I'm simply used to the privacy provided by those thin walls. I assure you, I don't do anything evil in there. :] Just as long as our labs bathrooms don't mysteriously get a bazillion walls all over the place on kernel upgrade, we're ok. I don't mind adding new options for advanced security, as long as you don't change the defaults. It's hard enough managing a boatload of workstations under ideal conditions. When the default settings change every month it gets really annoying really quickly. :-D. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r !y?(-) --END GEEK CODE BLOCK-- - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
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). 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. 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? 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. :) Thanks for your comments, Rene - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] Make /proc/pid chmod'able
Hi! 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). As a co-admin of university server... Yes, I want users to see what each other user is doing. That way, if someone hacks one account, some other user can notice and tell me. In some environments it may make sense not to allow users to chmod their $HOMEs (so that they can't hide mp3's etc), but we are not *that* stupid/paranoid ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
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. Note that the admin hopefully does not normally run as root. su1 and sudo exist. 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. 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. 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. 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. 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. :) I'd prefer a minimum and a maximum mask. If the admin wants to enforce privacy, he can do it, and if he wants the users to spy on each other, so be it. -- Top 100 things you don't want the sysadmin to say: 23. What do mean by fired? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
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/
[PATCH][RFC] Make /proc/pid chmod'able
OK, folks, another try to enhance privacy by hiding process details
from other users. Why not simply use chmod to set the permissions of
/proc/pid directories? This patch implements it.
Children processes inherit their parents' proc permissions on fork. You
can only set (and remove) read and execute permissions, the bits for
write, suid etc. are not changable. A user would add
chmod 500 /proc/$$
or something similar to his .profile to cloak his processes.
What do you think about that one?
Thanks,
Rene
diff -urp linux-2.6.11-mm3/fs/proc/base.c linux-2.6.11-mm3+/fs/proc/base.c
--- linux-2.6.11-mm3/fs/proc/base.c 2005-03-12 19:23:36.0 +0100
+++ linux-2.6.11-mm3+/fs/proc/base.c2005-03-13 18:36:06.0 +0100
@@ -1605,6 +1605,55 @@ out:
return ERR_PTR(error);
}
+static int proc_base_setattr(struct dentry *dentry, struct iattr *attr)
+{
+ struct inode *inode = dentry-d_inode;
+ struct task_struct *task;
+ unsigned id;
+ int error;
+
+ BUG_ON(!inode);
+
+ error = -EPERM;
+ if (attr-ia_valid != (ATTR_MODE | ATTR_CTIME))
+ goto out;
+ if (attr-ia_mode S_IALLUGO ~(S_IRUGO | S_IXUGO))
+ goto out;
+
+ error = inode_change_ok(inode, attr);
+ if (error)
+ goto out;
+
+ error = -ENOENT;
+ id = name_to_int(dentry);
+ if (id == ~0U)
+ goto out;
+
+ read_lock(tasklist_lock);
+ task = find_task_by_pid(id);
+ if (task)
+ get_task_struct(task);
+ read_unlock(tasklist_lock);
+ if (!task)
+ goto out;
+
+ error = inode_setattr(inode, attr);
+ if (error)
+ goto out_drop_task;
+ /*
+* Save permissions in task_struct as the reverse of the mode.
+* This way a value of zero, which is the default value of a
+* task_struct member, means normal permissions. Children
+* inherit the proc_dir_mask value of their parent process.
+*/
+ task-proc_dir_mask = S_IRWXUGO - (attr-ia_mode S_IRWXUGO);
+
+out_drop_task:
+ put_task_struct(task);
+out:
+ return error;
+}
+
static struct dentry *proc_tgid_base_lookup(struct inode *dir, struct dentry
*dentry, struct nameidata *nd){
return proc_pident_lookup(dir, dentry, tgid_base_stuff);
}
@@ -1625,10 +1674,12 @@ static struct file_operations proc_tid_b
static struct inode_operations proc_tgid_base_inode_operations = {
.lookup = proc_tgid_base_lookup,
+ .setattr= proc_base_setattr,
};
static struct inode_operations proc_tid_base_inode_operations = {
.lookup = proc_tid_base_lookup,
+ .setattr= proc_base_setattr,
};
#ifdef CONFIG_SECURITY
@@ -1797,11 +1848,10 @@ struct dentry *proc_pid_lookup(struct in
put_task_struct(task);
goto out;
}
- inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+ inode-i_mode = (S_IFDIR|S_IRUGO|S_IXUGO) ~task-proc_dir_mask;
inode-i_op = proc_tgid_base_inode_operations;
inode-i_fop = proc_tgid_base_operations;
inode-i_nlink = 3;
- inode-i_flags|=S_IMMUTABLE;
dentry-d_op = pid_base_dentry_operations;
@@ -1852,11 +1902,10 @@ static struct dentry *proc_task_lookup(s
if (!inode)
goto out_drop_task;
- inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+ inode-i_mode = (S_IFDIR|S_IRUGO|S_IXUGO) ~task-proc_dir_mask;
inode-i_op = proc_tid_base_inode_operations;
inode-i_fop = proc_tid_base_operations;
inode-i_nlink = 3;
- inode-i_flags|=S_IMMUTABLE;
dentry-d_op = pid_base_dentry_operations;
diff -urp linux-2.6.11-mm3/include/linux/sched.h
linux-2.6.11-mm3+/include/linux/sched.h
--- linux-2.6.11-mm3/include/linux/sched.h 2005-03-12 19:23:37.0
+0100
+++ linux-2.6.11-mm3+/include/linux/sched.h 2005-03-13 11:54:13.0
+0100
@@ -719,6 +719,10 @@ struct task_struct {
struct audit_context *audit_context;
seccomp_t seccomp;
+#ifdef CONFIG_PROC_FS
+ umode_t proc_dir_mask;
+#endif
+
/* Thread group tracking */
u32 parent_exec_id;
u32 self_exec_id;
-
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/
Re: [PATCH][RFC] Make /proc/pid chmod'able
OK, folks, another try to enhance privacy by hiding process details from other users. Why not simply use chmod to set the permissions of /proc/pid directories? This patch implements it. Children processes inherit their parents' proc permissions on fork. You can only set (and remove) read and execute permissions, the bits for write, suid etc. are not changable. A user would add chmod 500 /proc/$$ or something similar to his .profile to cloak his processes. What do you think about that one? This is a bad idea. Users should not be allowed to make this decision. This is rightly a decision for the admin to make. 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? If you restricted this new ability to root, then I'd have much less of an objection. (not that I'd like it) - 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/
