On 31/12/2021 00:23, Casey Schaufler wrote:

On 12/30/2021 2:50 PM, Mickaël Salaün wrote:

quoted

On 30/12/2021 18:59, Casey Schaufler wrote:

quoted

On 12/29/2021 6:56 PM, Konstantin Meskhidze wrote:

[...]

quoted

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.

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.

quoted

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.

quoted

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.

quoted

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

quoted

quoted

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.

quoted

quoted

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.

:)

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

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

quoted

quoted

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.

[...]