[systemd-devel] How to disable seccomp in systemd-nspawn?
Hi, How to disable seccomp in systemd-nspawn? I'm facing issue while running fuse-overlayfs and I reported it https://github.com/containers/fuse-overlayfs/issues/220#issuecomment-648865831 Developer asked me to check if the container is seccomp filtered, as suspected systemd-nspawn put the container inside seccomp faltered (Seccomp: 2). But I'm not able to get the list of filtered syscalls or I'm not able to find out why 'openat2()' is returning EPERM inside the systemd-nspawn container. Thanks, Mohan R ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Seccomp filters from file
On Mi, 24.06.20 09:02, Chris PeBenito (chpeb...@linux.microsoft.com) wrote: > On 6/23/20 10:57 AM, Lennart Poettering wrote: > > On Di, 23.06.20 09:41, Chris PeBenito (chpeb...@linux.microsoft.com) wrote: > > > > > I've got some challenges using systemd's seccomp support because it > > > conflicts with the way my system is managed. I need to manage the seccomp > > > SystemCallFilter lists in a central location (single directory) so that > > > they > > > can be updated independently of the packages and portable services on my > > > systems. Would there be any objections to a patch that would add a new > > > unit > > > option for loading the system call filter list out of a specified file? > > > > seccomp is still only supports plain bpf, not ebpf iirc. For some of > > the ebpf uses we noawadays support that you can upload your filter > > yourself and then make systemd use it: > > IPIngressFilterPath=/IPEgressFilterPath=. > > > > As soon as seccomp supports ebpf natively we could expose the same > > mechanism also for system call filtering, but until that happens I > > don't see any smart future-proof way to provide an interface for > > integrating your own filters with systemd. > > I don't understand your concern; can you clarify? Is it a concern about the > kernel ABI stability for seccomp? iiuc you cannot upload seccomp filters via the bpf() syscall, hence they cannot show up in bpffs either, but the IPIngressFilterPath= is built around bpffs paths... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Seccomp filters from file
On 6/23/20 10:57 AM, Lennart Poettering wrote: On Di, 23.06.20 09:41, Chris PeBenito (chpeb...@linux.microsoft.com) wrote: I've got some challenges using systemd's seccomp support because it conflicts with the way my system is managed. I need to manage the seccomp SystemCallFilter lists in a central location (single directory) so that they can be updated independently of the packages and portable services on my systems. Would there be any objections to a patch that would add a new unit option for loading the system call filter list out of a specified file? seccomp is still only supports plain bpf, not ebpf iirc. For some of the ebpf uses we noawadays support that you can upload your filter yourself and then make systemd use it: IPIngressFilterPath=/IPEgressFilterPath=. As soon as seccomp supports ebpf natively we could expose the same mechanism also for system call filtering, but until that happens I don't see any smart future-proof way to provide an interface for integrating your own filters with systemd. I don't understand your concern; can you clarify? Is it a concern about the kernel ABI stability for seccomp? -- Chris PeBenito ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 2/3] nsproxy: attach to namespaces via pidfds
On Wed, Jun 24, 2020 at 01:54:56PM +0200, Christian Brauner wrote: > Yep, I already have a fix for this in my tree based on a previous > report from LTP. Perfect. (Sorry for the noise then.) Thanks, Michal signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 2/3] nsproxy: attach to namespaces via pidfds
Hi.
On Tue, May 05, 2020 at 04:04:31PM +0200, Christian Brauner
wrote:
> -SYSCALL_DEFINE2(setns, int, fd, int, nstype)
> +SYSCALL_DEFINE2(setns, int, fd, int, flags)
> [...]
> - file = proc_ns_fget(fd);
> - if (IS_ERR(file))
> - return PTR_ERR(file);
> + int err = 0;
>
> - err = -EINVAL;
> - ns = get_proc_ns(file_inode(file));
> - if (nstype && (ns->ops->type != nstype))
> + file = fget(fd);
> + if (!file)
> + return -EBADF;
> +
> + if (proc_ns_file(file)) {
> + ns = get_proc_ns(file_inode(file));
> + if (flags && (ns->ops->type != flags))
> + err = -EINVAL;
> + flags = ns->ops->type;
> + } else if (pidfd_pid(file)) {
> + err = check_setns_flags(flags);
> + } else {
> + err = -EBADF;
> + }
> + if (err)
> goto out;
>
> - err = prepare_nsset(ns->ops->type, &nsset);
> + err = prepare_nsset(flags, &nsset);
> if (err)
> goto out;
This modification changed the returned error when a valid file
descriptor is passed but it doesn't represent a namespace (nor pidfd).
The error is now EBADF although originally and per man page it
was/should be EINVAL.
A change like below would restore it, however, I see it may be less
consistent with other pidfd calls(?), then I'd suggest updating the
manpage to capture this.
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -531,7 +531,7 @@ SYSCALL_DEFINE2(setns, int, fd, int, flags)
} else if (!IS_ERR(pidfd_pid(file))) {
err = check_setns_flags(flags);
} else {
- err = -EBADF;
+ err = -EINVAL;
}
if (err)
goto out;
I noticed this breaks systemd self tests [1].
Regards,
Michal
[1]
https://github.com/systemd/systemd/blob/a1ba8c5b71164665ccb53c9cec384e5eef7d3689/src/test/test-seccomp.c#L246
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
