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.
