Landlock LSM Still Tackling Unprivileged Sandboxing For Linux

[starshipeleven]

That's not the name of the project though. Which is Apple Seatbelt.

Do you want also a photoshopped image with an apple in there to get my point?

[unixfan2001]

I'm sure he was talking of algae.
This is a seabelt

That's not the name of the project though. Which is Apple Seatbelt.

[c117152]

Well, there is already a feature like that. It is used by Chrome for instance, though they also have the setuid wrapper. It would be nice to get away from the setuid wrapper, unfortunately that require a newish Linux kernel, and that distros doesn't choose to cripple the ability to start sandboxes as a user: https://github.com/bazelbuild/bazel/issues/433

that's still userland defined for the most part. this sucka limits syscalls as well.

well, none of these linux stuff come anywhere near the plan9 namespaces since there's no union mounts... but it's something.

[starshipeleven]

Michael phoronix
should be Seatbelt.

I'm sure he was talking of algae.
This is a seabelt

[carewolf]

This is precisely what you want. Currently, the namespaces and linux security models are very dependent on user land implementations and distribution \ root security policy. Docker needs everything configured just right. AppArmor and SELinux are configured by root... The result is that the end-users can't just run anything they want just like that.

Landlock is application level LSM. For instance, firefox could decide to run their javascript engine in it and they won't need any special polices set from root. You could pick up a python script and just run it in a directory, and not even look at the code to make sure it's not traversing outside the directory into your $HOME...

Use-land will need support for it of course. But effectively, it's anonymous namespaces.

Well, there is already a feature like that. It is used by Chrome for instance, though they also have the setuid wrapper. It would be nice to get away from the setuid wrapper, unfortunately that require a newish Linux kernel, and that distros doesn't choose to cripple the ability to start sandboxes as a user: https://github.com/bazelbuild/bazel/issues/433

[c117152]

I would be happy if we could just be allowed to use anonymous kernel namespaces by default on Debian.

This is precisely what you want. Currently, the namespaces and linux security models are very dependent on user land implementations and distribution \ root security policy. Docker needs everything configured just right. AppArmor and SELinux are configured by root... The result is that the end-users can't just run anything they want just like that.

Landlock is application level LSM. For instance, firefox could decide to run their javascript engine in it and they won't need any special polices set from root. You could pick up a python script and just run it in a directory, and not even look at the code to make sure it's not traversing outside the directory into your $HOME...

Use-land will need support for it of course. But effectively, it's anonymous namespaces.

[carewolf]

I would be happy if we could just be allowed to use anonymous kernel namespaces by default on Debian.

[unixfan2001]

Michael phoronix

Seabelt

should be Seatbelt.

[phoronix]

Phoronix: Landlock LSM Still Tackling Unprivileged Sandboxing For Linux

The "Landlock" Linux security module continues to be developed as an effort to let any progress -- even unprivileged processes -- create "powerful security" sandboxes...

http://www.phoronix.com/scan.php?page=news_item&px=Landlock-LSM-V3