freebsd & apparmor

Would apparmor for freebsd be a good idea or bad idea ?
 
I'm not sure how much apparmor is tied into systemd et al.

FreeBSD has mac(4)() which likely can support a lot of stuff that would be addressed by AppArmor. Combine it with a fine grained pf.conf() and you get pretty good coverage. However, this means it's all separate and not rule based like AppArmor.
Maybe it would be helpful to have a rule engine that transposes things into FreeBSD on-board methods?

My own experience with AppArmor was a bit spotty. If I remember correctly, it allowed you to run basically in "monitoring" mode, record the default state and then enforce the recorded constraints. We don't really have that atm; then again, with capsicum() we put that burden on the developer, which - at least in my opinion - gives you a better experience for the end user.

So far, I've used jails pretty much to do what AppArmor provides. Clearly, many roads lead to Rome as the saying goes.
 
Apparmor sounds a lot like SELinux and such. more or less a layer that all syscalls go through, check against a ruleset for that specific application, the permit or deny. The Wiki talks about a kernel module as part of the solution.

Effective? Sure, but like SELinux a big old pain to set up and configure. Run in monitoring mode for a while to accumulate rules for your specific workload, set up the config, then enable.

I think there are easier, perhaps better ways to accomplish the same goals with native tools.
So just my opinion, "that's a no from me" on apparmor for freebsd.
 
Back
Top