[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Seccomp profile for swtpm as default
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] Seccomp profile for swtpm as default |
Date: |
Fri, 15 Mar 2019 10:44:27 +0000 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
On Thu, Mar 14, 2019 at 07:15:10AM -0400, Stefan Berger wrote:
> On 3/14/19 5:59 AM, Daniel P. Berrangé wrote:
> > On Wed, Mar 13, 2019 at 03:43:13PM -0400, Stefan Berger wrote:
> > > Hello!
> > >
> > > If you have some feedback regarding a seccomp profile extension for
> > > swtpm
> > > for v0.2, please let me know. I created this github issue here:
> > >
> > >
> > > https://github.com/stefanberger/swtpm/issues/115
> > >
> > >
> > > Basically the choice is whether to make the creation of the seccomp
> > > profile
> > > a default behavior or have the caller explicitly pass the '--seccomp
> > > profile=default' on the command line, which then in turn would require
> > > libvirt for example to check whether this current version of swtpm
> > > supports
> > > the feature either by swtpm version or by strstr() the help page.
> > In QEMU we can't enable seccomp by default because its wide range of
> > features means any default profile would be effectively useless. Libvirt
> > knows that it uses a restricted set of QEMU features, so it can enable
> > a more useful seccomp by default.
> >
> > I think swtpm won't have this complexity problem. Its functionality is
> > relatively narrow & well understood & so it is practical to define a
> > good seccomp profile & use that by default. So personally I'd merely
> > provide an opt-out to turn it off unless you think this is likely to
> > break something important.
>
> Thanks. What makes me a bit hesitant now to activate it is the fact that I
> found several unexpected syscalls in places like openssl DRBG and glibc. The
> latter for example uses some #define ARCH_FORK (iirc), which was not fork or
> vfork but clone on F29. It will obviously break if it is something different
> on another machine or if it runs into branches that I haven't exercised with
> the limited coverage the test suite I have provides...
Yes, seccomp rules are arguably specific to the C library impl, though
I'd expect most C impls are largely the same. The use of clone instead
of fork is pretty long standing, as it is basically a more generalized
API so there's little reason to use the old fork() syscall.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|