Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C library #38

Open
l0kod opened this issue Jul 2, 2024 · 2 comments
Open

C library #38

l0kod opened this issue Jul 2, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@l0kod
Copy link
Member

l0kod commented Jul 2, 2024

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:

  • Linux is written in C and kernel developers can easily review such code,
  • we have a test framework that would be useful to test this library and ease some kernel tests writing,
  • it eases maintenance to update the kernel code and user space library with the same review, and
  • it makes sense to use the Linux repository as the authority for "landlock_" symbol prefixes (because the libc doesn't provide wrappers for Landlock syscalls).

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

@l0kod l0kod added the enhancement New feature or request label Jul 2, 2024
@l0kod l0kod added this to Landlock Jul 2, 2024
@l0kod l0kod moved this to Ready in Landlock Jul 2, 2024
@gnoack
Copy link
Member

gnoack commented Jul 8, 2024

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.

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
Copy link
Member Author

l0kod commented Jul 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Ready
Development

No branches or pull requests

2 participants