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@xxxxxxxxxxx
Hope I exlained my point. Thanks again for your comments.
[...]
