Re: [Qemu-devel] [PATCH] seccomp: add shmctl(), mlock(), and munlock() to the syscall whitelist

[Paul Moore]

On Wednesday, March 05, 2014 11:53:58 AM Eduardo Otubo wrote:
> On 03/03/2014 05:41 PM, Paul Moore wrote:
> > On Wednesday, February 26, 2014 10:25:01 AM Paul Moore wrote:
> >> Additional testing reveals that PulseAudio requires shmctl() and the
> >> mlock()/munlock() syscalls on some systems/configurations.  As before,
> >> on systems that do require these syscalls, the problem can be seen with
> >> 
> >> the following command line:
> >>    # qemu -monitor stdio  -sandbox on \
> >>    
> >>           -device intel-hda -device hda-duplex
> >> 
> >> Signed-off-by: Paul Moore <address@hidden>
> >> ---
> >> 
> >>   qemu-seccomp.c |    5 ++++-
> >>   1 file changed, 4 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/qemu-seccomp.c b/qemu-seccomp.c
> >> index caa926e..3db1e9b 100644
> >> --- a/qemu-seccomp.c
> >> +++ b/qemu-seccomp.c
> >> @@ -225,7 +225,10 @@ static const struct QemuSeccompSyscall
> >> seccomp_whitelist[] = { { SCMP_SYS(fchmod), 240 },
> >> 
> >>       { SCMP_SYS(shmget), 240 },
> >>       { SCMP_SYS(shmat), 240 },
> >> 
> >> -    { SCMP_SYS(shmdt), 240 }
> >> +    { SCMP_SYS(shmdt), 240 },
> >> +    { SCMP_SYS(shmctl), 240 },
> >> +    { SCMP_SYS(mlock), 240 },
> >> +    { SCMP_SYS(munlock), 240 }
> >> 
> >>   };
> >>   
> >>   int seccomp_start(void)
> > 
> > Bump to bring this back the forefront of everyone's minds.  Can we get
> > this merged?
> 
> Sorry for the late review, I've been hit by a terrible tendinitis and
> was unable to use a computer for the last week. :(

Hopefully nothing that isn't too unbearable and unmanageable.  Tendinitis can 
be a real pain.

> I ACK this patch and I'll create a pull request by friday EOD if nothing
> else comes up.

Great, thank you.  I've run across one more issue related to Open vSwitch and 
getrusage(); I'll try to get that fixed/tested before Friday, but don't let 
that hold up this fix.

On a somewhat related note, have you done any work on the dynamic, per-feature 
whitelist?  I'm thinking of doing some work to put together a basic framework 
for this, but I didn't want to waste time on a duplicated effort ...

-Paul

-- 
paul moore
security and virtualization @ redhat