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

Reply via email to