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

[Konstantin Meskhidze (A)]

7/12/2023 2:30 PM, 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 would like to mention that in case of files a Landlock rule is tied 
to undreliying file's inode ( already existing at the moment of creating
    a landlock's rule), and it's impossible to tie a new landlock rule 
to a socket before it's creating. Thats why all network access rules 
work with "port objects", representing network connections.

I was thinking about sendind socket's FD to another process.
If one process creates a socket and binds it to some port N. Then it 
sends socket's FD to a landlocked process with rule restricting to bind
to port N. Is this situation theoretically possible???


> 
> 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).
> .