# AppArmor alternative for FreeBSD?



## semafoor (Nov 27, 2013)

Hey everyone,

I wonder if an AppArmor-like system exists for FreeBSD, or if one can be constructed using system features.

Background: I always used to have networked applications running in convoluted chroots that I bootstrapped using port options, custom scripts and trial-and-error. That is annoying to keep updated, and interaction between applications is inflexible (e.g. you have to put the MySQL socket in /chroot/apache or always use TCP to localhost (yuck)). As I've posted before, I'm moving towards just using packages everywhere. Now, I really want to get rid of my legacy maze of chroots. I _could_ go for jails, which look somewhat easier to maintain (but still require work beyond just keeping packages updated). I'd much rather like to use a sandboxing approach, where I'd use applications in their default locations and just restrict what they can do. I've played with AppArmor the past weeks and it seems pretty great, but I can't find anything like it on FreeBSD.

I have perused papers and blogs on Capsicum, but most sources hint at recompiling applications in order to be sandboxes, which is not really in my powers. Is it possible to do some sort of AppArmor-style application sandboxing on FreeBSD, where an external framework imposes restrictions on _existing_ applications (e.g. by executable location) without requiring application support? Let's say, httpd might be allowed reading from /chroot/apache/*, writing to its logs, listening on the network, access the mysqld socket, etc.

I like AppArmor profiling/learning tools, but it would be no problem to do manual work using audit files. However I can't really find if the FreeBSD kernel has a mechanism to restrict access in an application-based way at all.

If such a methodology is not possible on FreeBSD, what do you guys use in order to restrict applications from having unchecked access to the system? It seems to me that a jail could be less restrictive than a sandbox with custom application-based rules; for instance, a binary inside the jail would probably be able to execute external binaries which are necessary for Apache/its rc scripts.

Thanks again!
semafoor


----------



## kpa (Nov 27, 2013)

As far as I know the Mandatory Access Control Framework (MAC for short) is the closest equivalent in FreeBSD.

https://www.freebsd.org/doc/handbook/mac.html


----------



## semafoor (Nov 28, 2013)

kpa said:
			
		

> As far as I know the Mandatory Access Control Framework (MAC for short) is the closest equivalent in FreeBSD.
> 
> https://www.freebsd.org/doc/handbook/mac.html


I would have given you thanks  I had browsed through those pages but found them to be a little cryptic. After a closer look, I think that some of the MAC modules might do the trick, or at least a large part of it. Documentation is pretty sparse. Let's see if I can get them to work.


----------



## rusty (Nov 30, 2013)

I recommend doing a search of this forum for "mls", there was quite a bit of discussion about that not so long ago. It may point you in the right direction.


----------



## semafoor (Dec 3, 2013)

I've checked out most of the MAC modules and while they are interesting, I don't think one of them closely matches my use case, where I want to externally provide pathname-based rules (to simulate a chroot environment without its inflexibility.)

Solutions based on labeling files don't seem viable to me, as users may upload lots of files themselves and it would be cumbersome to maintain labels in sync on large numbers of boxes.

Module mac_bsdextended with its ugidfw approach looks the most promising, but unfortunately its granularity is filesystem-based. There seem to have been a Google Summer of Code proposal to add path-based rules to it, but it's unclear what happened to it.

Since the policy is UID-based instead of application-based, it's not exactly clear to me how well its protections would compare in case of a local root compromise, but perhaps in that case all bets are off anyway.

Thanks for the input, I'll sleep on it but for now I think it'll be chroots.


----------

