Message-ID: <a24ffb44-8f3c-e043-61fa-3652e3e648b1@digikod.net>
Date:   Fri, 31 Dec 2021 01:00:00 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     Casey Schaufler <casey@...aufler-ca.com>,
        Konstantin Meskhidze <konstantin.meskhidze@...wei.com>
Cc:     linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
        netfilter@...r.kernel.org, yusongping@...wei.com,
        artem.kuzin@...wei.com
Subject: Re: [RFC PATCH 0/1] Landlock network PoC


On 31/12/2021 00:23, Casey Schaufler wrote:
> On 12/30/2021 2:50 PM, Mickaël Salaün wrote:
>>
>> On 30/12/2021 18:59, Casey Schaufler wrote:
>>> On 12/29/2021 6:56 PM, Konstantin Meskhidze wrote:
>>
>> [...]
>>
>>>
>>>> But I agree, that socket itself (as collection of data used for 
>>>> interproccess communication) could be not be an object.
>>>>
>>>> Anyway, my approach would not work in containerized environment: 
>>>> RUNC, containerd ect. Mickaёl suggested to go another way for 
>>>> Landlock network confinement: Defining "object" with connection port.
>>>
>>> Oh, the old days of modeling ...
>>>
>>> A port number is a name. It identifies a subject. A subject
>>> "names" itself by binding to a port number. The port itself
>>> isn't a thing.
>>
>> It depends on the definition of subject, object and action.
> 
> You are correct. And I am referring to the classic computer security
> model definitions.

Me too! :)

> If you want to redefine those terms to justify your
> position it isn't going to make me very happy.
> 
> 
>> The action can be connect or bind,
> 
> Nope. Sorry. Bind isn't an "action" because it does not involve a subject
> and an object.

In this context, the subject is the process calling bind. In a 
traditional model, we would probably identify the socket as the object 
though.

> 
>> and the object a TCP port,
> 
> As I pointed out earlier, a port isn't an object, it is a name.
> A port as no security attributes. "Privileged ports" are a convention.
> A port is meaningless unless it is bond, in which case all meaning is
> tied up with the process that bound it.

A port is not a kernel object, but in this case it can still be defined 
as an (abstract) object in a security policy. I think this is the 
misunderstanding here.

> 
> 
>> i.e. a subject doing an action on an object may require a 
>> corresponding access right.
> 
> You're claiming that because you want to restrict what processes can
> bind a port, ports must be objects. But that's not what you're doing here.
> You are making the problem harder than it needs to be
> 
>>
>>>
>>> You could change that. In fact, Smack includes port labeling
>>> for local IPv6. I don't recommend it, as protocol correctness
>>> is very difficult to achieve. Smack will forgo port labeling
>>> as soon as CALIPSO support (real soon now - priorities permitting)
>>> is available.
>> Please keep in mind that Landlock is a feature available to 
>> unprivileged (then potentially malicious) processes. I'm not sure 
>> packet labeling fits this model, but if it does and there is a need, 
>> we may consider it in the future. Let's first see with Smack. ;)
>>
>> Landlock is also designed to be extensible. It makes sense to start 
>> with an MVP network access control. Being able to restrict TCP connect 
>> and bind actions, with exception for a set of ports, is simple, 
>> pragmatic and useful. Let's start with that.
> 
> I'm not saying it isn't useful, I'm saying that it has nothing to do
> with subjects, objects and accesses. A process changing it's own state
> does not require access to any object.
> 
>>
>>>
>>> Again, on the other hand, you're not doing anything that's an
>>> access control decision. You're saying "I don't want to bind to
>>> port 3920, stop me if I try".
>>
>> This is an access control.
> 
> No.

:)

> 
>> A subject can define restrictions for itself and others (e.g. future 
>> child processes).
> 
> The "others" are subjects whose initial state is defined to be the
> state of the parent at time of exec. This is trivially modeled.

This doesn't change much.

> 
>> We may also consider that the same process can transition from one 
>> subject to another over time.
> 
> No, you cannot. A process pretty well defines a subject on a Linux system.
> Where the blazes did you get this notion?

I'm thinking in a more abstract way. I wanted to give this example 
because of your thinking about what is an access control or not. We 
don't have to tie semantic to concrete kernel data/objects. Because a 
process fits well to a subject for some use cases, it may not for 
others. In the end it doesn't matter much.

> 
>> This may be caused by a call to landlock_restrict_self(2) or, more 
>> abstractly, by an exploited vulnerability (e.g. execve, ROP…). Not 
>> everyone may agree with this lexical point of view (e.g. we can 
>> replace "subject" with "role"…), but the important point is that 
>> Landlock is an access control system, which is not (only) configured 
>> by the root user.
> 
> No. Landlock is a mechanism for processes to prevent themselves from 
> performing
> operations they would normally be allowed. No access control, subjects or
> objects are required to do this is many cases. Including bind.

I don't agree. An access control is a mechanism, backed by a security 
policy, which enforces restrictions on a system. Landlock is a way to 
drop privileges but also to enforce a set of security policies. We can 
see Smack, SELinux or others as a way for root to drop privileges too 
and for other users to restrict accesses they could have otherwise.

> 
>>
>>> All you're doing is asking the
>>> kernel to remember something for you, on the off chance you
>>> forget. There isn't any reason I can see for this to be associated
>>> with the port. It should be associated with the task.
>>
>> I don't understand your point. What do you want to associate with a 
>> task? Landlock domains are already tied to a set of tasks.
> 
> That's pretty much what I'm saying. It's all task data.

OK

> 
>>
>>>
>>>> Can be checked here:
>>>> https://lore.kernel.org/netdev/d9aa57a7-9978-d0a4-3aa0-4512fd9459df@digikod.net 
>>>>
>>>>
>>>> Hope I exlained my point. Thanks again for your comments.
>>
>> [...]

Powered by blists - more mailing lists