[PATCH v9 00/12] Network support for Landlock - allowed list of protocols

[Mickaël Salaün]

On 05/07/2023 17:00, Jeff Xu wrote:
> On Fri, Jun 30, 2023 at 11:23 AM Mickaël Salaün <mic at digikod.net> wrote:
>>
>>
>> On 30/06/2023 06:18, Jeff Xu wrote:
>>> On Thu, Jun 29, 2023 at 4:07 AM Mickaël Salaün <mic at digikod.net> wrote:
>>>>
>>>>
>>>> On 29/06/2023 05:18, Jeff Xu wrote:
>>>>> resend.
>>>>>
>>>>> On Wed, Jun 28, 2023 at 12:29 PM Mickaël Salaün <mic at digikod.net> wrote:
>>>>>>
>>>>>>
>>>>>> On 28/06/2023 19:03, Jeff Xu wrote:

[...]

>> The sandboxing/Landlock threat model is to restrict a process when it is
>> sandboxed, but this sandboxing is a request from the same process (or
>> one of its parent) that happen when it is more trustworthy (or at least
>> has more privileges) than after it sandbox itself.
>>
>> The process sandboxing itself can use several kernel features, and one
>> of it is Landlock. In any case, it should take care of closing file
>> descriptors that should not be passed to the sandboxed process.
>>
> Agree.
> 
>> The limits of sandboxing are the communication channels from and to
>> outside the sandbox. The peers talking with sandboxed processes should
>> then not be subject to confused deputy attacks, which means they must
>> not enable to bypass the user-defined security policy (from which the
>> Landlock policy is only a part). Receiving file descriptors should then
>> not be more important than controlling the communication channels. If a
>> not-sandboxed process is willing to give more right to a sandboxed
>> process, by passing FDs or just receiving commands, then this
>> not-sandboxed process need to be fixed.
>>
>> This is the rationale to not care about received nor sent file
>> descriptors. The communication channels and the remote peers must be
>> trusted to not give more privileges to the sandboxed processes.
>>
>> If a peer is malicious, it doesn't need to pass a file descriptor to the
>> sandboxed process, it can just read (data) commands and apply them to
>> its file descriptors.
> 
> I see the reasoning. i.e. sandboxing the process is not more
> important than securing communication channels, or securing the peer.
> 
> So in a system that let a peer process to pass a socket into a
> higher privileged process, when the communication channel or the peer
> process is compromised,  e.g. swapping the fd/socket into a different
> one that the attacker controls, confuse deputy attack can happen. The
> recommendation here is to secure peer and communication.
> I agree with this approach in general.  I need to think about how it
> applies to specific cases.
> 
>> I think the ability to pass file descriptors
>> should be seen as a way to improve performance by avoiding a user space
>> process to act as a proxy receiving read/write commands and managing
>> file descriptors itself. On the other hand, file descriptors could be
>> used as real capabilities/tokens to manage access, but senders still
>> need to be careful to only pass the required ones.
>>
>> All this to say that being able to restrict actions on file descriptors
>> would be useful for senders/services to send a subset of the file
>> descriptor capabilities (cf. Capsicum), but not the other way around.
>>
> In the Landlock kernel doc:
> Similarly to file access modes (e.g. O_RDWR), Landlock access rights
> attached to file descriptors are retained even if they are passed
> between processes (e.g. through a Unix domain socket). Such access
> rights will then be enforced even if the receiving process is not
> sandboxed by Landlock. Indeed, this is required to keep a consistent
> access control over the whole system, and this avoids unattended
> bypasses through file descriptor passing (i.e. confused deputy
> attack).
> 
> iiuc, the design for file and socket in landlock is different. For
> socket, the access rules are applied only to the current process (more
> like seccomp), while for file restriction, the rules can be passed
> into another un-landlocked process.

The O_RDWR restrictions are enforced by the basic kernel access control, 
not Landlock. However, for file truncation, Landlock complements the 
basic kernel access rights and behave the same.

There is indeed slight differences between file system and socket 
restrictions. For the file system, a file descriptor is a direct access 
to a file/data. For the network, we cannot identify for which data/peer 
a newly created socket will give access to, we need to wait for a 
connect or bind request to identify the use case for this socket. We 
could tie the access rights (related to ports) to an opened socket, but 
this would not align with the way Landlock access control works for the 
file system. Indeed, a directory file descriptor may enable to open 
another file (i.e. a new data item), but this opening is restricted by 
Landlock. A newly created socket gives access to the network (or a 
subset of it), but binding or connecting to a peer (i.e. accessing new 
data) is restricted by Landlock. Accesses tied to FDs are those that 
enable to get access to the underlying data (e.g. read, write, 
truncate). A newly created socket is harmless until it is connected to a 
peer, similarly to a memfd file descriptor. A directory opened by a 
sandboxed process can be passed to a process outside this sandbox and it 
might be allowed to open a relative path/file, which might not be the 
case for the sandboxed process.

I think it might be summarize by the difference between underlying FD 
data in the case of a regular file (i.e. tied access rights), and 
relative new data in the case of a directory or a socket (i.e. 
sandboxing policy scope).