Hacker News Reader

Comment by elric | Hacker News Reader

You can do similar things in Linux with firejail, but there are a lot of folks who feel uneasy about the safety of firejail.

View on HN

Besides firefox, more than 80 userland programs have their access to the filesystem restricted with the use of unveil.

If Theo stopped being so resistant to solutions like AppArmor, then OpenBSD could have a real security layer instead of toys like unveil and pledge.

Here is Justine's write up on pledge and why he wants to port it to Linux. https://justine.lol/pledge/

It has its uses I guess, but it requires opt-in which is a pretty big disadvantage, and then still can't do even a fraction of what SELinux can already do. SELinux isn't that hard to learn, and the security benefits are immense.

    2024-01-08 22:34 ubuntu@knope:~$ sudo apparmor_status
    apparmor module is loaded.
    185 profiles are loaded.
    104 profiles are in enforce mode.
    (...)
    124 processes have profiles defined.
    122 processes are in enforce mode.

including firefox and chromium

But apparmor is more complex system and in fact is an RBAC. unveil(2) is much more easier in implementation and enforcing.

Also, there's AppArmor which is enabled in Debian and SuSE which transparently limits applications' reach without they realize.

Transparent limitation is a double-edged sword. From an adversarial perspective, it's good since I'm not advertising what my system can and can't do, and poorly written software may get hung up on timeouts waiting for things to happen. On the other hand, those same benefits against an adversary are negative constraints to usability, as now silent failures can happen on a system, requiring you to watch your AppArmor logs like a hawk when using new software.

Ultimately, less of a concern for servers that likely have limited scope and use cases, but a significant decrease in usability for workstations.

You need to write an AppArmor profile to limit your software. It’s an opt-in system.

The workflow is you put a test system to “complain” mode and use your software as intended, and add the required permissions to the profile by looking at the logs to see what your app is doing. Then you put AppArmor to enforcing mode, add the profile to production system and your application is sandboxed. Iteratively refine as necessary.

Debian desktop comes with AppArmor enabled. Nothing has been broken so far.

And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed. You get it to work and things seem to be fine. Over time, you start noticing things that are subtly broken, until something just fails completely and doesn't work. The fix turns out to be trivial when you give it another go two days later, but at the time it happened you really didn't have the nerve to deal with it right then.

After two dist upgrades, you realize that this approach isn't workable.

> And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed.

Nah. That's a huge exaggeration. Most software doesn't change its base behavior like that and certainly not with every new release, and certainly browsers don't.

Well, I have two Debian desktop installations. One is six, the other one is ten years old. I never had a problem with either.

This is without adding the numerous servers which I just install and forget, and they work without any problems for years.

edit: Yes, they're dist-upgraded all the time.

Reply on news.ycombinator.com