Date: Mon, 1 Nov 1999 11:17:28 -0500 (EST) From: Spidey <beaupran@jsp.umontreal.ca> To: peter.jeremy@alcatel.com.au Cc: freebsd-security@FreeBSD.ORG Subject: Re: Examining FBSD set[ug]ids and their use Message-ID: <14365.48408.87230.710344@anarcat.dyndns.org> References: <14364.64172.638014.558487@anarcat.dyndns.org> <99Nov1.143118est.40332@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Big Brother told Peter Jeremy to write, at 14:36 of November 1: > On 1999-Nov-01 13:27:56 +1100, Spidey wrote: > >I started 'compiling' some info about the use of the setuid and setgid > >files in FreeBSD. > > An excellent idea. Note that some of the files you specify are > ports. Yes. I should have mentionned it maybe... I think we should do the same for all ports, and even more. I was thinking of putting a warning message in the port's makefile itself when there's a setuid installed. > As a general rule, anything that is setgid kmem should be converted > to a new sysctl with an unprivileged task to access it. Hum. I don't know.. wouldn't that give a widespread access? When we can simply turn the suid bit off certain binaries? > ># Allow users to see processes? Users cannot see the 'STARTED' and > ># 'TIME' columns, from ps aux... I don't want to dig much more.. > > ps gname=kmem mode=2555 > > I believe it's necessary for users to see other users' processes. > The information should probably be available via /proc instead. For that I don't know really... But yes, /proc could be a quite good solution. Is it possible to enforce file permissions on /proc? :)) > ># I don't have a ccd... I can't test this. > > ccdconfig gname=kmem > > Probably unnecessary. No-one but root needs to be able to run ccdconfig. That's what I thought too! > ># Allow users to dump on remote (see dump(1), the BUGS section) > > dump gname=tty > > rdump gname=tty > > restore gname=tty > > rrestore gname=tty > > As I recall it, this is to allow dump/restore to write to the console > (and wake up the operator) when it needs feeding. Ah! That's a fact.... I thought it was for remotes, as rsh or rlogin, to bind on a privilege port. But then, they would have to be suid root!!! > ># Allow users to bind on a socket (which? where?) > > ping mode=4555 > Needed to allow ordinary mortals to sent raw IP (ICMP) packets. I don't think this should be enable by default... on a shell box, this could cause some pretty dense headaches... > ># Allow users to consult routing tables > > route mode=4555 > > Needed to allow ordinary mortals to access the routing socket. > This is probably another sysctl candidate. Great. I'm learning. :) > ># ????? Look what's here?! > > Xwrapper mode=4711 > > This is a wrapper for the X-server. The idea is that Xwrapper is > slightly smaller :-) and less subject to security holes. Ok. But what is its use??? Is it used by X? Why is it suid? > ># Allow users to read master.passwd, skeykeys and probably other > ># things... > > login > > Necessary to allow users to log in as another user. > > ># Allow users to read the mail queue > ># Again, this is part of the sendmail suite and _can_ be replaced :) > > mailq > > Hard link to newaliases and sendmail. Only needs root for local > mail delivery in the absence of a setuid local delivery agent. > (It's fairly trivial to sandbox sendmail). Hum.. Indeed. I never thought of that. I think that sendmail should be run in a sandbox, as it is a complex system open to the network... > ># Allow users to use the catman cache > ^^^ update > > man uname=man Indeed. > ># Allow users to 'read' /etc/master.passwd > > su > Actually it's to allow users to change thir uid. Also. > ># I never understood what uucp was.... > >/set mode=4555 uname=uucp gname=wheel > > uucp > > uuname > > uustat gname=dialer mode=6555 > > uux > > UUCP lives in it's own sandbox. Ok. but what _is it_? Why does it needs special permissions? > ># "Gaming" management > > dm > > All games live in their own group for sandboxing. > > ># This is the sendmail super-program that does everything. Get rid of > ># it, install postfix.. :) > Religious comments don't belong in a file being touted as a part > of generic FreeBSD. That is a fact. But I never even hoped to see that file in generic FreeBSD. The final one won't have these comments. Thanks for yours. AnarCat. -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14365.48408.87230.710344>