Please consider that protocols like UDP do net need any bind or connect, so sending data would be still possible. Should I introduce a PRIV_NET_SOCKET, too? This would block UDP and other protocols if no file descriptors was already created. From your answer I assume, that you are in favour of a lot of technical privileges (PRIV_NET_BIND, PRIV_NET_CONNECT, ...) instead of one single general privilege (PRIV_NO_NETWORK). So I wonder if we should introduce PRIV_NET_ACCEPT and privileges for the system calls I have illustrated in my first mail to the list (e. g. PRIV_NET_DOOR_CALL, PRIV_NET_SOCKETPAIR) in the future.
Regards Johannes Nicolai On Friday 02 June 2006 17:50, you wrote: > I think we should start with PRIV_NET_CONNECT, PRIV_NET_BIND, this > follows reasonably well what we do else where. One thing that is > different here is I think we might want different privileges to cover > AF_INET/AF_INET6 versus AF_UNIX. I can see the case where we allow UNIX > domain sockets but not internet and vice versa. > > Given that the privilege names will be isolated into policy.c in new > secpolicy_*() function names it allows you to make a start and not worry > too much about the exact names just now. > > As for the "open connections" I believe this has to work so that > already open connections continue to work. There are two reasons for > this, one is an implementation one the other is that this is actually > desirable. > > The implementation reason is that we really only get to check for the > "connect" privilege in the connect(2) system call. After that we are > just doing read(2)/write(2) type of operations on and fd. This makes it > exactly the same as opening a file by using file_dac_read/file_dac_write > privileges. You need them at open(2) time not at read(2)/write(2) time. > > As for while this is actually the desired behaviour. It allow writing > an application that opens up some network connections and then drops the > basic networking privileges to ensure that if exploited no new > connections can be opened. This is similar to what we do with dropping > things like proc_fork/proc_exec or opening up a log file we don't own > then dropping file_dac_read/file_dac_write. > > -- > Darren J Moffat
