linux-kernel - Re: RFC: Network privilege separation.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090108031042.GQ496@one.firstfloor.org>
Date:	Thu, 8 Jan 2009 04:10:42 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Michael Stone <michael@...top.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: RFC: Network privilege separation.

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@...ux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/