netdev - Re: [RFC PATCH 0/1] Landlock network PoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bf9e42b5-5034-561e-b872-7ab20738326b@digikod.net>
Date:   Thu, 30 Dec 2021 23:50:04 +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 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. The action 
can be connect or bind, and the object a TCP port, i.e. a subject doing 
an action on an object may require a corresponding access right.

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

> 
> 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. A subject can define restrictions for itself 
and others (e.g. future child processes). We may also consider that the 
same process can transition from one subject to another over time. 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.

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

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

[...]