Testing chrony seccomp support
luto at mit.edu
Mon Oct 5 14:02:47 UTC 2015
On Oct 5, 2015 6:23 AM, "Michael Catanzaro" <mcatanzaro at gnome.org> wrote:
> On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
> > The rawhide chrony package is now compiled with the seccomp support,
> > but the filtering is not enabled by default. The trouble is it has to
> > cover all system calls needed in all possible configurations of
> > chrony
> > and all libraries it depends on, which is difficult and it may even
> > change over time as the libraries are updated.
> Yes; depending on your dependencies (...yeah!) this could be highly
> problematic. As you say, it imposes the requirement that all of your
> dependencies in Fedora never begin to use new syscalls, and never use
> syscalls in unexpected ways, over the supported lifetime of a Fedora
> release, or bundle their updates with corresponding chrony updates if
> they do. Frankly it's a recipe for disaster, given that many
> maintainers submit major version updates in flagrant disregard for our
> current updates policy, and using seccomp would require tightening the
> updates policy much more (since it makes minor version updates quite
> risky -- but we still want to do those...), but the security benefits
> of seccomp are huge so it's possibly worth working towards....
Why is the filter causing SIGSYS instead of forcing an ENOSYS return?
I'll look into the abrt thing. It might be an easy fix.
> Random example: when I was testing WebKit's experimental seccomp mode
> in Fedora 21, the maintainers of libxshmfence submitted an update to
> start using the new syscall memfd_create() rather than putting shared
> memory in /var/tmp. That's an acceptable update under all of our
> guidelines, since that's an implementation detail that ordinarily
> wouldn't affect programs, but it caused WebKit to crash on start, and
> would have broken pretty much anything else using libxshmfence and
> seccomp, since programs aren't going to have whitelisted a syscall that
> was not previously used (and in this case, didn't even exist when it
> was written). With chrony using seccomp, its dependencies must never do
> such a thing (except in rawhide).
> (Also fun is to try making the same list of filters work across
> So chrony might work perfectly now, but who knows how broken it will be
> after a couple months of updates.... Well, you'll find out after
> testing it in rawhide. Hope seccomp works better for you than it did
> for me. Of course, for programs with few dependencies, there's not
> really much problem.
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel