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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090108054145.GU496@one.firstfloor.org>
Date:	Thu, 8 Jan 2009 06:41:45 +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 11:51:08PM -0500, Michael Stone wrote:
> In short, I'm trying to provide a general-purpose facility for
> 
>   * limiting networking per _process_, not per user, 
> 
>   * with an api that requires no privilege to exercise, 

While it may seem old fashioned the good old suid wrapper
is still working well for such things. That assumes you don't
want to do that in the middle of a process execution,
but that seems like a reasonable restriction.

>   * which is suitable for widespread adoption by lots of Unix vendors and
>     related standards bodies,

Hmm, I suppose RLIMIT_* does not qualify then. 

>       + when it drop privileges, it becomes unable to acquire new resources 
>       on
>         its own

That's difficult, for example are you going to disallow fork/exec?
If no then the process might still exploit something suid.

Also typically such sandbox schemes want to restrict more system
calls (basically using a white list), just in case to protect against unknown 
kernel holes in the more complex ones.

>       + though other processes may still be able to send your process tokens
>         which give it access to resources which it couldn't open on its own.
> 
> Does this help clarify the causes of my design choices?

It would be probably better if you had a few concrete use cases too
(so not just what, but also why) 

Anyways, it all sounds like more like it should be done as a special
case in a more general sandbox framework to me. Linux already
has several ones (e.g. selinux, secure computing, AA out of tree). Perhaps one
of them could be adapted to your needs.

> >Why limiting Unix sockets and not e.g. named pipes? 
> 
> Named pipes, like non-abstract unix sockets, are manageable through the
> filesystem, e.g. by DAC and namespace manipulating tools like bind-mounts 

In Linux, at least traditional BSD semantics ignore file system
access checks on Unix sockets. 

> and
> chroots.

There are more IPC mechanisms around too, e.g. sysv message passing
or queued signals with payload.  You probably need to consider
all of those.

-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/