5 ms·

> Something like SELinux, RSBAC, Even AppArmor The problem with AppArmor and friends is that they are hell on earth to configure and manage. And I'm saying th

> Something like SELinux, RSBAC, Even AppArmor The problem with AppArmor and friends is that they are hell on earth to configure and manage. And I'm saying that as a security conscious sysadmin ! I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Of course I leave AppArmor enabled to some degree, and I'm happy if a package comes with AppArmor rules ... but I ain't gonna be sacrificing days of my life writing, tweaking, troubleshooting my own rules. That's why I feel OpenBSD's answer is likely a good compromise. It adds a demonstrable level of security, and it doesn't stress out the sysadmin.

binkHN 4y ago
> The problem with AppArmor and friends is that they are hell on earth to configure and manage. > I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Yep. This is one of the prime motivators as to why OpenBSD did what they did. Often times, when AppArmor and similar solutions prevent a program from working properly, the first reaction is to disable it, and then these protections tend to stay disabled.
Zurrrrr 4y ago
Rules might be a pain, but no more so than writing good firewall rules, and once done don't have to be done again. It's not the issue some make it out to be
- commandersaki 4y ago
  > and once done don't have to be done again Hardly, you'll have to update the rules when the program gets updated to do new things; whereas with pledge(2)/unveil(2) the developer simply applies more restrictions if needed before the program is distributed. pledge(2)/unveil(2) is not only superior because it cannot be disabled, it has better aesthetics than any of that apparmor/selinux garbage.
  - Zurrrrr 4y ago
    On most servers, programs are not doing drastically new things. That really isn't the issue you make it out to be. The developer applying restrictions ahead of time can't, by nature, mitigate the types of bugs that things like SELinux can protect against. You really have no clue about what you're talking about.

binkHN 4y ago

> The problem with AppArmor and friends is that they are hell on earth to configure and manage. > I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Yep. This is one of the prime motivators as to why OpenBSD did what they did. Often times, when AppArmor and similar solutions prevent a program from working properly, the first reaction is to disable it, and then these protections tend to stay disabled.

Zurrrrr 4y ago

Rules might be a pain, but no more so than writing good firewall rules, and once done don't have to be done again. It's not the issue some make it out to be

commandersaki 4y ago
> and once done don't have to be done again Hardly, you'll have to update the rules when the program gets updated to do new things; whereas with pledge(2)/unveil(2) the developer simply applies more restrictions if needed before the program is distributed. pledge(2)/unveil(2) is not only superior because it cannot be disabled, it has better aesthetics than any of that apparmor/selinux garbage.
- Zurrrrr 4y ago
  On most servers, programs are not doing drastically new things. That really isn't the issue you make it out to be. The developer applying restrictions ahead of time can't, by nature, mitigate the types of bugs that things like SELinux can protect against. You really have no clue about what you're talking about.