Bidirectional scoping for abstract unix sockets

[xokdvium]

This is more of a question/discussion than a concrete proposal.

#7 and LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET that stemmed from that works only in the one direction: sandboxed processes can restrict themselves from being able to connect to outside resources. This works well for the threat model where there are no malicious unsandboxed processes. But if there are malicious cooperating sandboxed and an unsandboxed process, the connection order could be reversed to make the unsandboxed one connect to an abstract socket created by the landlocked process. The only way to mitigate that threat is to either unshare network namespaces (and require userspace networking like slirp4netns or pasta if one wants to give network access to the sandbox).

It would be quite useful (and avoid the userspace networking complexity and overhead) to be able to restrict a sandboxed process from being able to accept incoming connections from outside the sandbox - having connection process get a ECONNREFUSED or EACCES e.g. That way the primary headache of abstract sockets - passing file descriptors via SCM_RIGHTS - could be fully mitigated via landlock. As noted in the threads from #7, using seccomp for this turns out to be quite complex and racy.

I'm framing it this way, because if such a feature was implemented, then it would be quite a big change for the landlock model of only restricting the sandboxed thread/process. Nevertheless, such functionality would provide a very convenient and robust way of completely scoping IPC access.

It's not clear to me whether this approach would align with Landlock semantics.

An alternative solution might be to disallow sending messages to outside processes (including SCM_RIGHTS) - not preventing processes from the outside from connecting. This would be more in-line with existing precedent, yet less complete - an outside process could still smuggle file descriptors into the sandbox - even for something that the sandbox couldn't access due to FS landlock restrictions.

[xokdvium]

Hm, I guess another angle for this is being able to drop the capability for accepting connections from processes from unrelated domains in the sandbox.

[gnoack]

If there is a malicious unsandboxed process, the possibility of that process connecting to a sandboxed process is the least of my worries.

Landlock has a hierarchical security model that is aligned with the hierarchy of nested Landlock domains (enforced Landlock policies). It constrains the processes within these domains further and further with each nesting level, but it does not constrain processes on the outside.

When phrased the other way around, as in #57 (comment), it makes a bit more sense to me, as it would impose a restriction on the sandboxed process and not on a process outside of that sandbox. However, it is not fully clear how that provides much additional strict guarantees, since processes in more privileged sandbox domains anyway have much broader powers over the sandboxed process (i.e. they can ptrace and debug it, poking around in its memory).

In the big scheme of things for Landlock networking features, I am a bit worried that we will drown in a long list of address-family-specific special access rights, but are forgetting about the bigger picture.

The feature request #6 aims to restrict the creation of socket FDs based on address family and socket type, and would be a broader and more comprehensive restriction. Would that help in your use case as well?

[xokdvium]

If there is a malicious unsandboxed process, the possibility of that process connecting to a sandboxed process is the least of my worries.

Yeah, I was a bit cautious about the phrasing, since this isn't exactly what Landlock is for. Maybe this would make more sense if I explain the situation a bit more:

With the Nix package manager, a privileged process manages the sandboxes. Certain types of builds need network access to download sources with a predefined hash, so they run in the hosts network namespace (we want those to also work with unprivileged userns, thus the only reasonable way would be to do the same thing unprivileged container runtimes do - i.e. userspace networking, which is a huge hammer). Unlike other types of sockets, abstract UDS expose a large surface via SCM_RIGHTS - network access is a design choice and it doesn't have the unfortunate capability to smuggle out file descriptors. Those unfortunately expose path traversal races on files that the sandbox creates and leaves behind for the privileged process to collect/register in the store/database.

(i.e. they can ptrace and debug it, poking around in its memory).

In our case, all the sandboxes are running as distinct users (via pre-created users or we have also been experimenting with systemd-nsresourced for the unpriviledged case), so ptracing them would require CAP_SYS_PTRACE.