Skip to content

dtprobed: adopt Landlock #91

@thesamesam

Description

@thesamesam
Contributor

dtprobed already uses seccomp, but there's a new Linux sandboxing LSM in town which solves a bunch of problems seccomp has wrt abstraction and targeting the wrong layer.

We should be able to use it to restrict precisely our access to the device node/socket. See https://docs.kernel.org/userspace-api/landlock.html. xz has a nice example of some simple usage.

Activity

nickalcock

nickalcock commented on Aug 28, 2024

@nickalcock
Member

I know next to nothing about it, but IIRC landlock replaces seccomp's non-strict mode (BPF filtering). I don't think anything replaces what dtprobed uses, which is strict-mode seccomp (which is intentionally totally insanely harsh and unconfigurable, i.e. just what we want). In particular if landlocking a process stops its children from being strict-mode-seccomped, it isn't really usable for our purposes.

If landlock doesn't interfere with strict-mode seccomp, we could always landlock-confine the parent dtprobed so that it can't write to anything but the CUSE socket, /run/dtrace and whatever else it needs, but the problem is that "whatever else it needs" includes things like chasing /proc/$pid/fd symlinks which could point almost anywhere. So we can't restrict reading much. Still, if it can do better, I'd be interested!

For now I'm relying on systemd doing a bunch of containerization of dtprobed's parent...

thesamesam

thesamesam commented on Aug 28, 2024

@thesamesam
ContributorAuthor

IIRC landlock replaces seccomp's non-strict mode (BPF filtering).
[...]
In particular if landlocking a process stops its children from being strict-mode-seccomped, it isn't really usable for our purposes.

Ah, you might be right. OK. I'll check it out and if it's incompatible, we'll (obviously) leave it.

but the problem is that "whatever else it needs" includes things like chasing /proc/$pid/fd symlinks which could point almost anywhere.

... oh, duh. I hadn't thought about that part. I suggest we keep it open as I'd like a chance to play with landlock, but if I don't get around to it, I don't think it matters at all. Either way is fine (closing now or not).

For now I'm relying on systemd doing a bunch of containerization of dtprobed's parent...

That's what I was worrying you'd say ;)

Right now, there's nothing like this for OpenRC, which is a big shame.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nickalcock@thesamesam@ezannoni

        Issue actions

          dtprobed: adopt Landlock · Issue #91 · oracle/dtrace-utils