Comment by pdimitar

Comment by pdimitar 3 days ago

I'm very slowly taking an interest in Linux security as I'm starting to disentangle from my Mac and preparing to get a Linux workstation and make it my forever home for personal and work computing. So I'm very new to all this.

My questions are:

- How does this help with malware? I want to craft an environment where any program trying to read f.ex. anything inside ~/.ssh is automatically denied. I don't want a malicious build script to exfiltrate all my sensitive data!

- It seems that this software is well-positioned for us to write application launchers with, is that true? If so, well, I like the idea but it seems too manual.

Maybe I'm looking at the wrong thing. I strongly prefer deny-by-default in an invisible manner i.e. my system to refuse most requests to access this or that. Not opting in to it. Bad actors will not graciously limit their own program with Landlock. They'll try to get anything before I can even blink my eyes.

I feel I'm missing crucially important context. Can somebody help?

ameliaquining 3 days ago

The threat model here is not malware, but code-execution vulnerabilities in legitimate apps. If you're developing an application, you might use this API to deny yourself privileges that you know you won't need, so that if an attacker finds a code-execution vulnerability in your app, they can't use it to take over the user's machine.

It is not a suitable technology for sandboxing a program that wasn't designed to be sandboxed in this way. For that, you need one of the other technologies listed in the article.

Reply View 0 replies

tremon 3 days ago

I want to craft an environment where any program trying to read f.ex. anything inside ~/.ssh is automatically denied

That requires a MAC security model like apparmor [0] or selinux [1]. Those can deny filesystem access based on process environment data, such as the executable path or its security context. But these require the access rules to be enumerated externally, whereas landlock is about an application voluntarily limiting itself -- or limiting its children: e.g. it would be a very good idea for npm to restrict the scope of package post-install scripts to only the npm cache/build tree.

It seems that this software is well-positioned for us to write application launchers

Like OpenBSD's pledge[2], this API is primarily meant for application writers, not launchers. But where the Openbsd base system is maintained as a whole by the same group of people, Linux is a hodgepodge of different distributions using various software to construct a complete system. This means it's going to take a long while before landlock will reach anywhere close to the same coverage that pledge already has in OpenBSD. In the meantime, wrappers/launchers is the best that you can do on Linux.

[0] https://en.opensuse.org/SDB:AppArmor_geeks#Anatomy_of_a_prof...

[1] https://manpages.opensuse.org/Tumbleweed/selinux-policy-doc/...

[2] https://unix.stackexchange.com/a/411157

Reply View 0 replies

Dig1t 3 days ago

Mac and iOS have something that is almost exactly the same as this called sandboxing. When a daemon or app starts one of the first things it does (usually right inside of “main”) is enable the sandbox and declare which resources to whitelist, everything else is denied.

It is only useful for guarding your own process against someone using malicious inputs to get your process to do something you don’t intend. It is not a guard against programs written by malicious actors (malware), there exist other mechanisms to guard against malware.

Reply View 4 replies

fragmede 3 days ago

Linux has selinux and apparmor already.

Reply View | 3 replies
- staticassertion 3 days ago
  
  SELinux and Apparmor are typically configured by admins. They require root privileges and are designed with human interfaces. It is certainly atypical for a program to say "hey kernel, apply this apparmor profile to me" and they're not designed for incrementally dropping rights either.
  On Windows and MacOS programs are free to sandbox themselves programmatically and without privileges. Linux is the odd one out, basically every way of reducing your privileges programmatically requires already being root or at least having an admin preconfigure the system in a way that would allow it.
  
  Reply View | 0 replies
- baq 3 days ago
  
  Which both are so hard to get correctly that everyone on the desktop disables them. Ergonomics matter.
  
  Reply View | 1 reply
  
  preisschild 3 days ago
  
  Thats not true. Fedora has SELinux enabled by default and I dont have issues with it.
  
  Reply View | 0 replies

staticassertion 3 days ago

> - How does this help with malware? I want to craft an environment where any program trying to read f.ex. anything inside ~/.ssh is automatically denied. I don't want a malicious build script to exfiltrate all my sensitive data!

Your package manager would specify a policy that only allows specific access by build scripts. Or you'd use a wrapper.

> - It seems that this software is well-positioned for us to write application launchers with, is that true? If so, well, I like the idea but it seems too manual.