On Sun, 16 Aug 2020 at 15:47, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
I think it would be wise to use do fallback logic for EPERM too. It's
the error that nspawn uses since day #1 basically. I am a bit puzzled
noone noticed this before, afaik glibc test cases at least on Fedora
(where most glibc upstream devs work on) run in nspawn, so how did
noone notice?
That's interesting .. it's possible things don't work quite the way I think they do, but I will try to find previous examples - I remember borgbackup was affected on armhf fairly recently, for example.
I suspect trying to convince glibc maintainers to check for EPERM could turn into a holy war quite quickly :)
> A rule of thumb might be to return ENOSYS for anything libseccomp doesn't
> know about - is it possible to look things up that way around?
libseccomp doesn't allow us to install filters for syscalls it doesn't
know anyway iirc...
Not sure I follow though? Why would that help?
Well, my logic was if seccomp didn't know about a syscall when it was built then that syscall is "new", and userland can probably live without it. If we're going to block it anyway (because seccomp doesn't know about it, it won't end up in the whitelist, even if systemd/nspawn is more up-to-date), we might as well return ENOSYS and let userland try a fallback (e.g. openat instead of openat2.) We can still return EPERM for well-known-but-blocked syscalls which hopefully indicates to sufficiently caffeinated users that there's a security filter in place :)
> Another useful thing might be to allow whitelisting by syscall number -
> again don't know if seccomp allows this. Would allow easier work arounds in
> cases like this without having to go off and backport libseccomp...
syscall numbers are highly arch dep, we currently don't support that
because you cannot reasonably express this in unit files, as they'd
become very much arch dependent then.
That said, I'd be happy to review/merge a patch that adds a syntax
where you could spell out SystemCallFilter=x86-64:345 for example,
i.e. specify arch plus syscall nr. But it's still ugly, since it would
do result in different filers on different archs.
Yeah, I'm not suggesting anyone should deploy that in a published unit file. But for individual admins/users to "bodge" a system in an override file it might be handy. It's fractionally less messy to my mind than manually backporting system libraries!
> Third thing on my wishlist might be a log entry for denied syscalls
> somewhere ..
Hmm, this would make a ton of sense. We currently have a "log" seccomp
action, but it will just log and allow anyway. we'd need another
action that would log and refuse. Please file an RFE, or even better
prep a PR for this!
Looking at the kernel seccomp doc, I'm not actually sure it's possible, from code at least:
S.
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
