On Tue, Apr 30, 2024 at 05:24:45PM +0200, Mickaël Salaün wrote:

On Wed, Apr 10, 2024 at 04:24:30PM -0600, Tahera Fahimi wrote:

quoted

On Tue, Apr 02, 2024 at 11:53:09AM +0200, Mickaël Salaün wrote:

quoted

Thanks for this patch.  Please CC the netdev mailing list too, they may
be interested by this feature. I also added a few folks that previously
showed their interest for this feature.

On Thu, Mar 28, 2024 at 05:12:13PM -0600, TaheraFahimi wrote:

quoted

Abstract unix sockets are used for local interprocess communication without
relying on filesystem. Since landlock has no restriction for connecting to
a UNIX socket in the abstract namespace, a sandboxed process can connect to
a socket outside the sandboxed environment. Access to such sockets should
be scoped the same way ptrace access is limited.

This is good but it would be better to explain that Landlock doesn't
currently control abstract unix sockets and that it would make sense for
a sandbox.

quoted

For a landlocked process to be allowed to connect to a target process, it
must have a subset of the target process’s rules (the connecting socket
must be in a sub-domain of the listening socket). This patch adds a new
LSM hook for connect function in unix socket with the related access rights.

Because of compatibility reasons, and because Landlock should be
flexible, we need to extend the user space interface.  As explained in
the GitHub issue, we need to add a new "scoped" field to the
landlock_ruleset_attr struct. This field will optionally contain a
LANDLOCK_RULESET_SCOPED_ABSTRACT_UNIX_SOCKET flag to specify that this
ruleset will deny any connection from within the sandbox to its parents
(i.e. any parent sandbox or not-sandboxed processes).

quoted

Thanks for the feedback. Here is what I understood, please correct me if
I am wrong. First, I should add another field to the
landlock_ruleset_attr (a field like handled_access_net, but for the unix
sockets) with a flag LANDLOCK_ACCESS_UNIX_CONNECT (it is a flag like
LANDLOCK_ACCESS_NET_CONNECT_TCP but fot the unix sockets connect).

That was the initial idea, but after thinking more about it and talking
with some users, I now think we can get a more generic interface.

Because unix sockets, signals, and other IPCs are fully controlled by
the kernel (contrary to inet sockets that get out of the system), we can
add ingress and egress control according to the source and the
destination.

To control the direction we could add an
LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_RECEIVE and a
LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_SEND rights (these names are a bit
long but at least explicit).  To control the source and destination, it
makes sense to use Landlock domain (i.e. sandboxes):
LANDLOCK_DOMAIN_HIERARCHY_PARENT, LANDLOCK_DOMAIN_HIERARCHY_SELF, and
LANDLOCK_DOMAIN_HIERARCHY_CHILD.  This could be used by extending the
landlock_ruleset_attr type and adding a new
landlock_domain_hierarchy_attr type:

struct landlock_ruleset_attr ruleset_attr = {
  .handled_access_dom = LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_RECEIVE | \
                        LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_SEND,
}

// Allows sending data to and receiving data from processes in the same
// domain or a child domain, through abstract unix sockets.
struct landlock_domain_hierarchy_attr dom_attr = {
  .allowed_access = LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_RECEIVE | \
                    LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_SEND,
  .relationship = LANDLOCK_DOMAIN_HIERARCHY_SELF | \
                  LANDLOCK_DOMAIN_HIERARCHY_CHILD,
};

It should also work with other kind of IPCs:
* LANDLOCK_ACCESS_DOM_UNIX_PATHNAME_RECEIVE/SEND (signal)
* LANDLOCK_ACCESS_DOM_SIGNAL_RECEIVE/SEND (signal)
* LANDLOCK_ACCESS_DOM_XSI_RECEIVE/SEND (XSI message queue)
* LANDLOCK_ACCESS_DOM_MQ_RECEIVE/SEND (POSIX message queue)
* LANDLOCK_ACCESS_DOM_PTRACE_RECEIVE/SEND (ptrace, which would be
  limited)

What do you think?

Indeed, in the case of abstract Unix sockets, both parties can send and
receive data when a connection is established. Therefore, we can define
a single LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT to represent the right to
share data, regardless of direction. However, we should still retain
LANDLOCK_DOMAIN_HIERARCHY for SELF, PARENT, and CHILD, as the source and
destination are important. 
As you said, I believe we should have receive and send rights for
another kind of IPCs (which will be used for landlock#8 issue)