[libvirt] Seccomp profile for swtpm as default

[Daniel P. Berrangé]

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 :|