Message-ID: <263c1eb3-602f-57fe-8450-3f138581bee7@digikod.net>
Date: Thu, 13 Jul 2023 16:52:55 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: "Konstantin Meskhidze (A)" <konstantin.meskhidze@...wei.com>,
 Jeff Xu <jeffxu@...gle.com>
Cc: Jeff Xu <jeffxu@...omium.org>, Günther Noack
 <gnoack@...gle.com>, Günther Noack <gnoack3000@...il.com>,
 willemdebruijn.kernel@...il.com, linux-security-module@...r.kernel.org,
 netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
 yusongping@...wei.com, artem.kuzin@...wei.com,
 Jorge Lucangeli Obes <jorgelo@...omium.org>,
 Allen Webb <allenwebb@...gle.com>, Dmitry Torokhov <dtor@...gle.com>
Subject: Re: [PATCH v9 00/12] Network support for Landlock - allowed list of
 protocols


On 13/07/2023 15:20, Konstantin Meskhidze (A) wrote:
> 
> 
> 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@...ikod.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@...ikod.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@...ikod.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.

Correct, even if a port is not a *kernel* object.

> 
> 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???

Yes, it's possible an it's OK because the bind action was performed by 
an unsandboxed process. If this unsandboxed process is not trusted or if 
it can be fooled by a malicious client, the system should be designed to 
make it not able to talk to 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).
>> .

Powered by blists - more mailing lists