linux-kernel - Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

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]

Date:	Thu, 26 May 2011 11:30:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	James Morris <jmorris@...ei.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kees Cook <kees.cook@...onical.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Will Drewry <wad@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, gnatapov@...hat.com,
	Chris Wright <chrisw@...s-sol.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call
 filtering

* Avi Kivity <avi@...hat.com> wrote:

> > Note that tools/kvm/ would probably like to implement its own 
> > object manager model as well in addition to access method 
> > restrictions: by being virtual hardware it deals with many 
> > resources and object hierarchies that are simply not known to the 
> > host OS's LSM.
> >
> > Unlike Qemu tools/kvm/ has a design that is very fit for MAC 
> > concepts: it uses separate helper threads for separate resources 
> > (this could in many cases even be changed to be separate 
> > processes which only share access to the guest RAM image) - while 
> > Qemu is in most parts a state machine, so in tools/kvm/ we can 
> > realistically have a good object manager and keep an exploit in a 
> > networking interface driver from being able to access disk driver 
> > state.
> 
> You mean each thread will have a different security context?  I 
> don't see the point.  All threads share all of memory so it would 
> be trivial for one thread to exploit another and gain all of its 
> privileges.

You are missing the geniality of the tools/kvm/ thread pool! :-)

It could be switched to a worker *process* model rather easily. Guest 
RAM and (a limited amount of) global resources would be shared via 
mmap(SHARED), but otherwise each worker process would have its own 
stack, its own subsystem-specific state, etc.

Exploiting other device domains via the shared guest RAM image is not 
possible, we treat guest RAM as untrusted data already.

Devices, like real hardware devices, are functionally pretty 
independent from each other, so this security model is rather natural 
and makes a lot of sense.

> A multi process model works better but it has significant memory 
> and performance overhead.

Not in Linux :-) We context-switch between processes almost as 
quickly as we do between threads. With modern tagged TLB hardware 
it's even faster.

> (well the memory overhead is much smaller when using transparent 
> huge pages, but these only work for anonymous memory).

The biggest amount of RAM is the guest RAM image - but if that is 
mmap(SHARED) and mapped using hugepages then the pte overhead from a 
process model is largely mitigated.

Once we have a process model then isolation and MAC between devices 
becomes a very real possibility: exploit via one network interface 
cannot break into a disk interface.

Maybe even the isolation and per device access control of 
*same-class* devices from each other is possible: with careful 
implementation of the subsystem shared data structures. (which isnt 
much really)

Thanks,

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