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

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

[Paul Moore]

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 <pmoore@redhat.com>
---
 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)

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

[Paul Moore]

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 <pmoore@redhat.com>
> ---
>  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?

-- 
paul moore
security and virtualization @ redhat

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

[Eduardo Otubo]

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 <pmoore@redhat.com>
>> ---
>>   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. :(

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

-- 
Eduardo Otubo
IBM Linux Technology Center

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 <pmoore@redhat.com>
> >> ---
> >> 
> >>   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