nicolast / landlock-hs

Haskell bindings for the Linux Landlock API

landlock-hs: Haskell bindings for the Linux Landlock API

The Linux kernel Landlock API provides unprivileged access control. The goal of Landlock is to enable to restrict ambient rights (e.g. global filesystem access) for a set of processes. Because Landlock is a stackable LSM, it makes possible to create safe security sandboxes as new security layers in addition to the existing system-wide access-controls. This kind of sandbox is expected to help mitigate the security impact of bugs or unexpected/malicious behaviors in user space applications. Landlock empowers any process, including unprivileged ones, to securely restrict themselves.

This projects provides the following Haskell libraries to use this API:

• landlock, Haskell binding for the Linux Landlock API
• psx, a package to integrate libpsx with the GHC RTS

For more information, see the Landlock homepage and its kernel documentation.

landlock-hs's Issues

Fix documentation on Hackage

For some reason, the API documentation as hosted on Hackage doesn't include all docs. As an example, the constructors of AccessFsFlag don't have their associated docstrings. However, a local render of the docs (either as-is, or using --haddock-for-hackage, then unpacking the resulting tarball and opening the HTML pages) included the desired information.

Document issue with multiple threads

In Linux, security contexts and related things are kept per-thread by the kernel, even though users (and POSIX) expect many of them to be per-process. As an example, when one calls setuid(...), one expects the whole process, including all its threads (some the application author may not even know to exist) to now run as the new UID, not only the thread performing the syscall.

Within Glibc and other libc's, there's code in place to make setuid, setgid and other calls to behave as expected/required: instead of simply invoking the syscall in the calling thread, the syscall is invoked in all threads of the process, through a bunch of highly tricky code involving signals and whatnot. This is known as the setxid issue.

The Landlock API has the very same problem with landlock_restrict_self (and its prerequisite prctl(PR_SET_NO_NEW_PRIVS, ...)): the restrictions are applied only to the thread invoking landlock_restrict_self, not all pre-existing threads in a process. Hence, even after invoking landlock_restrict_self, some other threads would still be able to access files etc. which were supposed to be restricted.

The Glibc machinery to run some syscall in all threads is not exposed, and can hence not be repurposed. There's a library, libpsx, part of libcap (which struggles from the exact same setxid problem) which provides a user-facing API to run some syscalls in all pre-existing threads, relying on some linker functionality to hook into pthread_create. However, when attempting to use libpsx with a GHC Haskell program, things don't work out, potentially due to how libpsx and the GHC RTS interact, or maybe some bug(s) in the RTS, not expecting some function calls to be interrupted by SIGSYS.

In Golang, the syscall.AllThreadsSyscall function was added to invoke some syscall in all OS threads managed by the Go runtime. If GHC were to have a similar feature, the setxid problem of landlock_restrict_self could be fixed trivially (assuming no OS threads were created using other means).

Alternatively, if Glibc gets built-in bindings for landlock_restrict_self which uses the setxid functionality under the hood, we could use this instead of invoking the syscall directly.

For now, this issue is documented in the API docs, and the library will throw an exception when using landlock with the threaded RTS.

See https://github.com/NicolasT/landlock-hs/blob/f22b7e4450991f7cdbec37271f56550c1d747b10/test/ThreadedScenario.hs for a scenario exposing the issue (when using the threaded RTS).

See also a related article by Kazu Yamamoto at https://kazu-yamamoto.hatenablog.jp/entry/2020/12/04/141308.

See: golang/go#1435
See: https://ewontfix.com/17/
See: https://sites.google.com/site/fullycapable/who-ordered-libpsx
See: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/psx

Add example code to `README.md` and run as a test

Extend README.md with some sample code, and execute it as part of the test-suite.