5 ms·

pledge and, say, SELinux solve two different problems: Pledge stops trusted software from being exploited. I trust Apache (I run it as root) but the authors ca

pledge and, say, SELinux solve two different problems: Pledge stops trusted software from being exploited. I trust Apache (I run it as root) but the authors can't guarantee that it can't get exploited, so it's protected by pledge. If I didn't trust Apache, I wouldn't trust that it pledged anything. SELinux secures un-trusted code. So if I download a program off the internet and run it as nobody, it shouldn't exploit something to get root. This is useful when downloading random closed-source programs (such as on Android). Unfortunately, Linux relies on SELinux to solve problem #1 (how do I know which files does Apache really need, and which won't help security exploits), which is why it gets such a terrible reputation.

djsumdog 10y ago
I've had to make AppArmor profiles in the past and they can get a bit painful. I've never had to configure SELinux so I don't know how much better/worse it is. That being said, I think Docker and other container systems are going to remove the need for these security profile systems. Yes, if there is exploitable code in the container, it can read/write to other things in the container. But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports.
- ams6110 10y ago
  The typical configuration I see in /etc/selinux/config is: SELINUX=disabled
  - protomyth 10y ago
    Its definitely one of the things that shows up when you call about a lot of vendor's software support. I find it rather annoying that a company tells you to buy a specific Linux distribution then pulls exactly what you say. Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? I guess in some ways its why I like the idea of pledge. It makes me think better of the programmer because they have put some thought into their program. I'm not sure what I should think when I see SELINUX=disabled as a possible solution.
    - dispose13432 10y ago
      >Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? SELinux is not complex because we program in complex ways, but because we don't know the target program. For example, (again, nothing against Apache but...) if I want to secure Apache, there's no way for me (as a sysadmin) to tell exactly which files, exactly which syscalls, and exactly which libs does it need to function, and there's no way for me to stay on top of it. And the same applies to any other complicated software. How to I lock down X? Firefox? Really, the beauty of a "pledge" like system is that the programmer/PM of the code (which he should understand) should know how to lock it down
      - nickpsecurity 10y ago
        You can do that in a SELinux-like system. There's been tools and policy languages for it. Even better, if the language is high-level & declarative, then it can be used to generate security policies on many different OS's and mechanisms instead of just SELinux or pledge.
        protomyth 10y ago
        Which projects are doing this with SELinux?
        nickpsecurity 10y ago
        I haven't followed SELinux in a while. I recall Tresys made tools with dialog boxes to make it about as easy as Windows firewalls. A quick Google leads me to Lobster being an example of what I was thinking of: https://selinuxproject.org/files/2008_selinux_developer_summit/2008_summit_white.pdf https://selinuxproject.org/files/2008_selinux_developer_summ...
        protomyth 10y ago
        Given how fast pledge was able to be put into production, I think it was the right move. I get SELinux can and has (2008) had tools for this, but it really doesn't seem to have caught on.
  - yarrel 10y ago
    It's quicker to recover from a hack than it is to deal with SELinux every day.
    - dispose13432 10y ago
      >It's quicker to recover from a hack than it is to deal with SELinux every day. Quicker, but not cheaper
- rwj 10y ago
  I'm not sure that containers will help with security profiles. They should help with (for example) privilege escalation, but you will still be left with managing what systems/programs need access to what resources.
  - dispose13432 10y ago
    While containers can't help against privilege escalation, they help against information leakage. For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
    - module0000 10y ago
      If your www-user can read /etc/passwd without 'avc: denied' appearing in your selinux log, you are doing it wrong. The whole idea behind selinux is to prevent this scenario from ever happening. Apache has a policy written for it, that specifies precisely which paths and contexts apache needs <X> type of access to. If it tries to access anything outside those paths and context, the selinux module denies the attempt. It's foolproof if you use it. It's also incredibly annoying if you are on a system with selinux enabled, but aren't familiar with selinux.
      - dispose13432 10y ago
        It's true, but containers are much easier to play with if your distro doesn't come with sane presets (Debian, for one)
    - geggam 10y ago
      ... because you are auditing all of the upstream image sources ? seriously ?
- xorcist 10y ago
  There has been no shortage of ways to escape Docker containers. If you want to lock down applications, SELinux will be much more useful, even if far from perfect.
- pmoriarty 10y ago
  "But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports." A kernel exploit executed in a Docker container would compromise all the other Docker containers on the same machine (and the machine as a whole).
splesjaz 10y ago
While SELinux enabled distros usually comes with a targeted mode by default Gentoo hardened has strict mode in it's policy rules, everything is confined with that policy. Usually only targeted applications are confined by default and allowing unconfined applications to run without any protection. Apparmor is easy and anyone can understand how it works after reading the wiki, while apparmor also has neat functions you need to compile them in sadly :( OpenBSD is great, first you can leave it running for a long time without thinking about security bugs or updates, instead Linux you have to keep close eye to kernel updates & application patches, that's why things like mailservers & DNS & NTP and more are running OpenBSD because I know it doesn't need critical updates every week and uptime is critical for me.

djsumdog 10y ago

I've had to make AppArmor profiles in the past and they can get a bit painful. I've never had to configure SELinux so I don't know how much better/worse it is. That being said, I think Docker and other container systems are going to remove the need for these security profile systems. Yes, if there is exploitable code in the container, it can read/write to other things in the container. But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports.

ams6110 10y ago
The typical configuration I see in /etc/selinux/config is: SELINUX=disabled
- protomyth 10y ago
  Its definitely one of the things that shows up when you call about a lot of vendor's software support. I find it rather annoying that a company tells you to buy a specific Linux distribution then pulls exactly what you say. Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? I guess in some ways its why I like the idea of pledge. It makes me think better of the programmer because they have put some thought into their program. I'm not sure what I should think when I see SELINUX=disabled as a possible solution.
  - dispose13432 10y ago
    >Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? SELinux is not complex because we program in complex ways, but because we don't know the target program. For example, (again, nothing against Apache but...) if I want to secure Apache, there's no way for me (as a sysadmin) to tell exactly which files, exactly which syscalls, and exactly which libs does it need to function, and there's no way for me to stay on top of it. And the same applies to any other complicated software. How to I lock down X? Firefox? Really, the beauty of a "pledge" like system is that the programmer/PM of the code (which he should understand) should know how to lock it down
    - nickpsecurity 10y ago
      You can do that in a SELinux-like system. There's been tools and policy languages for it. Even better, if the language is high-level & declarative, then it can be used to generate security policies on many different OS's and mechanisms instead of just SELinux or pledge.
      - protomyth 10y ago
        Which projects are doing this with SELinux?
        nickpsecurity 10y ago
        I haven't followed SELinux in a while. I recall Tresys made tools with dialog boxes to make it about as easy as Windows firewalls. A quick Google leads me to Lobster being an example of what I was thinking of: https://selinuxproject.org/files/2008_selinux_developer_summit/2008_summit_white.pdf https://selinuxproject.org/files/2008_selinux_developer_summ...
        protomyth 10y ago
        Given how fast pledge was able to be put into production, I think it was the right move. I get SELinux can and has (2008) had tools for this, but it really doesn't seem to have caught on.
- yarrel 10y ago
  It's quicker to recover from a hack than it is to deal with SELinux every day.
  - dispose13432 10y ago
    >It's quicker to recover from a hack than it is to deal with SELinux every day. Quicker, but not cheaper
rwj 10y ago
I'm not sure that containers will help with security profiles. They should help with (for example) privilege escalation, but you will still be left with managing what systems/programs need access to what resources.
- dispose13432 10y ago
  While containers can't help against privilege escalation, they help against information leakage. For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
  - module0000 10y ago
    If your www-user can read /etc/passwd without 'avc: denied' appearing in your selinux log, you are doing it wrong. The whole idea behind selinux is to prevent this scenario from ever happening. Apache has a policy written for it, that specifies precisely which paths and contexts apache needs <X> type of access to. If it tries to access anything outside those paths and context, the selinux module denies the attempt. It's foolproof if you use it. It's also incredibly annoying if you are on a system with selinux enabled, but aren't familiar with selinux.
    - dispose13432 10y ago
      It's true, but containers are much easier to play with if your distro doesn't come with sane presets (Debian, for one)
  - geggam 10y ago
    ... because you are auditing all of the upstream image sources ? seriously ?
xorcist 10y ago
There has been no shortage of ways to escape Docker containers. If you want to lock down applications, SELinux will be much more useful, even if far from perfect.
pmoriarty 10y ago
"But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports." A kernel exploit executed in a Docker container would compromise all the other Docker containers on the same machine (and the machine as a whole).

splesjaz 10y ago

While SELinux enabled distros usually comes with a targeted mode by default Gentoo hardened has strict mode in it's policy rules, everything is confined with that policy. Usually only targeted applications are confined by default and allowing unconfined applications to run without any protection. Apparmor is easy and anyone can understand how it works after reading the wiki, while apparmor also has neat functions you need to compile them in sadly :( OpenBSD is great, first you can leave it running for a long time without thinking about security bugs or updates, instead Linux you have to keep close eye to kernel updates & application patches, that's why things like mailservers & DNS & NTP and more are running OpenBSD because I know it doesn't need critical updates every week and uptime is critical for me.