<div dir="ltr"><div dir="ltr">On Sun, 16 Aug 2020 at 15:47, Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it would be wise to use do fallback logic for EPERM too. It's<br>
the error that nspawn uses since day #1 basically. I am a bit puzzled<br>
noone noticed this before, afaik glibc test cases at least on Fedora<br>
(where most glibc upstream devs work on) run in nspawn, so how did<br>
noone notice?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>I suspect trying to convince glibc maintainers to check for EPERM could turn into a holy war quite quickly :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> A rule of thumb might be to return ENOSYS for anything libseccomp doesn't<br>
> know about - is it possible to look things up that way around?<br>
<br>
libseccomp doesn't allow us to install filters for syscalls it doesn't<br>
know anyway iirc...<br>
<br>
Not sure I follow though? Why would that help?<br></blockquote><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Another useful thing might be to allow whitelisting by syscall number -<br>
> again don't know if seccomp allows this. Would allow easier work arounds in<br>
> cases like this without having to go off and backport libseccomp...<br>
<br>
syscall numbers are highly arch dep, we currently don't support that<br>
because you cannot reasonably express this in unit files, as they'd<br>
become very much arch dependent then.<br>
<br>
That said, I'd be happy to review/merge a patch that adds a syntax<br>
where you could spell out SystemCallFilter=x86-64:345 for example,<br>
i.e. specify arch plus syscall nr. But it's still ugly, since it would<br>
do result in different filers on different archs.<br></blockquote><div><br></div><div>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!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Third thing on my wishlist might be a log entry for denied syscalls<br>
> somewhere ..<br>
<br>
Hmm, this would make a ton of sense. We currently have a "log" seccomp<br>
action, but it will just log and allow anyway. we'd need another<br>
action that would log and refuse. Please file an RFE, or even better<br>
prep a PR for this!<br></blockquote><div><br></div><div>Looking at the kernel seccomp doc, I'm not actually sure it's possible, from code at least:</div><div><br></div><div><a href="https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html">https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html</a><br></div><div><br></div>But there is  /proc/sys/kernel/seccomp/actions_logged which might do the trick!</div><div class="gmail_quote"><br></div><div class="gmail_quote">S.</div></div>