Support scoping abstract unix sockets

[WavyEbuilder]

Closes: #330

[WavyEbuilder]

Flag name is a bit long, but I couldn't think of a shorter one; open to suggestions.

[WavyEbuilder]

Ping

[rusty-snake]

Manpage should be updated too.

[WavyEbuilder]

I noticed some completions in the repo, so I've updated those as well.

[rusty-snake]

tabs vs. spaces

[WavyEbuilder]

How should it be indented then? I noticed that indentation, at least in my editor, in the file seems inconsistent, so I copied the --as-pid-1 section.

[rusty-snake]

you're right it is inconsistent. I just noticed strange indention in GH diff and --cap options looked good.

[smcv]

Please mimic the indentation of the better / more consistent options when adding new options. --cap-add and --cap-drop are better examples to follow.

[smcv]

The commit message should briefly describe why this is here. Presumably the main use-case is to be able to prevent sandboxed processes from accessing your Xorg/Xwayland server's listening socket, as on #330?

Landlock is an optional LSM (although it seems to be on-by-default in at least some distributions, perhaps many distributions - unlike the "big" LSMs AppArmor, SELinux and Smack, which are currently still mutually exclusive, so each distro has to choose no more than one of them to be the default, and if sysadmins are allowed to choose a different "big" LSM then they have to turn off the distro's default). This means we need to consider what will happen if the distro or sysadmin has turned it off, or if the kernel is too old to offer this feature.

At the moment, --scope-abstract-unix-sockets would "fail closed", refusing to start any apps that have that option in their sandboxing parameters. But bwrap is primarily designed to be used by higher-level frameworks like Flatpak, WebKitGTK and Glycin, rather than being used directly by end users, and I suspect that the maintainers of those frameworks would prefer to have a way to "fail open" - having your app run normally, but relying on Xauth to prevent access to the abstract X11 socket, seems like it would be better than nothing.

So do we need an accompanying --scope-abstract-unix-sockets-try option, similar to the relationship between --unshare-cgroup and --unshare-cgroup-try?

[smcv]

What does it mean to "scope" abstract sockets, more precisely? It's OK for the option name and the --help to be brief, but the man page should really give a little more detail about what this means.

If a process outside the sandbox (most commonly Xorg or Xwayland) listens on an abstract Unix socket, does this option prevent processes inside the sandbox from connecting to it, even in the absence of --unshare-net?

Conversely, if a process inside the sandbox listens on an abstract Unix socket, does this option prevent processes outside the sandbox from connecting to it, even in the absence of --unshare-net?

It would probably also be helpful to mention This has the same behaviour as LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET: see <citerefentry><refentrytitle>landlock</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details. but I think at least a brief summary of what this option does is also necessary here.

[WavyEbuilder]

I've included a brief summary of what it means to "scope", but not of what an abstract unix socket is. Would you like me to include that as well, or is it okay as is?

[smcv]

What kernel/glibc versions, if any, guarantee to have this header?

The build system should probably check for this header with cc.check_header('linux/landlock.h') and define HAVE_LANDLOCK_H, so that this can become

Suggested change

	#include <linux/landlock.h>
	#ifdef HAVE_LANDLOCK_H
	#include <linux/landlock.h>
	#endif

and then the use of Landlock features in the code can be something like (pseudocode)

if (opt_scope_abs_unix_sockets)
  {
#ifdef HAVE_LANDLOCK_H
    do Landlock things;
#else
    die ("Landlock not available at compile time, cannot implement --scope-abstract-unix-sockets");
#endif
  }

[WavyEbuilder]

Not sure about the exact version, but the header was introduced by Linux in cb2c7d1a1776057c9a1f48ed1250d85e94d4850d on Thu Apr 22 17:41:17 2021. Regardless, I also agree that we should have this as a check and guard it, so I'll wire that up.

[smcv]

For this initial review pass I've assumed that you didn't change the --help except for re-indenting. I'm leaving this comment as a reminder that someone still needs to check this.

[WavyEbuilder]

Should be a non-issue now that we've changed the option name to be shorter.

[smcv]

Please mimic the indentation of the better / more consistent options when adding new options. --cap-add and --cap-drop are better examples to follow.

[smcv]

This name is rather long, as you said. --scope-abstract-af-unix would be shorter, perhaps? Or --scope-abstract-sockets since there is no other type of socket with the abstract vs. path-based distinction?

[WavyEbuilder]

Personally I prefer --scope-abstract-af-unix (which seems reasonable to me). I'll change it to that unless the other option is preferred.

[smcv]

.