On Thu, Nov 12, 2020 at 9:51 PM Mickaël Salaün mic@digikod.net wrote:
A Landlock ruleset is mainly a red-black tree with Landlock rules as nodes. This enables quick update and lookup to match a requested access, e.g. to a file. A ruleset is usable through a dedicated file descriptor (cf. following commit implementing syscalls) which enables a process to create and populate a ruleset with new rules.
A domain is a ruleset tied to a set of processes. This group of rules defines the security policy enforced on these processes and their future children. A domain can transition to a new domain which is the intersection of all its constraints and those of a ruleset provided by the current process. This modification only impact the current process. This means that a process can only gain more constraints (i.e. lose accesses) over time.
Cc: James Morris jmorris@namei.org Cc: Jann Horn jannh@google.com Cc: Kees Cook keescook@chromium.org Cc: Serge E. Hallyn serge@hallyn.com Signed-off-by: Mickaël Salaün mic@linux.microsoft.com
Changes since v23:
- Always intersect access rights. Following the filesystem change logic, make ruleset updates more consistent by always intersecting access rights (boolean AND) instead of combining them (boolean OR) for the same layer.
This seems wrong to me. If some software e.g. builds a policy that allows it to execute specific libraries and to open input files specified on the command line, and the user then specifies a library as an input file, this change will make that fail unless the software explicitly deduplicates the rules. Userspace will be forced to add extra complexity to work around this.
This defensive approach could also help avoid user space to inadvertently allow multiple access rights for the same object (e.g. write and execute access on a path hierarchy) instead of dealing with such inconsistency. This can happen when there is no deduplication of objects (e.g. paths and underlying inodes) whereas they get different access rights with landlock_add_rule(2).
I don't see why that's an issue. If userspace wants to be able to access the same object in different ways for different purposes, it should be able to do that, no?
I liked the semantics from the previous version.