From: Andi Kleen <andi@firstfloor.org>
To: Michael Stone <michael@laptop.org>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: RFC: Network privilege separation.
Date: Thu, 8 Jan 2009 04:10:42 +0100 [thread overview]
Message-ID: <20090108031042.GQ496@one.firstfloor.org> (raw)
In-Reply-To: <20090108023111.GJ3164@didacte.laptop.org>
On Wed, Jan 07, 2009 at 09:31:11PM -0500, Michael Stone wrote:
> -- 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?
You always create joe-nonet one when you create joe
Now writing to joe's files: you can either use ACLs or do everything
through group accesses (it's very common to have a "joe" group for this
purpose for each user)
But perhaps it's a good idea to not allow writing to all of Joe's
files by those "no network" processes too. It at least sounds like
that might be useful to combine.
> * 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?
No you can't. But is that really your requirement? Why limiting Unix
sockets and not e.g. named pipes? Unix sockets do not talk to the network.
I suppose I don't understand your requirements very well.
>
> * 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?
You always define static ones at system boot.
It would probably not scale to a lot of users, but I understand you're
talking about the OLPC which probably only has a limited set of users?
Even on a true multiuser system it could be done in a PAM module.
>
> -- 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?
Your arguments don't seem very convincing to me, but
the big problem is more the control of incoming packets. I think
it would be possible to fix OWNER match to support the INPUT chain
though.
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2009-01-08 2:56 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 5:48 RFC: Network privilege separation 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
2009-01-08 3:10 ` Andi Kleen [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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=20090108031042.GQ496@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@laptop.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;
as well as URLs for NNTP newsgroup(s).