HackerTrans
TopNewTrendsCommentsPastAskShowJobs

l0kod

no profile record

Submissions

Island: Linux sandboxing tool powered by Landlock

github.com
3 points·by l0kod·7 miesięcy temu·1 comments

comments

l0kod
·7 miesięcy temu·discuss
Island makes Landlock practical for everyday workflows by acting as a high-level wrapper and policy manager. Developed alongside the kernel feature and its Rust libraries, it bridges the gap between raw security mechanisms and user activity.
l0kod
·w zeszłym roku·discuss
Landlock supports scoped abstract UNIX socket: https://docs.kernel.org/userspace-api/landlock.html#ipc-scop...

Landlock doesn't use namespaces, they are orthogonal.
l0kod
·w zeszłym roku·discuss
Seccomp is not an access control system, but Landlock is. Seccomp limits the kernel attack surface and Landlock enforces an access control. They are complementary.

With Landlock, the access control is at the right layer, and the semantic is guaranteed to be the same even if the kernel gets new syscalls. Landlock is the closest thing to Pledge/Unveil we can get with the Linux constraints (and it is gaining new features).
l0kod
·w zeszłym roku·discuss
For instance, with Pledge, the "dns" promise is implemented with hardcoded path in the kernel. Linux is complex because it is versatile and flexible. Controlling access to such features requires some complexity and the kernel might not be enough.

About interfaces, another example is that Unveil is configured with path names but Landlock uses file descriptors instead (more flexible).

Also, these OpenBSD primitives only apply to the current executed binary, there is no nested sandboxes because the goal is not to create this kind of secure environment but mainly to secure a trusted binary.
l0kod
·w zeszłym roku·discuss
BSD systems ship a kernel and user space, which simplifies a lot of things. Linux is more flexible but it comes at a cost. Adding new security features can also be challenging for other reasons. Anyway, Landlock is one of these new security primitives, and it is gaining new features over time.

The Landlock interface must not change the underlying semantic of what is allowed or denied, otherwise it could break apps build for an older or a newer kernel. However, these apps should still use all the available security features. This is challenging.

Landlock provides a way to define fine-grained security policies. I would not say the kernel interface is complex (rather flexible), but what really matter are the user space library interfaces and how they can safely abstract complexity.
l0kod
·w zeszłym roku·discuss
Namespaces (used by containers) are very powerful but they are also a door to a large attack surface: https://lwn.net/Articles/673597/

Landlock is (only) an access control system, but it's designed to let any process use it, including potentially untrusted ones, which makes it suitable for any apps. It's close and complementary to seccomp.
l0kod
·w zeszłym roku·discuss
It takes time to develop theses features, but Landlock is gaining new network filtering features. We are working in a way to control socket creation according to their protocols, and also a way to filter UDP (which makes sense to developers and users).

From the point of view of an app developer, it might not make sense to filters peers but services (ports) instead, and filtering peers without their names would not be ideal (the kernel doesn't know about DNS, only IPs). Anyway, this feature might come one day if someone want to work on it, but we follow well-tested incremental development.

Netfiler is a privileged network feature that allows to do almost anything with the network, which makes it unsuitable for (app/unprivileged) sandboxing.
l0kod
·w zeszłym roku·discuss
We are working on a JSON/TOML format for Landlock, with the related library, and bindings for several languages: https://github.com/landlock-lsm/landlockconfig

We are working to make it part of the OCI runtime specification too.

Using existing configuration format would not work because Landlock has its own unique properties: unprivileged, nested sandboxes, dedicated Linux syscalls, and a good compatibility story with opt-in and incremental features.
l0kod
·w zeszłym roku·discuss
Namespace are very useful to build virtual environments, but I think it's important to keep in mind that they are not designed for sandboxing and don't provide security guarantees (e.g. mount point propagation), nor fine-grained access rights, nor security events (e.g. logs)... which might be OK according to use cases. Also, namespaces increase the attack surface of the kernel (e.g. vulnerabilities that can be reached through user namespaces). That being said, even if Landlock can control the most important filesystem access rights, not all of them are supported yet. New kernel releases bring new Landlock features (e.g. IPC, network control). It takes some time to build a new and safe access control system but we'll get there!