[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] seccomp: add shmctl(), mlock(), and munlock() t
From: |
Paul Moore |
Subject: |
Re: [Qemu-devel] [PATCH] seccomp: add shmctl(), mlock(), and munlock() to the syscall whitelist |
Date: |
Wed, 05 Mar 2014 12:35:10 -0500 |
User-agent: |
KMail/4.12.2 (Linux/3.12.13-gentoo; KDE/4.12.2; x86_64; ; ) |
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