6 ms·

Let's enable AppArmor by default (why not?)

106 points by boramalper 9y ago

esaym 9y ago
If people rant and rave about how hard pulse audio is to configure, then I can only imagine how much kick back there will be about having to configuring apparmor etc. Just saying. Personally, I'll be keeping it disabled. I used to use selinux, but eventually stopped as I didn't find the constant headache of trying to figure out why something wasn't working was related to SE or not worth it.
- SteveNuts 9y ago
  Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If you want to do something weird like allowing nginx or apache to serve your home directories, it takes maybe 5 minutes to google the correct se context to set on the directory and apply it, otherwise any standard installation works out of the box. There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.
  - rightos 9y ago
    How about lack of necessity? I isolate my systems in many ways, using vms, tunnels and network isolation, but SELinux just doesn't fall into that, if anything's getting compromised it's the service in question that's the problem. Just because something exists doesn't mean you have to learn it and it doesn't make you lazy for refusing to do so. Proper protections extend far beyond using tools like this. Additionally, if you're running a desktop system and software installation is a frequent task, you'll have to deal with that constantly, often many times for the same application. At some point you're going to give up and say it's not worth it. Most people can't even stand the GUI based notifications of Outpost or ZoneAlarm in my experience.
    - emmelaich 9y ago
      > it's the service in question that's the problem .. But that's what selinux limits -- the "blast radius" from a compromised service.
      - rightos 9y ago
        Precisely what I'm saying, the limitation to the blast radius is already there if you've done the isolation yourself and it's only that one service that gets hit. If your Web server is on a private network with your app server and your load balancer, there's no way it can attack your database server. Basically, policies are implemented at the network and host level rather than the process and file level.
        emmelaich 9y ago
        The risk is that an app compromised could lead to local access which allows local (root/kernel) exploits.
        angry_octet 9y ago
        You're entirely correct, but we've become infected with SOE-think. Eventually you are always going to have a compromised node, and defence/detection in the node is hard and constantly evolving. The kernel attack surface is still large and complicated. In contrast, network interfaces are well controlled. If people started with 'deny all' in their fw permissions then added the minimal necessary holes then lateral movement would be a lot harder. I think the best argument for selinux/apparmor is that a lot of application specific security hardening can be packaged into standard configs. In contrast, there is little to orchestrate this for VMs/containers/physical hosts. Inter-VM/CNTR network control seems difficult (open vSwitch). If we could have easily configured, hypervisor enforced firewalling and encrypted tunneling then that would be more useful confinement.
    - SteveNuts 9y ago
      SELinux is all about minimizing and isolating collateral damage after a service is compromised, so if you care about that at all I'd suggest leaving it on. Also, it's probably the best protection from a zero-day exploit there is.
  - jron 9y ago
    I can think of a great reason to disable SELinux; you actually use linux for a workstation and don't want fight with it every time you install a new application.
    - Hello71 9y ago
      do you also do chmod -R 777 /?
      - xyzzy_plugh 9y ago
        That seems excessive. Why not just run as root?
      - yjftsjthsd-h 9y ago
        Pretty sure that actually breaks stuff
        jameskegel 9y ago
        This is correct.
    - Spivak 9y ago
      But you don't. Almost all 'applications' run unconfined.
    - pjmlp 9y ago
      I can think of a great reason not to disable it, exposing $HOME to the world.
      - deleted 9y ago
        [deleted]
      - hobarrera 9y ago
        Have had SELinux for almost 10 consecutive years. $HOME has never been exposed. I've no idea what you're going on about.
  - throw2016 9y ago
    Selinux will become useful when it precisely lists out what it disables with transparent explanations for assumptions made. And clear error messages or alerts when it has just disabled something with proper logging. Unlike with most open source software for things like selinux that disable a host of stuff by default, documentation cannot be an after thought. And why invent weird vague terminology, what is a context? Things are complex as it is and people need to get things done. To have to waste man hours that could be used more productively more than once only to figure out its caused by selinux 'silently' without any proper error messages or logging and you do the sensible thing and disable it.
    - Spivak 9y ago
      > what it disables with transparent explanations setroubleshoot > documentation cannot be an after thought Take a look at selinux-policy-doc, it's extensive. > what is a context It's a type. But 'type' as it refers to files means something else. It's just a label that describes what kind of file it is. user_home_dir_t is user files, httpd_sys_content_t is content that can be served by apache, nfsd_fs_t are files that that can be exported by NFS. > proper error messages or logging Every single denial is logged and it contains all the details why it was denied. You're asking for SELinux to log why it wasn't allowed which is done by setroubleshoot but isn't possible in general.
      - emmelaich 9y ago
        > Every single denial is logged Not quite true. Some need to have debug turned on. See my other comment.
  - staticassertion 9y ago
    Building policy by just auditing is a bad idea - you'll end up with overly general roles. Policy building is best left to the author of the applications so that they can test against it and lock it down.
    - problems 9y ago
      So what's your suggestion? Just disable SELinux for that application if it's failing?
  - emmelaich 9y ago
    I mostly agree with you but sometimes it is extraordinarily difficult to find out what went wrong. audit2allow and audit2why are often helpful but at least as often they offer the wrong solution. Did you know that some selinux violations are not even reported by default? This was the case for me; selinux transitions are prevented by a filesystem mounted _nosuid_. The failure is not reported because transition failures are apparently so common and unimportant selinux does not report them by default. Took me a looong time to troubleshoot this.
  - naasking 9y ago
    > Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If it were actually that easy, then you wouldn't need this step since SELinux would just do it for you. Clearly that isn't the case.
    - yorwba 9y ago
      SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Maybe it could be made more convenient by a tool that parses the log and automatically runs the commands when you answer the question with "y".
      - naasking 9y ago
        > SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Right, it requires intervention by a person who doesn't actually understand the minutiae of what the software is trying to do, so obviously they can make a properly informed choice as to what is and is not a security violation. Modern operating systems are so broken...
  - hobarrera 9y ago
    > There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn. Sometimes is as simple as not having time for that. If I've urgent work to do, I can't stop my work and well my boss/client "hang on, I need to learn to configure SELinux first!". The fact that it DOESN'T work out-of-the-box immediately and needs for me to configure it (regardless of how well documented it is) is its major pitfall. These things need to work without adding ANY burden to the user. Otherwise, they'll end up disabled.
- aidenn0 9y ago
  I still can't get PA to directly work with my USB sound card. I ended up configuring alsa dmix for it (which is definitely not easy to configure), and pointing PA at dmix. Supposedly it should see the card arrive through hotplug and add it to the device list, but that has never happened.
  - cat199 9y ago
    I've not had issues on this on Fedora (24+) - I did have to kill pulseaudio 1st though.. might try that if you have not already
  - digi_owl 9y ago
    dmix is hard to configure?
    - aidenn0 9y ago
      Configuring ALSA to work properly with my USB sound was the single hardest thing I did on my gentoo box. The documentation ranges from terrible to nonexsitent and it is unclear how to generalize many of the example configurations.
  - monksy 9y ago
    I have a mediabox which decided it was time to install PulseAudio for kodi. Which, that perceeded to complexly screw over audio over HDMI. (No idea why it was refusing to play audio until I disabled pulseaudio).
- viraptor 9y ago
  Having done all 3, I'd order them from the hardest as selinux, pulseaudio, apparmor. Out of these 3, apparmor has the most user-friendly tools to apply changes. It also allows you to easily turn off a single profile without disabling the whole system. Given those, I don't expect that many issues. But also, worth remembering that this is a proposal for an experiment. One of the things they're going to judge is how much does it affect regular users.
- oliwarner 9y ago
  Ubuntu has used AppArmor for years. Debian users will benefit from those years use.
- upofadown 9y ago
  People rant and rave about how pulseaudio is broken on their system. Pulseaudio is pretty easy to configure for most things. Sometimes it even (unexpectedly) configures itself!
qznc 9y ago
As an Ubuntu user, I suffered from AppArmor a few times and removed it. However, these days it seems to work. Worth a try, Debian.
revelation 9y ago
The Linux desktop of today still occasionally requires teaching users how to install new udev rules so they can properly use that USB serial converter or other gadget sanely. Now imagine raising that pain to the power of 10, but instead of only weird USB or "device not found" errors nothing works anymore because "AppArmor" is blocking syscalls. I can already see the StackOverflow answer that just tells you to set it to permissive, and you know what, that fixes it everytime, too! This is just a non-starter. Maybe they should look at deploying ASLR first, it's not 2000 anymore you know. (Update: they just managed to get this done with stretch, released 4 months ago! That's only like 7 years late for a crucial actual security feature)
- language 9y ago
  Huh, didn't know that Debian was missing ASLR. Any idea about the reasoning there?
  - staticassertion 9y ago
    What makes you think debian is missing ASLR?
    - language 9y ago
      > Update: they just managed to get this done with stretch, released 4 months ago! That's only like 7 years late for a crucial actual security feature) Dunno, taking @revelation's word for it? Mentioned they were missing it. It sounds funny to me though. I'm not a Debian user. edit: The Debian page on security features confuses me (https://wiki.debian.org/Security/Features https://wiki.debian.org/Security/Features).
- AaronFriel 9y ago
  Since the Year of Linux on the Desktop has still not come, perhaps major distributions would be wise not to use that as a reason not to implement security features. Last I checked, the Year of Linux on the Server has been every year for many, many years. And it's the servers and their vulnerabilities which are exposing tens of millions users information at a time, not individual Linux desktop users.
baldfat 9y ago
It looked like AppArmor was done for. Thanks to OpenSUSE for saving it!
ausjke 9y ago
Good idea for the server at least. For my development machine I need be able to disable apparmor easily(when it breaks my desktop). Increasing security sometimes decreases usability, especially when I just need Debian/Ubuntu for development and browsing.
- IgorPartola 9y ago
  Isn’t compromising your development machine way worse than a random server?
  - XR0CSWV3h3kZWg 9y ago
    My dev machine can't access prod data. My dev machine doesn't deploy to prod, the attack vector would be inserting malicious code, which would need to pass CR before being compiled on a build server and then deployed to prod. In my case impact to the business would likely be less if my dev machine was compromised than if prod was. It'd depend on the dedication and skills of the attacker though.
    - theossuary 9y ago
      I'm really curious if it's actually true your development machine can't pivot into prod. You don't have sufficient access on the build/ci/deploy servers to pivot into prod without code review? You don't have passwords saved/stored that are reused in critical/prod infrastructure? You have no way of accessing prod? That seems crazy to me, as I'm able to SSH into prod with a single command and password. I guess I'm further on the ops side, but still.
      - XR0CSWV3h3kZWg 9y ago
        There is a pretty strong ops/dev divide where I work. There are some repos I have admin access to, those I could push malicious code directly, execute a build and authorize a push to production. Most products I work on have a fairly long build time and that'd be a fairly noisy process (emails sent off). It'd work if you are just trying to get a shell, but it'd assuredly alert someone that something bad is happening.
language 9y ago
There's some kind of bind here between "putting burden on end-users" and "putting burden on application developers." Either you (a) ship $LSM with some defaults that are necessarily general (so as to avoid breaking applications) and let the user fit filters to their circumstances, or; (b) push for developers to write/maintain filters baked into their applications (ie. using some kernel features like `seccomp` and what-have-you).
- ris 9y ago
  seccomp and LSMs do different (and complementary) things.
  - language 9y ago
    How so? I understand they're different, but I thought there was some overlap. Don't LSMs work by hooking syscalls anyway?
    - AstralStorm 9y ago
      Seccomp can only disable syscalls. LSMs are more nuanced. Three most important difference is that it is easy to check if seccomp is available and the policy is not kept in or on a file.
      - language 9y ago
        I was under the impression that seccomp was a bit more flexible (via ptrace() and BPF fanciness) - although I guess you'd need other co-operating processes in userspace? I've only played around with it a tiny bit. Also, both kinds of policy are resident in files. I don't understand your point there.
        ris 9y ago
        It is flexible to an extent, but you still can't e.g. deference a pointer to a struct passed as an argument. And that's where much of the interesting detail is for many calls.
mtgx 9y ago
If wonder if the way most Linux "apps" work right now is what's keeping Linux from adopting more advanced security measures by default, such as Grsec, AppArmor, SELinux, or even ASLR... Instead of having one self-contained app that either works on it doesn't on your AppArmor-enabled OS, you have "dependencies". If a media-player you download doesn't support AppArmor, you can just use one that does. I think it's harder to avoid dependencies like that, if a library used by a whole bunch of programs doesn't support AppArmor.
- xj9 9y ago
  i'm pretty excited about flatpak et al, because gnu/linux will finally get application sandboxing that is reasonably easy to enforce. the dynamic lib bullshit that the community got hooked has been a huge impediment to implementing good application-level security on the linux desktop imo not so much the fact that they are using dynamic libraries, but the foolish idea that you should keep all of your applications and libraries in a single namespace in a messy pile. plan 9 showed y'all the way, but you don't listen, b/c y'all are obstinate.
  - hossbeast 9y ago
    Did plan 9 not have dynamic libs, or were they namespaced in some way? Would love a link to read about this
    - pjmlp 9y ago
      Plan 9 had dynamic libraries. Limbo, the main language for Inferno, only makes use of dynamic loading. http://www.vitanuova.com/inferno/docs.html http://www.vitanuova.com/inferno/docs.html
- craftyguy 9y ago
  > such as Grsec Well, there are totally different reasons (code quality and silly politics) preventing this one from being adopted.
zzzcpan 9y ago
"it can prevent exploited server software from accessing data it does not own and executing arbitrary code" Isn't AppArmor overly broad for something like that to be true? Exploited server software would happily provide access to the data of all users, since usually they all are withing the same trust boundaries anyway. I think it's not a good idea to enable "security features" simply because it feels like they help, without even a threat model.
- pwman 9y ago
  That's not how AppArmor works provided you lock down your server software properly -- say the server running is NTP -- that NTP server is only able to read /etc/ntp/* and /usr/sbin/ntpd only able to write /var/log/ntp* only able to execute /usr/sbin/ntpd Now you've radically limited what an exploit of this particular server can mean.
  - zzzcpan 9y ago
    Not a good example, chmod, chown and chroot accomplish pretty much the same thing.
    - boramalper 9y ago
      How? AFAIK, the only way to do it is to create a different user for each app, like Android, which seems absurd to me.
pjmlp 9y ago
Please do, that is already how I use Ubuntu since quite a few LTS releases. Ideally, every single application would be sandboxed in some way.

106 points by boramalper 9y ago

If people rant and rave about how hard pulse audio is to configure, then I can only imagine how much kick back there will be about having to configuring apparmor etc. Just saying. Personally, I'll be keeping it disabled. I used to use selinux, but eventually stopped as I didn't find the constant headache of trying to figure out why something wasn't working was related to SE or not worth it.

SteveNuts 9y ago
Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If you want to do something weird like allowing nginx or apache to serve your home directories, it takes maybe 5 minutes to google the correct se context to set on the directory and apply it, otherwise any standard installation works out of the box. There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.
- rightos 9y ago
  How about lack of necessity? I isolate my systems in many ways, using vms, tunnels and network isolation, but SELinux just doesn't fall into that, if anything's getting compromised it's the service in question that's the problem. Just because something exists doesn't mean you have to learn it and it doesn't make you lazy for refusing to do so. Proper protections extend far beyond using tools like this. Additionally, if you're running a desktop system and software installation is a frequent task, you'll have to deal with that constantly, often many times for the same application. At some point you're going to give up and say it's not worth it. Most people can't even stand the GUI based notifications of Outpost or ZoneAlarm in my experience.
  - emmelaich 9y ago
    > it's the service in question that's the problem .. But that's what selinux limits -- the "blast radius" from a compromised service.
    - rightos 9y ago
      Precisely what I'm saying, the limitation to the blast radius is already there if you've done the isolation yourself and it's only that one service that gets hit. If your Web server is on a private network with your app server and your load balancer, there's no way it can attack your database server. Basically, policies are implemented at the network and host level rather than the process and file level.
      - emmelaich 9y ago
        The risk is that an app compromised could lead to local access which allows local (root/kernel) exploits.
      - angry_octet 9y ago
        You're entirely correct, but we've become infected with SOE-think. Eventually you are always going to have a compromised node, and defence/detection in the node is hard and constantly evolving. The kernel attack surface is still large and complicated. In contrast, network interfaces are well controlled. If people started with 'deny all' in their fw permissions then added the minimal necessary holes then lateral movement would be a lot harder. I think the best argument for selinux/apparmor is that a lot of application specific security hardening can be packaged into standard configs. In contrast, there is little to orchestrate this for VMs/containers/physical hosts. Inter-VM/CNTR network control seems difficult (open vSwitch). If we could have easily configured, hypervisor enforced firewalling and encrypted tunneling then that would be more useful confinement.
  - SteveNuts 9y ago
    SELinux is all about minimizing and isolating collateral damage after a service is compromised, so if you care about that at all I'd suggest leaving it on. Also, it's probably the best protection from a zero-day exploit there is.
- jron 9y ago
  I can think of a great reason to disable SELinux; you actually use linux for a workstation and don't want fight with it every time you install a new application.
  - Hello71 9y ago
    do you also do chmod -R 777 /?
    - xyzzy_plugh 9y ago
      That seems excessive. Why not just run as root?
    - yjftsjthsd-h 9y ago
      Pretty sure that actually breaks stuff
      - jameskegel 9y ago
        This is correct.
  - Spivak 9y ago
    But you don't. Almost all 'applications' run unconfined.
  - pjmlp 9y ago
    I can think of a great reason not to disable it, exposing $HOME to the world.
    - deleted 9y ago
      [deleted]
    - hobarrera 9y ago
      Have had SELinux for almost 10 consecutive years. $HOME has never been exposed. I've no idea what you're going on about.
- throw2016 9y ago
  Selinux will become useful when it precisely lists out what it disables with transparent explanations for assumptions made. And clear error messages or alerts when it has just disabled something with proper logging. Unlike with most open source software for things like selinux that disable a host of stuff by default, documentation cannot be an after thought. And why invent weird vague terminology, what is a context? Things are complex as it is and people need to get things done. To have to waste man hours that could be used more productively more than once only to figure out its caused by selinux 'silently' without any proper error messages or logging and you do the sensible thing and disable it.
  - Spivak 9y ago
    > what it disables with transparent explanations setroubleshoot > documentation cannot be an after thought Take a look at selinux-policy-doc, it's extensive. > what is a context It's a type. But 'type' as it refers to files means something else. It's just a label that describes what kind of file it is. user_home_dir_t is user files, httpd_sys_content_t is content that can be served by apache, nfsd_fs_t are files that that can be exported by NFS. > proper error messages or logging Every single denial is logged and it contains all the details why it was denied. You're asking for SELinux to log why it wasn't allowed which is done by setroubleshoot but isn't possible in general.
    - emmelaich 9y ago
      > Every single denial is logged Not quite true. Some need to have debug turned on. See my other comment.
- staticassertion 9y ago
  Building policy by just auditing is a bad idea - you'll end up with overly general roles. Policy building is best left to the author of the applications so that they can test against it and lock it down.
  - problems 9y ago
    So what's your suggestion? Just disable SELinux for that application if it's failing?
- emmelaich 9y ago
  I mostly agree with you but sometimes it is extraordinarily difficult to find out what went wrong. audit2allow and audit2why are often helpful but at least as often they offer the wrong solution. Did you know that some selinux violations are not even reported by default? This was the case for me; selinux transitions are prevented by a filesystem mounted _nosuid_. The failure is not reported because transition failures are apparently so common and unimportant selinux does not report them by default. Took me a looong time to troubleshoot this.
- naasking 9y ago
  > Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If it were actually that easy, then you wouldn't need this step since SELinux would just do it for you. Clearly that isn't the case.
  - yorwba 9y ago
    SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Maybe it could be made more convenient by a tool that parses the log and automatically runs the commands when you answer the question with "y".
    - naasking 9y ago
      > SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Right, it requires intervention by a person who doesn't actually understand the minutiae of what the software is trying to do, so obviously they can make a properly informed choice as to what is and is not a security violation. Modern operating systems are so broken...
- hobarrera 9y ago
  > There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn. Sometimes is as simple as not having time for that. If I've urgent work to do, I can't stop my work and well my boss/client "hang on, I need to learn to configure SELinux first!". The fact that it DOESN'T work out-of-the-box immediately and needs for me to configure it (regardless of how well documented it is) is its major pitfall. These things need to work without adding ANY burden to the user. Otherwise, they'll end up disabled.
aidenn0 9y ago
I still can't get PA to directly work with my USB sound card. I ended up configuring alsa dmix for it (which is definitely not easy to configure), and pointing PA at dmix. Supposedly it should see the card arrive through hotplug and add it to the device list, but that has never happened.
- cat199 9y ago
  I've not had issues on this on Fedora (24+) - I did have to kill pulseaudio 1st though.. might try that if you have not already
- digi_owl 9y ago
  dmix is hard to configure?
  - aidenn0 9y ago
    Configuring ALSA to work properly with my USB sound was the single hardest thing I did on my gentoo box. The documentation ranges from terrible to nonexsitent and it is unclear how to generalize many of the example configurations.
- monksy 9y ago
  I have a mediabox which decided it was time to install PulseAudio for kodi. Which, that perceeded to complexly screw over audio over HDMI. (No idea why it was refusing to play audio until I disabled pulseaudio).
viraptor 9y ago
Having done all 3, I'd order them from the hardest as selinux, pulseaudio, apparmor. Out of these 3, apparmor has the most user-friendly tools to apply changes. It also allows you to easily turn off a single profile without disabling the whole system. Given those, I don't expect that many issues. But also, worth remembering that this is a proposal for an experiment. One of the things they're going to judge is how much does it affect regular users.
oliwarner 9y ago
Ubuntu has used AppArmor for years. Debian users will benefit from those years use.
upofadown 9y ago
People rant and rave about how pulseaudio is broken on their system. Pulseaudio is pretty easy to configure for most things. Sometimes it even (unexpectedly) configures itself!

qznc 9y ago

As an Ubuntu user, I suffered from AppArmor a few times and removed it. However, these days it seems to work. Worth a try, Debian.

revelation 9y ago

The Linux desktop of today still occasionally requires teaching users how to install new udev rules so they can properly use that USB serial converter or other gadget sanely. Now imagine raising that pain to the power of 10, but instead of only weird USB or "device not found" errors nothing works anymore because "AppArmor" is blocking syscalls. I can already see the StackOverflow answer that just tells you to set it to permissive, and you know what, that fixes it everytime, too! This is just a non-starter. Maybe they should look at deploying ASLR first, it's not 2000 anymore you know. (Update: they just managed to get this done with stretch, released 4 months ago! That's only like 7 years late for a crucial actual security feature)

language 9y ago
Huh, didn't know that Debian was missing ASLR. Any idea about the reasoning there?
- staticassertion 9y ago
  What makes you think debian is missing ASLR?
  - language 9y ago
    > Update: they just managed to get this done with stretch, released 4 months ago! That's only like 7 years late for a crucial actual security feature) Dunno, taking @revelation's word for it? Mentioned they were missing it. It sounds funny to me though. I'm not a Debian user. edit: The Debian page on security features confuses me (https://wiki.debian.org/Security/Features https://wiki.debian.org/Security/Features).
AaronFriel 9y ago
Since the Year of Linux on the Desktop has still not come, perhaps major distributions would be wise not to use that as a reason not to implement security features. Last I checked, the Year of Linux on the Server has been every year for many, many years. And it's the servers and their vulnerabilities which are exposing tens of millions users information at a time, not individual Linux desktop users.

baldfat 9y ago

It looked like AppArmor was done for. Thanks to OpenSUSE for saving it!

ausjke 9y ago

Good idea for the server at least. For my development machine I need be able to disable apparmor easily(when it breaks my desktop). Increasing security sometimes decreases usability, especially when I just need Debian/Ubuntu for development and browsing.

IgorPartola 9y ago
Isn’t compromising your development machine way worse than a random server?
- XR0CSWV3h3kZWg 9y ago
  My dev machine can't access prod data. My dev machine doesn't deploy to prod, the attack vector would be inserting malicious code, which would need to pass CR before being compiled on a build server and then deployed to prod. In my case impact to the business would likely be less if my dev machine was compromised than if prod was. It'd depend on the dedication and skills of the attacker though.
  - theossuary 9y ago
    I'm really curious if it's actually true your development machine can't pivot into prod. You don't have sufficient access on the build/ci/deploy servers to pivot into prod without code review? You don't have passwords saved/stored that are reused in critical/prod infrastructure? You have no way of accessing prod? That seems crazy to me, as I'm able to SSH into prod with a single command and password. I guess I'm further on the ops side, but still.
    - XR0CSWV3h3kZWg 9y ago
      There is a pretty strong ops/dev divide where I work. There are some repos I have admin access to, those I could push malicious code directly, execute a build and authorize a push to production. Most products I work on have a fairly long build time and that'd be a fairly noisy process (emails sent off). It'd work if you are just trying to get a shell, but it'd assuredly alert someone that something bad is happening.

language 9y ago

There's some kind of bind here between "putting burden on end-users" and "putting burden on application developers." Either you (a) ship $LSM with some defaults that are necessarily general (so as to avoid breaking applications) and let the user fit filters to their circumstances, or; (b) push for developers to write/maintain filters baked into their applications (ie. using some kernel features like `seccomp` and what-have-you).

ris 9y ago
seccomp and LSMs do different (and complementary) things.
- language 9y ago
  How so? I understand they're different, but I thought there was some overlap. Don't LSMs work by hooking syscalls anyway?
  - AstralStorm 9y ago
    Seccomp can only disable syscalls. LSMs are more nuanced. Three most important difference is that it is easy to check if seccomp is available and the policy is not kept in or on a file.
    - language 9y ago
      I was under the impression that seccomp was a bit more flexible (via ptrace() and BPF fanciness) - although I guess you'd need other co-operating processes in userspace? I've only played around with it a tiny bit. Also, both kinds of policy are resident in files. I don't understand your point there.
      - ris 9y ago
        It is flexible to an extent, but you still can't e.g. deference a pointer to a struct passed as an argument. And that's where much of the interesting detail is for many calls.

mtgx 9y ago

If wonder if the way most Linux "apps" work right now is what's keeping Linux from adopting more advanced security measures by default, such as Grsec, AppArmor, SELinux, or even ASLR... Instead of having one self-contained app that either works on it doesn't on your AppArmor-enabled OS, you have "dependencies". If a media-player you download doesn't support AppArmor, you can just use one that does. I think it's harder to avoid dependencies like that, if a library used by a whole bunch of programs doesn't support AppArmor.

xj9 9y ago
i'm pretty excited about flatpak et al, because gnu/linux will finally get application sandboxing that is reasonably easy to enforce. the dynamic lib bullshit that the community got hooked has been a huge impediment to implementing good application-level security on the linux desktop imo not so much the fact that they are using dynamic libraries, but the foolish idea that you should keep all of your applications and libraries in a single namespace in a messy pile. plan 9 showed y'all the way, but you don't listen, b/c y'all are obstinate.
- hossbeast 9y ago
  Did plan 9 not have dynamic libs, or were they namespaced in some way? Would love a link to read about this
  - pjmlp 9y ago
    Plan 9 had dynamic libraries. Limbo, the main language for Inferno, only makes use of dynamic loading. http://www.vitanuova.com/inferno/docs.html http://www.vitanuova.com/inferno/docs.html
craftyguy 9y ago
> such as Grsec Well, there are totally different reasons (code quality and silly politics) preventing this one from being adopted.

zzzcpan 9y ago

"it can prevent exploited server software from accessing data it does not own and executing arbitrary code" Isn't AppArmor overly broad for something like that to be true? Exploited server software would happily provide access to the data of all users, since usually they all are withing the same trust boundaries anyway. I think it's not a good idea to enable "security features" simply because it feels like they help, without even a threat model.

pwman 9y ago
That's not how AppArmor works provided you lock down your server software properly -- say the server running is NTP -- that NTP server is only able to read /etc/ntp/* and /usr/sbin/ntpd only able to write /var/log/ntp* only able to execute /usr/sbin/ntpd Now you've radically limited what an exploit of this particular server can mean.
- zzzcpan 9y ago
  Not a good example, chmod, chown and chroot accomplish pretty much the same thing.
  - boramalper 9y ago
    How? AFAIK, the only way to do it is to create a different user for each app, like Android, which seems absurd to me.

pjmlp 9y ago

Please do, that is already how I use Ubuntu since quite a few LTS releases. Ideally, every single application would be sandboxed in some way.