mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Stone <michael@laptop.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: RFC: Network privilege separation.
Date: Wed, 7 Jan 2009 21:31:11 -0500	[thread overview]
Message-ID: <20090108023111.GJ3164@didacte.laptop.org> (raw)
In-Reply-To: <87mye2yg8a.fsf@basil.nowhere.org>

On Wed, Jan 07, 2009 at 10:10:45PM +0100, Andi Kleen wrote:
>Michael Stone <michael@laptop.org> 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

  reply	other threads:[~2009-01-08  2:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-07  5:48 Michael Stone
2009-01-07  5:48 ` [PATCH] Security: Implement and document RLIMIT_NETWORK Michael Stone
2009-01-07 11:47   ` Evgeniy Polyakov
2009-01-07 16:52     ` Rémi Denis-Courmont
2009-01-07 17:48       ` Evgeniy Polyakov
2009-01-07 20:54         ` Rémi Denis-Courmont
2009-01-07 21:42           ` Evgeniy Polyakov
2009-01-07 18:35     ` C. Scott Ananian
2009-01-07 19:02       ` Evgeniy Polyakov
2009-01-07 19:39         ` Evgeniy Polyakov
2009-01-07 21:07     ` Michael Stone
2009-01-07 21:59       ` Evgeniy Polyakov
2009-01-08  0:56         ` Michael Stone
2009-01-08  4:27           ` Evgeniy Polyakov
2009-01-08  1:22       ` James Morris
2009-01-08  3:34         ` Michael Stone
2009-01-07 21:10 ` RFC: Network privilege separation Andi Kleen
2009-01-08  2:31   ` Michael Stone [this message]
2009-01-08  3:10     ` Andi Kleen
2009-01-08  4:51       ` Michael Stone
2009-01-08  5:41         ` Andi Kleen
2009-01-08  7:05       ` Oliver Hartkopp
2009-01-08  7:52       ` david
2009-01-08 10:43     ` Alan Cox
2009-01-12 18:44       ` Valdis.Kletnieks
2009-01-12 19:09         ` Bryan Donlan
2009-01-12 19:43         ` Andi Kleen
2009-01-12 19:47           ` Rémi Denis-Courmont
2009-01-12 20:14             ` Andi Kleen
2009-01-12 20:15               ` Rémi Denis-Courmont
2009-01-12 20:27                 ` Evgeniy Polyakov
2009-01-12 20:39                 ` Andi Kleen
2009-01-12 20:30                   ` Rémi Denis-Courmont
2009-01-12 20:55                     ` Andi Kleen
2009-01-12 20:47                       ` Rémi Denis-Courmont
2009-01-12 21:50                         ` Andi Kleen
2009-01-13  8:06                           ` Rémi Denis-Courmont
2009-01-08 12:08 Herbert Xu
2009-01-08 12:10 Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090108023111.GJ3164@didacte.laptop.org \
    --to=michael@laptop.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®