4 ms·

This is the first I am hearing about Landlock, but a major part of my job is writing SELinux policy. First, it should be possible to use both this and SELinux

This is the first I am hearing about Landlock, but a major part of my job is writing SELinux policy. First, it should be possible to use both this and SELinux as they are stackable. The main benefit I see to Landlock over SELinux I see is that it is far more dynamic. With SELinux, you need to know what accesses a program will make when you write the policy. Since Landlock creates the rules at runtime, it can be used in cases where you do not know exactly what it needs to do ahead of time. Obviously, this can also be thought of as a drawback instead of a benefit. For a toy usecase, consider a hex editor. You want to be able to open and edit any file on the system; however you are concerned that a maliciously crafted could compromise the editor. With Landlock, you can let the user select the file they want to use, then dynamically restrict your permissions before you actually open the file. With SELinux, you would need to give the editor access to the entire system because you do not know ahead of time which file the user will want to access. Granted, this toy example is simple enough that I could come up with a workable SELinux solution if I had to, but sometimes the application actually knows best what it needs to do.

e12e 5y ago
I think this and sibling captures the difference quite well. For your hex editor, you could replace it with an image converter service - each image conversion need to open a source file for reading and a destination file for writing. You could limit the converters access to not read /etc/shadow various static ways. But assuming uploads/malicious.jpg blows up, it's tricky to statically say: deny access to uploads/other_user_medical_bill.jpg. So the example isn't all that contrived. Run time dropping of privileges is very useful (and common for network daemons etc for a long time - like apache binding port 80, maybe opening log files, then dropping from root to nobody/www data). But being able to say that "after this point I should never have to open a file" and having that pledge enforced - is really nice. This is a tool for good programs to behave in the face of bugs, while static measures are a way to enforce access on potentially bad programs.

e12e 5y ago

I think this and sibling captures the difference quite well. For your hex editor, you could replace it with an image converter service - each image conversion need to open a source file for reading and a destination file for writing. You could limit the converters access to not read /etc/shadow various static ways. But assuming uploads/malicious.jpg blows up, it's tricky to statically say: deny access to uploads/other_user_medical_bill.jpg. So the example isn't all that contrived. Run time dropping of privileges is very useful (and common for network daemons etc for a long time - like apache binding port 80, maybe opening log files, then dropping from root to nobody/www data). But being able to say that "after this point I should never have to open a file" and having that pledge enforced - is really nice. This is a tool for good programs to behave in the face of bugs, while static measures are a way to enforce access on potentially bad programs.