3 ms·

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

by pdimitar 11mo 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?

deleted 11mo ago
[deleted]
ameliaquining 11mo 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.
Dig1t 11mo 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.
- fragmede 11mo ago
  Linux has selinux and apparmor already.
  - baq 11mo ago
    Which both are so hard to get correctly that everyone on the desktop disables them. Ergonomics matter.
    - preisschild 11mo ago
      Thats not true. Fedora has SELinux enabled by default and I dont have issues with it.
  - staticassertion 11mo 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.
staticassertion 11mo 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. It could be. It's for anyone who knows what their program does, basically.
tremon 11mo 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_profile https://en.opensuse.org/SDB:AppArmor_geeks#Anatomy_of_a_prof... [1] https://manpages.opensuse.org/Tumbleweed/selinux-policy-doc/ssh_selinux.8.en.html https://manpages.opensuse.org/Tumbleweed/selinux-policy-doc/... [2] https://unix.stackexchange.com/a/411157 https://unix.stackexchange.com/a/411157
- pdimitar 11mo ago
  Thank you, that was super useful. When I said launchers, I meant more like f.ex. my own bespoke mini Golang program that lists rules inside its via Landlock's DSL and then launches f.ex. Firefox. But maybe that's unnecessary because I hear that Flatpak has a big database of such rules already. I'll find out in the future.

deleted 11mo ago

[deleted]

ameliaquining 11mo 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.

Dig1t 11mo 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.

fragmede 11mo ago
Linux has selinux and apparmor already.
- baq 11mo ago
  Which both are so hard to get correctly that everyone on the desktop disables them. Ergonomics matter.
  - preisschild 11mo ago
    Thats not true. Fedora has SELinux enabled by default and I dont have issues with it.
- staticassertion 11mo 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.

staticassertion 11mo 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. It could be. It's for anyone who knows what their program does, basically.

tremon 11mo 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_profile https://en.opensuse.org/SDB:AppArmor_geeks#Anatomy_of_a_prof... [1] https://manpages.opensuse.org/Tumbleweed/selinux-policy-doc/ssh_selinux.8.en.html https://manpages.opensuse.org/Tumbleweed/selinux-policy-doc/... [2] https://unix.stackexchange.com/a/411157 https://unix.stackexchange.com/a/411157

pdimitar 11mo ago
Thank you, that was super useful. When I said launchers, I meant more like f.ex. my own bespoke mini Golang program that lists rules inside its via Landlock's DSL and then launches f.ex. Firefox. But maybe that's unnecessary because I hear that Flatpak has a big database of such rules already. I'll find out in the future.