On Tue, Oct 24, 2023 at 11:07:14AM -0500, Serge E. Hallyn wrote: > On Tue, Oct 24, 2023 at 10:29:17AM -0400, Paul Moore wrote: > > On Tue, Oct 24, 2023 at 10:18 AM Serge E. Hallyn <[email protected]> wrote: > > > On Tue, Oct 24, 2023 at 10:14:29AM -0400, Paul Moore wrote: > > > > On Tue, Oct 24, 2023 at 9:46 AM Serge E. Hallyn <[email protected]> > > > > wrote: > > > > > On Sun, Dec 18, 2022 at 08:29:10PM +0100, Stefan Bavendiek wrote: > > > > > > When building userspace application sandboxes, one issue that does > > > > > > not seem trivial to solve is the isolation of abstract sockets. > > > > > > > > > > Veeery late reply. Have you had any productive discussions about > > > > > this in > > > > > other threads or venues? > > > > > > > > > > > While most IPC mechanism can be isolated by mechanisms like mount > > > > > > namespaces, abstract sockets are part of the network namespace. > > > > > > It is possible to isolate abstract sockets by using a new network > > > > > > namespace, however, unprivileged processes can only create a new > > > > > > empty network namespace, which removes network access as well and > > > > > > makes this useless for network clients. > > > > > > > > > > > > Same linux sandbox projects try to solve this by bridging the > > > > > > existing network interfaces into the new namespace or use something > > > > > > like slirp4netns to archive this, but this does not look like an > > > > > > ideal solution to this problem, especially since sandboxing should > > > > > > reduce the kernel attack surface without introducing more > > > > > > complexity. > > > > > > > > > > > > Aside from containers using namespaces, sandbox implementations > > > > > > based on seccomp and landlock would also run into the same problem, > > > > > > since landlock only provides file system isolation and seccomp > > > > > > cannot filter the path argument and therefore it can only be used > > > > > > to block new unix domain socket connections completely. > > > > > > > > > > > > Currently there does not seem to be any way to disable network > > > > > > namespaces in the kernel without also disabling unix domain sockets. > > > > > > > > > > > > The question is how to solve the issue of abstract socket isolation > > > > > > in a clean and efficient way, possibly even without namespaces. > > > > > > What would be the ideal way to implement a mechanism to disable > > > > > > abstract sockets either globally or even better, in the context of > > > > > > a process. > > > > > > And would such a patch have a realistic chance to make it into the > > > > > > kernel? > > > > > > > > > > Disabling them altogether would break lots of things depending on > > > > > them, > > > > > like X :) (@/tmp/.X11-unix/X0). The other path is to reconsider > > > > > network > > > > > namespaces. There are several directions this could lead. For one, > > > > > as > > > > > Dinesh Subhraveti often points out, the current "network" namespace is > > > > > really a network device namespace. If we instead namespace at the > > > > > bind/connect/etc calls, we end up with much different abilities. > > > > > > > > The LSM layer supports access controls on abstract sockets, with at > > > > least two (AppArmor, SELinux) providing abstract socket access > > > > controls, other LSMs may provide controls as well. > > > > > > Good point. And for Stefan that may suffice, so thanks for mentioning > > > that. But The LSM layer is mandatory access control for use by the > > > admins. That doesn't help an unprivileged user. > > > > Individual LSMs may implement mandatory access control models, but > > that is not an inherent requirement imposed by the LSM layer. While > > the Landlock LSM does not (yet?) support access controls for abstract > > sockets, it is a discretionary access control mechanism.
A recent discussion focused on this topic: https://lore.kernel.org/all/[email protected]/ I'd like Landlock to be able to scope the use of unix sockets according to a Landlock domain the same way it is done for ptrace. This would make it possible to easily isolate unix sockets to a sandbox even by unprivileged processes (without any namespace change). I'd be happy to help implement such mechanism. > > In 2005, before namespaces were upstreamed, I posted the 'bsdjail' LSM, > which briefly made it into the -mm kernel, but was eventually rejected as > being an abuse of the LSM interface for OS level virtualization :) > > It's not 100% clear to me whether Stefan only wants isolation, or > wants something closer to virtualization. > > Stefan, would an LSM allowing you to isolate certain processes from > some abstract unix socket paths (or by label, whatever0 suffice for you? > > > I'm not currently aware of a discretionary access control LSM that > > supports abstract socket access control, but such a LSM should be > > possible if someone wanted to implement one. > > > > -- > > paul-moore.com
