Re: RFC: Network privilege separation.

[Michael Stone]

On Wed, Jan 07, 2009 at 10:10:45PM +0100, Andi Kleen wrote:
> Michael Stone <michael@xxxxxxxxxx> writes:
>
> > For the sake of discussion, I have written up and documented one possible
> > implementation of this concept based on the idea of a new rlimit named
> > RLIMIT_NETWORK in the following patch series. 
> >
> > I eagerly await your questions, comments, suggestions, and improvements.
>
> At least for outgoing packets you could already do it using the netfilter
> owner match and a suitable uid. I suppose that could be also extended
> for incoming packets.

While it's certainly true that you can simulate /some/ of the functionality of
my patch with the (deprecated?) netfilter owner match extension and by
synthesizing new uids as needed, I'm fairly sure that you'll run into some
serious complications involving concurrent manipulations of shared mutable
state which my proposal does not suffer from.

For example:

  * in order to user owner-match, you need to specify a uid and you probably
    need to back it up with an account in the pwd database in order to keep
    random bits of userland happy. What uid should you use?

    -- if it's the same as Joe User's uid, then you're probably going to break
       random other parts of Joe User's software stack. How is Joe going to
       debug this?

        + (unless, of course, you've also got CAP_NET_ADMIN, use the new net
          namespaces work, /and/ reconfigure your whole networking stack inside
          the new NS.)
   
    -- if it's different from Joe User's regular uid, then where did it come
       from and how is Joe going to clean it up when he no longer needs it?

        + again, privilege is required, either in the form of a setuid
          executable, CAP_SETUID capability, or an NSS module (or some
          combination of these)

  * so far as I know, netfilter is only commonly used to filter IP traffic. Can
    I really use it to limit connections to abstract unix sockets?

  * I think there are some problems with resource acquisition, trust, and
    finalization:

    -- something has to work out the actual firewall rules which need to be
       added. 

        + why should you or your sysadmin trust whatever is doing this to pick
          the right ones?

    -- something (with privilege) needs to install the firewall rules and needs
       to remove unneeded rules or you've got a space leak.

        + are there any significant race conditions between whatever is
          installing the rules and whatever is removing the dead rules?

Conclusion: so far as I can see, RLIMIT_NETWORK is, in every way, a smaller
expansion of the end user's trusted code base and should therefore be preferred
in comparison netfilter-based solutions for process-level network privilege
separation tasks. Do you see things differently?

Thanks very much,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/