[libvirt] Seccomp profile for swtpm as default
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. Regards, Stefan
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. 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 :|
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... Stefan
Regards, Daniel
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 :|
participants (2)
-
Daniel P. Berrangé -
Stefan Berger