Date: Thu, 9 Sep 1999 01:02:41 -0500 From: "Jason Young" <doogie@anet-stl.com> To: "Daniel O'Connor" <doconnor@gsoft.com.au>, "Gustavo V G C Rios" <grios@ddsecurity.com.br> Cc: <freebsd-hackers@FreeBSD.ORG>, <chris@calldei.com> Subject: RE: CS Project Message-ID: <NCBBJEDMMDOPOMPDEKBPIEFFDDAA.doogie@anet-stl.com> In-Reply-To: <XFMail.990909113502.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of > Daniel O'Connor > Sent: Wednesday, September 08, 1999 9:05 PM > To: Gustavo V G C Rios > Cc: freebsd-hackers@FreeBSD.ORG; chris@calldei.com > Subject: Re: CS Project > > > > On 09-Sep-99 Gustavo V G C Rios wrote: > > > I would be able to see any other proccess which i am > not the owner, top > > ^^^^^^^^ > > would not be (there was a mistaken in the > sentece above, it was > > in lack of "not" ) > > > > > would indicated, only 8 proccess, for this current scenario. > > > > > > do you understand now, what i meant? > > > > > > Linux already have such a facility! > > Hack ps and turn off procfs :) I would think it more appropriate to adjust procfs' permissions in the kernel such that a user couldn't look at processes they don't own, i.e., can't cd or look into /proc/$PIDTHEYDONTOWN. Adding group-read for wheel or operator or a special new group would be good for things that must see all the processes. Like this: > ls -al /proc dr-xr-x--- 15 root operator 512 Sep 9 00:36 171 dr-xr-x--- 15 root operator 512 Sep 9 00:36 17430 dr-xr-x--- 15 doogie operator 512 Sep 9 00:36 17758 dr-xr-x--- 15 doogie operator 512 Sep 9 00:36 17760 Alternatively, you could just have only the entries you're supposed to see show up in /proc, and the rest would be suppressed entirely. If you then have procfs directly disclaim knowledge of that process when queried by an unpriveleged user (chdir to /proc/$PIDEXISTSBUTNOTYOURS would return ENOENT instead of EACCES), you deny brute force attacks to find out if a PID exists and by who it is owned. That increases privacy a bit. After all that, one could implement a 'ps' command that would use only procfs for process info. Procfs would need to export some more info, I think, that is only available via kvm but surely this is a trivial task. Then you have a simple situation where the kernel tells the user exactly what they should know and ps just looks up all the info it's allowed to. This should be controlled by sysctls like (placement based on nfs and ffs sysctl placement precedent): vfs.procfs.user_proc_privacy (0 or 1) vfs.procfs.user_proc_overridegid (obvious, -1 for no magic GID) I vaguely recall that PicoBSD has already got a procfs ps implementation. I might be wrong there. Somebody's done one, anyway. I think it would be a nice idea to have such a thing in the base system, since such a simple utility shouldn't have to grovel in kmem and be suid root. Note that this feature would dovetail itself nicely to the jail() concept. The kernel could check jail credentials as well as UID/GID credentials to present only the jailed virtual machine processes to the users (including root) inside the jail. I think the idea (of a procfs ps) was shot down on the lists some time ago because ps needs to retain the ability to look at the process list in a kernel coredump. IMHO that's a lot of messy kvm groveling and associated kernel-to-userland sync dependencies, just to cater to the (generous figure) 0.5% of the people out there who have 1) a crashing FreeBSD box and 2) the expertise and the will to debug the crash dump. I think that issue needs to be revisited somehow. Unfortunately I don't have my proposal written in diff(1) at the moment, but writing all this out makes me really want to go ahead and do it. Then again, somebody DID ask for a CS project. :) Hope this helps, Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NCBBJEDMMDOPOMPDEKBPIEFFDDAA.doogie>