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:

[...]

quoted

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.

quoted

Can be checked here:
https://lore.kernel.org/netdev/d9aa57a7-9978-d0a4-3aa0-4512fd9459df@digikod.net (local) 


Hope I exlained my point. Thanks again for your comments.

[...]