Interesting idea, I still not understand some things: 1. What should happen with loopbacked network access (should it be considered like Unix domain sockets)?
2. What about socketpair (is it considered as PRIV_IPC_INITIATE)? 3. Apropos IPC: What is about mapped files? Regards Johannes -----Urspr?ngliche Nachricht----- Von: Nicolas Williams [mailto:Nicolas.Williams at Sun.COM] Gesendet: Fr 02.06.2006 19:46 An: Nicolai Johannes Cc: Darren J Moffat; networking-discuss at opensolaris.org; security-discuss at opensolaris.org Betreff: Re: [networking-discuss] Re: [Security-discuss] First thoughts and questions regarding the expansion of the basic privilege set (Google SoC project) On Fri, Jun 02, 2006 at 07:12:25PM +0200, Johannes Nicolai wrote: > 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. "Socket" is not a good name here. At minimum you probably want to distinguish between initiator/acceptor (responder, whatever) and between local/non-local networking. What else? Here's a quick, simple stab: PRIV_{NET|IPC}_{INITIATE|ACCEPT} PRIV_NET_* would be for anything IP related, except when loopback addresses are used (i.e., if non-loopback addresses are used but traffic would loop back PRIV_NET_* should still apply). PRIV_IPC_* would be for IPC (Unix domain sockets, doors, named pipes, shared memory[?], ...). For non-connection-oriented protocols PRIV_*_INITIATE would control the ability to send {messages, datagrams, ....}. PRIV_NET_INITIATE should apply at connect()-time for connection-oriented transports and for "connected" UDP, and at send*() time for UDP. For non-connection-oriented protocols PRIV_*_ACCEPT would control the ability to receive {messages, datagrams, ....}. PRIV_NET_ACCEPT should apply at listen()/accept()-time for connection- oriented transports and at recv*() time for UDP. For doors PRIV_IPC_ACCEPT would control the ability to create doors, while PRIV_IPC_INITIATE would control the ability to make door calls. For Unix domain sockets PRIV_IPC_{INITIATE|ACCEPT} would work much like PRIV_NET_{INITIATE|ACCEPT}. Similarly for named pipes. I haven't thought about SysV/POSIX IPC (shared memory, message queues, semaphores). > 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.
