After having thought more about your suggestions, some further questions have occured, I like to discuss:
1. You stated "Similarly for named pipes. I haven't thought about SysV/POSIX IPC (shared memory, message queues, semaphores)." What do you mean with "similar", there is a system call mkfifo, one can deny if PRIV_IPC_ACCEPT is not set, but how to react if a process opens and writes/reads to a named pipe (should I modify open and read, too)? Apropos open/read: Communication over files (open/read or mmap) or with SIGNALS (directly via kill or indirectly via fcntl) may also be considered as IPC. So PRIV_IPC_* would affect a lot of things. My suggestion is that I start with the PRIV_NET_* capabilities because for these, I do not have to modify lots of system calls. Regards Johannes -----Ursprüngliche Nachricht----- Von: Nicolas Williams [mailto:[EMAIL PROTECTED] Gesendet: Fr 02.06.2006 19:46 An: Nicolai Johannes Cc: Darren J Moffat; [email protected]; [EMAIL PROTECTED] 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. _______________________________________________ networking-discuss mailing list [email protected]
