Open l0kod opened 4 months ago
https://github.com/gnoack/landlock-examples/blob/main/landlock_compat.h
I've tried to find out what a "minimal" C library would need to look like, by growing it from the surrounding CLI tool examples.
The way I see this, we have two main complications:
To determine the right ruleset, you can source a ruleset in one of these ways:
Based on these rulesets, you can build the least common denominator between these with a helper function that applies bitwise-AND on the struct.
In previous versions, I've played with helper functions that do more of that at the same time, but I'm currently leaning towards exposing a bit more of Landlock's internals, but providing some more orthogonal helper functions and good documentation. The helpers offer the following things:
struct landlock_ruleset_attr
by ABI version (compatibility table).
struct landlock_ruleset_attr
s into one (bitwise-AND on all fields)landlock_get_abi()
to determine the best ABI version.
Apart from that, it's still slightly annoying that syscalls need to be called with syscall()
.
And yes, I should absolutely move this into the kernel samples directory or into the landlock-lsm Github organization. :)
https://github.com/gnoack/landlock-examples/blob/main/landlock_compat.h
I've tried to find out what a "minimal" C library would need to look like, by growing it from the surrounding CLI tool examples.
The way I see this, we have two main complications:
- Determining the right ruleset to enable.
- Dealing with the "refer" special case.
To determine the right ruleset, you can source a ruleset in one of these ways:
- Use the ruleset that characterizes a given (hardcoded) ABI version
- Look up the best ruleset that can be used on the currently running system, and look it up by ABI version
- Define your own ruleset (for instance, if you only want to restrict file access)
Based on these rulesets, you can build the least common denominator between these with a helper function that applies bitwise-AND on the struct.
In previous versions, I've played with helper functions that do more of that at the same time, but I'm currently leaning towards exposing a bit more of Landlock's internals, but providing some more orthogonal helper functions and good documentation. The helpers offer the following things:
Look up a
struct landlock_ruleset_attr
by ABI version (compatibility table).
- This is just exposed as an array.
- Combine two
struct landlock_ruleset_attr
s into one (bitwise-AND on all fields)
landlock_get_abi()
to determine the best ABI version.
- Guaranteed to return a number >= 0, where 0 means "unsupported". The result can be used as an index into the ABI table.
Great idea! I like this landlock_min_ruleset_attr()
.
Apart from that, it's still slightly annoying that syscalls need to be called with
syscall()
.
Yes, this C library should declare the Landlock syscalls with proper names.
And yes, I should absolutely move this into the kernel samples directory or into the landlock-lsm Github organization. :)
As explain above, this C library should live close to the kernel source code, in the same Git repository, but we should make it easy to synchronize with a dedicated GitHub repository that would be used by downstream.
While we have good libraries (e.g. Rust, Go, Haskell...) we need a C library. I'd like this library to be light and only provide a set of small helpers for common use cases (e.g. drop all access rights according to a Landlock ABI version).
We already wrote most of the mechanic with the sandboxer tool and tests, and we could move some part of this code into a standalone library.
This C library should live close to the kernel source code, in the same Git repository, because:
To ease consumption of this C library, we should also have a dedicated repository in this GitHub organization, synchronized with the code hosted by the kernel repository, similar to libbpf (but simpler).