landlock-lsm / linux

Linux kernel - See Landlock issues
https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git/
Other
33 stars 9 forks source link

C library #38

Open l0kod opened 2 weeks ago

l0kod commented 2 weeks ago

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).

gnoack commented 1 week 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:

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. :)

l0kod commented 5 days 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:

  • 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_attrs 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.