permission-based actions?

[stsp]

Hi guys!

I am very new to landlock.
As far as I understand, the one can
allow the particular actions based on
a file path, but what I was looking
for, should also include permission
check.

That is, would it make sense to add
the actions like:
LANDLOCK_ACCESS_FS_WRITE_FILE_USER
LANDLOCK_ACCESS_FS_WRITE_FILE_GROUP
LANDLOCK_ACCESS_FS_WRITE_FILE_OTHER
so that I can eg allow the access only by
"Other" permission bits, but keep User and
Group denied for files in the specified dir?
More precisely, if I only use
LANDLOCK_ACCESS_FS_WRITE_FILE_OTHER
then User and Group checks are not enough
to grant the permission, but are only enough
to reject the permission.

In that semantic,
(LANDLOCK_ACCESS_FS_WRITE_FILE_USER |
LANDLOCK_ACCESS_FS_WRITE_FILE_GROUP |
LANDLOCK_ACCESS_FS_WRITE_FILE_OTHER) ==
LANDLOCK_ACCESS_FS_WRITE_FILE
I.e. specifying all 3 is similar to what
LANDLOCK_ACCESS_FS_WRITE_FILE does
right now. So basically its just a more
fine-grained control.

What do you think? Does something like this
make a sense?

[l0kod]

Hi,

It's interesting. I guess it would be an easy way to allow everything which is world-accessible and only focus on the sensitive files.

Currently Landlock is agnostic to the underlying filesystem access rigths, it just adds another layer of access control.

Because there may be several access checks (e.g. unix rights, ACLs...), I think it would make sense to be able to allow access to a file if everyone else can. However, doing the same only for unix's owner and group would be a special case that I'd prefer to avoid.

From an implementation point of view, it would be different than the current model: Landlock would need to check each inode (and their i_mode) from a path walk, which is not currently the case. It would make more sense once #9 is implemented.

Another thing to keep in mind is that even if a file allows e.g. read access to "others", this doesn't mean that anyone can access it because:

1. we need to be allowed to walk the rest of the path,
2. and SUID/SGID bits may remove permissions for a specific user or group (e.g. chmod 2604 denied-for-group.txt)

One drawback of this approach would be that a Landlock ruleset policy would not be enough to describe/understand the actually enforced access control, we'll need to know potentially every file's permissions.

[stsp]

Hi, thanks for considering!

However, doing the same only for unix's owner and group would be a special case that I'd prefer to avoid.

Its indeed not needed to, for
example, only disallow Other
access. I need to disallow Owner,
Groups and selectively supplementary
groups... I wonder if Landlock
is up to deal with supplementary
groups?
Currently I use suid/sgid bits
to switch to "nobody", but the
supplementary groups require
CAP_SETGID, which is a real
problem. And getting rid of
suid/sgid would be good too.

may remove permissions for a specific user or group

Yep, so any denial from Owner
or Group should be retained,
but the allowance should be
ignored.

we'll need to know potentially every file's permissions.

Yes, this seems a slight deviation
from what Landlock currently does,
which seems to be path-based
restrictions only. Whether or not
you can integrate the permission-based
model, or should it require a
completely different approach,
is an interesting question. :)
I personally would like to see
Landlock a fit-all solution.