On Mon, Jun 18, 2012 at 8:13 PM, Eduardo Otubo <ot...@linux.vnet.ibm.com> wrote: > On Mon, Jun 18, 2012 at 02:55:35PM +0100, Daniel P. Berrange wrote: >> On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote: >> > On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote: >> > > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote: >> > > > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote: >> > > > > I think allowing execve() would render seccomp pretty much useless. >> > > > >> > > > Not necessarily. >> > > > >> > > > I'll agree that it does seem a bit odd to allow execve(), but there is >> > > > still value in enabling seccomp to disable potentially >> > > > buggy/exploitable >> > > > syscalls. Let's not forget that we have over 300 syscalls on x86_64, >> > > > not >> > > > including the 32 bit versions, and even if we add all of the new >> > > > syscalls >> > > > suggested in this thread we are still talking about a small subset of >> > > > syscalls. As far as security goes, the old adage of "less is more" >> > > > applies. >> > > >> > > I can sort of see this argument, but *only* if the QEMU process is being >> > > run under a dedicated, fully unprivileged (from a DAC pov) user, >> > > completely >> > > separate from anything else on the system. >> > > >> > > Or, of course, for a QEMU already confined by SELinux. >> > >> > Agreed ... and considering at least one major distribution takes this >> > approach >> > it seems like reasonable functionality to me. Confining QEMU, either >> > through >> > DAC and/or MAC, when faced with potentially malicious guests is just good >> > sense. >> >> Good, I'm not missing anything then. I'd suggest that future iterations >> of these patches explicitly mention the deployment scenarios in which >> this technology is able to offer increases security, and also describe >> the scenarios where it will not improve things. > > Please correct me if I'm wrong here, but I don't understand how exactly > whitelisting execve() is odd. The white list is inherit and passed along > the child processes so they also need to have their own syscalls filtered > by BPF in the kernel as stated in the Will's commit log[1] - "Filter > programs will be inherited across fork/clone and execve." - I wonder if > this is main point of your concern. Whitelisting execve() or not should be > no difference from the security pov.
The helper might behave strangely (read: according to attacker's wishes) when some of the required syscalls are not working. > However, I agree that a possible future feature could a customized > whitelist for each child process spawned. But for a first instance, the > default whitelist should be enough to start seccomp support in Qemu. It's a good way. I just wish the list weren't so open and lame to begin with. > > Also, as far as I understand, seccomp never meant to replace any of the > technologies above mentioned. Using more than one layer of protection > (SELinux, AppArmor MAC policy and/or DAC) should always be a good practice > for the defense in depth. > > [1] - > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e2cfabdfd075648216f99c2c03821cf3f47c1727 > > -- > Eduardo Otubo > Software Engineer > Linux Technology Center > IBM Systems & Technology Group > Mobile: +55 19 8135 0885 > eot...@linux.vnet.ibm.com >
