Subject: Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4)

From: Michael Stone <[email-masked]>
Date: Sun, 10 Jan 2010 16:54:09 -0500

On Fri, 1 Jan 2010, Pavel Machek wrote:

> > > Quoting Michael Stone ([email-masked]):
> > > > Implement security_* hooks for socket_create, socket_bind, socket_connect,
> > > > socket_sendmsg, and ptrace_access_check which return -EPERM when called from a
> > > > process with networking restrictions. Exempt AF_UNIX sockets.
> > > > 
> > > > Signed-off-by: Michael Stone <[email-masked]>
> > > 
> > > Acked-by: Serge Hallyn <[email-masked]>
> > 
> > For the record: NAK, as it introduces security holes.
> 
> Please elaborate.

Pavel's position is that disablenetwork is likely to permit some attacker
somewhere to deny network access to some setuid app some day in a way that
violates some security policy.

He has mentioned specific concern over scenarios like:

   Alice configures PAM auth to 'fail open' by checking login credentials
   against a restrictive LDAP server and, if the server is unavailable, against
   a very permissive files database.

   Alice updates her kernel to a version with disablenetwork.

   Mallory calls disablenetwork, calls su -, and vanquishes all.

My position is that better isolation facilities like disablenetwork will
prevent far more grievous security faults than they (theoretically) cause.

What is your perspective on the matter?

Regards,

Michael