3 ms·

> They use AppArmor extensively as an "application firewall for syscalls", which may sound ugly but is the most practical security solution I've seen in this sp

> They use AppArmor extensively as an "application firewall for syscalls", which may sound ugly but is the most practical security solution I've seen in this space. Seems like a good use case for Capsicum[1]. Too bad Capsicum hasn't been merged into the Linux Kernel yet[2]. [1]: https://www.freebsd.org/cgi/man.cgi?capsicum(4) https://www.freebsd.org/cgi/man.cgi?capsicum(4) [2]: http://capsicum-linux.org/ http://capsicum-linux.org/

jlgaddis 9y ago
Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.
- weberc2 9y ago
  I'm of the impression that SELinux is much more operationally complex than AppArmor--so much so that it lends itself to security holes by way of accidental misconfiguration. This is all hearsay, but I'd like to hear some good discussion about this.
  - insertnickname 9y ago
    Or by way of intentional disablement.
  - jlgaddis 9y ago
    > ... it lends itself to security holes by way of accidental misconfiguration. I'm not sure I understand how SELinux would introduce additional security issues. It doesn't permit any behavior that wouldn't be allowed if it weren't in use. > ... I'd like to hear some good discussion about this. Some people seem to have -- for whatever reasons (previous issues or whatever) -- sworn off SELinux completely which, IMO, is a mistake. Unfortunately, there are way too many tutorials and how-to guides on the Internet where step 1 is often "turn off SELinux". Instead of taking the time to figure out what the problem is and fixing it, they just take the easy route and get rid of it completely. I am the opposite. Most of my servers run RHEL/CentOS and I insist that it be enabled on all of them. This is primarily because I've seen, firsthand, SELinux prevent a compromise (well, kind of). In my career, I've had one machine that I had responsible for (even though it was "shared responsibility") get compromised (that I know of, of course). It was because of a web application (used by Marketing) where a vulnerability had been found and a patch had been released but not yet installed. I was on vacation at the time and, when I returned, just mistakenly assumed that this had been addressed. An exploit existed and was being used "in the wild" and this machine was hit. The first thing that exploit did was to reach out and download the rest of its toolkit via TFTP. Fortunately, that attempt was prevented by SELinux and logged. Thanks to that log entry, we began investigating, figured out what happened, and promptly updated the machine. So, yeah, SELinux saved our ass once, many years ago, and so now I make sure that it is enabled everywhere possible. It didn't technically prevent a compromise but it certainly prevented it from being much, much worse. We were able to figure out that nothing else happened after the TFTP transfer failed. The attacker didn't "try again" and we got it patched and back online without any other issues. SELinux is complex and requires administrators to learn new things, but it's nothing that someone running Linux servers isn't used to -- it's just one more thing you need to learn.
- 2trill2spill 9y ago
  > Sounds like a good use case for SELinux kinda, although you could implement sandboxing with SELinux it's going to take much more effort. SELinux is a Mandatory Access Control Framework and Capsicum is a hybrid Unix capabilities system. While there is overlap in what you can do with them they really our different sets of tools. Mandatory access controls are for system administrators to lock down and control access on a machine. Capsicum is for application authors to sandbox their application. Ideally they should be used together. Back to my point that while MAC(SELinux) can be used for sandboxing but will take more effort then using something like capsicum or pledge. With MAC you have to think of all the things you don't want an application to do. With Capsicum or Pledge you only have to think of the things you want your application to do and everything else will be blocked automatically. So for example to sandbox chromium with capsicum it took 100 LOC, to sandbox chromium with SELinux it took 200 LOC so not bad but it doesn't stop IPC primitives. So half the code and more protection. [1]: https://www.youtube.com/watch?v=raNx9L4VH2k https://www.youtube.com/watch?v=raNx9L4VH2k
X86BSD 9y ago
Meh I don’t consider it bad. It’s in FreeBSD. You want it? Run FreeBSD. Waiting for Linux to implement their “version” of capsicum, poorly, Might be a while. Plus you have other great tech like CloudABI in FreeBSD as well which makes it even more compelling.
- 2trill2spill 9y ago
  It would be wonderful for FreeBSD as well as Linux if both operating systems supported capsicum. It would mean that both would have the same sandboxing API. Which would make it more likely for application authors to use capsicum, which in turn increases the amount of applications using it. Also why do you assume Linux's implementation would be poor? there's nothing to indicate that it is. Also capsicum is already implemented for Linux and has been for a couple years, it's just not in Linus's tree[1]. [1]: https://github.com/google/capsicum-linux https://github.com/google/capsicum-linux
  - X86BSD 9y ago
    Because almost every thing that Linux implements is poorly done. Let’s take the subject at hand. Containers. They never created containers. Instead they came up with docker. And never designed it to be secure. Hence all these efforts to figure out how to secure docker. They keep trying to retroactively bolt security on. Which is never going to secure it. Eventually someone’s going to have to throw it out and redo it with the initial goal of making it secure. When it should have been designed secure as the main feature. Like Zones or Jails were. Also for sand boxing apps you really should look at CloudABI. Ed has put a ton of work into it. The last time I looked at capsicum for Linux it wasn’t complete. That’s changed?

jlgaddis 9y ago

Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.

weberc2 9y ago
I'm of the impression that SELinux is much more operationally complex than AppArmor--so much so that it lends itself to security holes by way of accidental misconfiguration. This is all hearsay, but I'd like to hear some good discussion about this.
- insertnickname 9y ago
  Or by way of intentional disablement.
- jlgaddis 9y ago
  > ... it lends itself to security holes by way of accidental misconfiguration. I'm not sure I understand how SELinux would introduce additional security issues. It doesn't permit any behavior that wouldn't be allowed if it weren't in use. > ... I'd like to hear some good discussion about this. Some people seem to have -- for whatever reasons (previous issues or whatever) -- sworn off SELinux completely which, IMO, is a mistake. Unfortunately, there are way too many tutorials and how-to guides on the Internet where step 1 is often "turn off SELinux". Instead of taking the time to figure out what the problem is and fixing it, they just take the easy route and get rid of it completely. I am the opposite. Most of my servers run RHEL/CentOS and I insist that it be enabled on all of them. This is primarily because I've seen, firsthand, SELinux prevent a compromise (well, kind of). In my career, I've had one machine that I had responsible for (even though it was "shared responsibility") get compromised (that I know of, of course). It was because of a web application (used by Marketing) where a vulnerability had been found and a patch had been released but not yet installed. I was on vacation at the time and, when I returned, just mistakenly assumed that this had been addressed. An exploit existed and was being used "in the wild" and this machine was hit. The first thing that exploit did was to reach out and download the rest of its toolkit via TFTP. Fortunately, that attempt was prevented by SELinux and logged. Thanks to that log entry, we began investigating, figured out what happened, and promptly updated the machine. So, yeah, SELinux saved our ass once, many years ago, and so now I make sure that it is enabled everywhere possible. It didn't technically prevent a compromise but it certainly prevented it from being much, much worse. We were able to figure out that nothing else happened after the TFTP transfer failed. The attacker didn't "try again" and we got it patched and back online without any other issues. SELinux is complex and requires administrators to learn new things, but it's nothing that someone running Linux servers isn't used to -- it's just one more thing you need to learn.
2trill2spill 9y ago
> Sounds like a good use case for SELinux kinda, although you could implement sandboxing with SELinux it's going to take much more effort. SELinux is a Mandatory Access Control Framework and Capsicum is a hybrid Unix capabilities system. While there is overlap in what you can do with them they really our different sets of tools. Mandatory access controls are for system administrators to lock down and control access on a machine. Capsicum is for application authors to sandbox their application. Ideally they should be used together. Back to my point that while MAC(SELinux) can be used for sandboxing but will take more effort then using something like capsicum or pledge. With MAC you have to think of all the things you don't want an application to do. With Capsicum or Pledge you only have to think of the things you want your application to do and everything else will be blocked automatically. So for example to sandbox chromium with capsicum it took 100 LOC, to sandbox chromium with SELinux it took 200 LOC so not bad but it doesn't stop IPC primitives. So half the code and more protection. [1]: https://www.youtube.com/watch?v=raNx9L4VH2k https://www.youtube.com/watch?v=raNx9L4VH2k

X86BSD 9y ago

Meh I don’t consider it bad. It’s in FreeBSD. You want it? Run FreeBSD. Waiting for Linux to implement their “version” of capsicum, poorly, Might be a while. Plus you have other great tech like CloudABI in FreeBSD as well which makes it even more compelling.

2trill2spill 9y ago
It would be wonderful for FreeBSD as well as Linux if both operating systems supported capsicum. It would mean that both would have the same sandboxing API. Which would make it more likely for application authors to use capsicum, which in turn increases the amount of applications using it. Also why do you assume Linux's implementation would be poor? there's nothing to indicate that it is. Also capsicum is already implemented for Linux and has been for a couple years, it's just not in Linus's tree[1]. [1]: https://github.com/google/capsicum-linux https://github.com/google/capsicum-linux
- X86BSD 9y ago
  Because almost every thing that Linux implements is poorly done. Let’s take the subject at hand. Containers. They never created containers. Instead they came up with docker. And never designed it to be secure. Hence all these efforts to figure out how to secure docker. They keep trying to retroactively bolt security on. Which is never going to secure it. Eventually someone’s going to have to throw it out and redo it with the initial goal of making it secure. When it should have been designed secure as the main feature. Like Zones or Jails were. Also for sand boxing apps you really should look at CloudABI. Ed has put a ton of work into it. The last time I looked at capsicum for Linux it wasn’t complete. That’s changed?