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] [day] [month] [year] [list]

Message-ID: <e81d9c0cbc85262051b2246783bb193b@chewa.net>
Date:	Tue, 13 Jan 2009 09:06:39 +0100
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
Subject: Re: RFC: Network privilege separation.

   Hello,

On Mon, 12 Jan 2009 22:50:01 +0100, Andi Kleen <andi@...stfloor.org> wrote:
>> Fair enough. It's just way too much interface/adaptation work compared
>> to the benefit. Especially considering that it would be much easier, and
>> almost as secure, with a "relaxed" SECCOMP.
> 
> What system calls would you want in a relaxed SECCOMP?

I already listed them on a high level. At the very very least, brk(),
sbrk(), mmap(), mremap(), getpagesize() and munmap() so that we can re-use
the libc memory allocator. If one wants to limit memory usage, there is
always setrlimit() before enabling SECCOMP.

Also readv() and writev() could not hurt; I suppose neither could
vmsplice().

I don't know what are the security implications of inter-process futex(). I
assume it's possible to freeze, and perhaps busy loop other task that would
use the same futexes. That is OK to me. But it's not clear to me if
something really bad, like arbitrary memory access could be achieved.
Notably, with futex() allowable, we can also grant clone(), gettid() and
then we can run parallelized codecs on SMP.

>> And on top of that, it's causing
>> unnecessary overhead (we're also interested in those small Linux-based
> 
> Would be interesting to try that out -- just adding two memcpyies to
> the existing code and see how much slower it gets. My guess
> would be not very, even e.g. on a Atom system (which are really
> not all that slow).
> 
> Presumably you could always #ifdef it if it's really a problem
> on some specific system. That would be needed anyways for
> non linux systems.

In practice, I suspect the most work would come from reworking the build
system such that codecs are executable rather than libraries. I suspect a
plain fork() with _no_ exec() would leave to many unused anonymous pages
from the main media player process, not to mention information leakage.

I'd like to point out that, from my personnal experience, we've had more
problem this far with file format parsers than codecs. I don't know why. It
might be because they are easier for pirates to talk to, as they're one
step closer to the data than codecs. Or it is that the VideoLAN project is
writing overall more buggy code than, say, FFMPEG :-( ?

To sandbox parsers, we might need a whole lot more stuff, especially timers
and events handling stuff.

-- 
Rémi Denis-Courmont

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