Date: Thu, 2 Jan 1997 21:41:37 +1100 (EST) From: Julian Assange <proff@iq.org> To: hackers@freebsd.org Subject: file locking / firewalling based on uid/gid Message-ID: <199701021041.VAA11426@profane.iq.org> In-Reply-To: <199701020710.CAA09967@skynet.ctr.columbia.edu> from Bill Paul at "Jan 2, 97 02:10:22 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> I have a question. > > Say you have the following series of events: > > - A process creates a socket. > o You now have a struct socket. > o You also have a struct file that references the socket, and that > points to the ucred of the process. > > - The process forks. > o Now the child and the parent refer to the same socket. > > - The child does a setuid() to some other UID. > o You still only have one socket. > > What happens now? You have one socket referenced by two proccesses > with different credentials (I think -- not sure what happens to the > credentials in inherited descriptors when a process does a setuid()). Looked at this. You retain pointers to the original credentials. This is the probably way you want things to be, because of situations like: inetd(root,socket) -> rsh(user) Where by you want root to be able to accept/make connections on behalf of users that do not have such an ability. What is interesting about the inetd situation, is that without introducing an enhanced bind()/PORT_RESERVED access controller, we can forbid root to pass traffic, but permit inetd, running as root, to accept incoming connections. e.g # killall inetd # addgroup inetd # chgrp inetd /usr/sbin/inetd # chmod g+s /usr/sbin/inetd # inetd # ipfw add pass tcp from any to any established gid inetd # ipfw add padd tcp from any to any 21,79 setup in gid inetd Is a good start at eliminating covert channels. Speaking of inetd, does someone care to commit my virtual hosting patches? Cheers, Julian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701021041.VAA11426>