Date: Thu, 09 Sep 1999 15:53:25 +0930 (CST) From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Jason Young <doogie@anet-stl.com> Cc: chris@calldei.com, freebsd-hackers@FreeBSD.ORG, Gustavo V G C Rios <grios@ddsecurity.com.br> Subject: RE: CS Project Message-ID: <XFMail.990909155325.doconnor@gsoft.com.au> In-Reply-To: <NCBBJEDMMDOPOMPDEKBPIEFFDDAA.doogie@anet-stl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990909155325:656=_ Content-Type: text/plain; charset=us-ascii On 09-Sep-99 Jason Young wrote: > > 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: Well.. that doesn't sound *too* complex either. Would make an interesting CS project :) > 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. Yes. it depends on your level of paranoia. > 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 It would be a good idea anyway.. I think someone has one floating around anyway. > allowed to. This should be controlled by sysctls like (placement based > on nfs and ffs sysctl placement precedent): Or even a mount option to procfs :) > 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. Well.. I do use crash dumps, but rarely use ps on them.. Even so you could have 2 implementations of ps, or a ps which allows you to compile in a different 'back end'. That way you can use either easily. > 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. :) Heh :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990909155325:656=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN9dSXVbYW/HEoF9pAQHYSgQAlC2MSFxCsIQFDXeBV9ohTuhFvnvVbu2r oETuLRH0sTZYO5KWtKmC99QFdGWwKvSPiBagg6U4kkWrOhQFCdQuL4WjXQwgkiUF swIRfM2WUW+gbAj/V/p6X4beievtFXjs5I0ranfXlM8QM4atCgt9pMU2IUfKcCOT PCllYG+7ESs= =sXPQ -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990909155325:656=_-- End of MIME message 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?XFMail.990909155325.doconnor>