[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200901122147.57731.rdenis@simphalempin.com>
Date: Mon, 12 Jan 2009 21:47:57 +0200
From: Rémi Denis-Courmont <rdenis@...phalempin.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Valdis.Kletnieks@...edu, Alan Cox <alan@...rguk.ukuu.org.uk>,
Michael Stone <michael@...top.org>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: RFC: Network privilege separation.
Le lundi 12 janvier 2009 21:43:33 Andi Kleen, vous avez écrit :
> > Yes, the network access part *is* something that should be part of a more
> > general interface. Having said that, we currently are lacking a way for
> > a *general user* program to say "I'm all set up, and would like to
> > disavow any other further resource access (except maybe r/o access as
> > "other" to file systems)".
>
> seccomp does exactly that. It's quite obscure, but available in most
> linux kernels. Basically it blocks everything except
> read/write on already open file descriptors.
>
> I always thought it would be nice if codecs (which tend
> to be full of security holes) ran in such jails by default
Yeah, and there are not going to do that because there are lots of useful
stuff codecs like to do that represents no security issue but is nevertheless
impossible with SECCOMP (according to the documentation).
Expanding the heap, mapping memory. Getting timestamps. Waiting on futexes,
catching signals, polling file descriptors. Seeking, doing vectorized I/O.
Cloning.
Codecs don't like to read/write raw video through a pipe...
--
Rémi Denis-Courmont
http://www.remlab.net/
--
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/
Powered by blists - more mailing lists