5 ms·

Yet when apple makes a sandbox for apps -- which is basically this design, yet usable by people who don't understand software construction or libs -- people shr

by x0x0 12y ago

Yet when apple makes a sandbox for apps -- which is basically this design, yet usable by people who don't understand software construction or libs -- people shriek. A sandbox is a security boon for the vast majority of people. And I think this is the only way to get reasonable security; we've been banging on this "reduce bugs" plan for at least a decade with much less progress than one would hope to show for it.

higherpurpose 12y ago
It's ironic that even Android now has SELinux enforced by default, yet most Linux distros do not, even though they had support for it since a decade ago.
- vidarh 12y ago
  The reason for this is that SELinux is a nightmare to configure, and lots of peoples expectations break when dealing with it and they usually don't know how to fix things without just disabling SELinux entirely. For Android peoples expectation has from the beginning been set to expect to run into security restrictions.
  - jfindley 12y ago
    That's much, much less true than it used to be. These days there's great tools for managing and modifying selinux policy, and much better reporting of what was denied, when and why, and how to fix it. The "Selinux is too hard for mortals" thing is a relic from the early days of its inclusion into linux, and turning around this attitude is important.
    - viraptor 12y ago
      Depends how well integrated it is into the system. I tried to add any MAC to my Arch and discovered that: 1. doing everything from scratch for Tomoyo, including plugging it into grub config and creating your own policies is easier than even getting proper tools for selinux 2. Tomoyo behaves like Apparmor (policies on names not inodes), but can do more (ioctls, devices, more granular network controls) 3. Nobody uses Tomoyo and I really don't get why...
      - jfindley 12y ago
        Yeah, it's going to be an uphill struggle on any distro that it isn't already well integrated into - there's a lot of effort that goes into making SELinux in fedora/RHEL/etc JustWork(tm). Duplicating this on a distro without tight SELinux integration is going to be hard - but I tend to feel that if you use arch, linux from scratch or other similar distro, it's not really fair to blame SELinux ;)
    - badgersandjam 12y ago
      I disagree. The tools are awful and terribly slow to execute at best. Then you occasionally get shafted with a relabel.
      - jfindley 12y ago
        Can you be more specific? There's lots of different tools available - there might be some better options available than what you're using. And while tools that change things (e.g. setting booleans, changing context rules, etc) are unlikely to be instant in the near future, as the policy needs to be re-compiled, this has been improved, particularly for booleans. You can also batch updates together, which is a much nicer experience if you're trying to set a bunch of things at once. e.g. semanage -i <( echo -e "boolean -m --on httpd_use_nfs\n boolean -m --on httpd_use_sasl") That said, "this admin command I rarely use takes 30s to run" (30s seems to be about the average on RHEL 6/7) is to me an odd reason to try to avoid an important security feature. I don't recall the last time I had to do a full relabel on a production system. Not saying it hasn't happened, but I can't recall an instance. Overall, I spend less time managing SELinux (and that includes the custom policies I maintain) than I do managing IPTables. It's really not the nightmare it's made out to be.
    - vidarh 12y ago
      It's not that it's too hard for mortals, but that it provides a level of resistance people are not used to, and don't know how to deal with, and where the easiest solution is to turn it off. Whereas on Android, people expect the barrier, and developers don't expect to be able to disable it.
  - drzaiusapelord 12y ago
    This is what people were saying not too long ago on Windows when we'd complain that the apps didn't work if the user running them wasn't a local admin. Now you'd be hard pressed to find non-legacy software that doesn't work as a non-admin. In the commercial world, pressure can be brought down from on high - executives and IT purchasers discriminating against shitty software. What about FOSS? If the community has a 'meh' attitude with SELinux then things won't be easily SELinux compatible because devs don't give a shit. The same way most devs don't give a shit about most security related topics. I'm really worried that Linux has become a liability. The lax security practices of the culture its part of are obvious. What now? Do we migrate to OpenBSD? I've been considering this at work. It just seems that the culture surrounding OpenBSD just takes security more seriously. The idea that we can just put a application on the internet sounds dangerous to me. If its isn't hardened by something like apparmor/selinux and also behind some kind of application-level firewall (or at least snort), then we're just asking for trouble. Something has to change. The status quo is now failing us. How many high-priority patches have there been in the FOSS world this year? Sadly, I worry more about my linux machines than my windows machines.
- slgeorge 12y ago
  What "most Linux distros" are you talking about? Ubuntu has Mandatory Access Control in the form of AppArmor (https://wiki.ubuntu.com/AppArmor https://wiki.ubuntu.com/AppArmor). It's switched on with a set of policies on the desktop (do sudo apparmor_status to see) and on the server. On the mobile side a lot of work has been done to confine individual applications in a manner similar to Android. That's future work that could go into mainstream Linux eventually. On the traditional server side both RedHat and SUSE have MAC on by default - for them SELinux I believe.
tormeh 12y ago
If only we could abandon c and c++. That would make most security bugs go away. Source: Mozilla
- Havvy 12y ago
  It would make most security bugs caused by unsafe by default memory management which do account for a high percentage of security bugs, but logic bugs also cause security issues. See for instance SQL Injection attacks.
  - tormeh 12y ago
    Yes, but I can't help but imagine how an OS written in Rust would look. Probably a lot better than what we have today. A combination of Rust and D would probably be capable of doing everything C and C++ can, and much better.
    - 72deluxe 12y ago
      Let the language wars commence! In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. As with ANY language, if you write it badly, bad things will happen. The language choice doesn't mean bug-free code.
      - zxcdw 12y ago
        > In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. So, in essence this would mean to many that Rusts safety focus happens too late for it to be a big enough benefit for having to give up the investment in modern C++? As in, memory safety is a solved problem with modern C++?
        72deluxe 12y ago
jeffdavis 12y ago
"people shriek" Can you expand on that?
- x0x0 12y ago
  there's a search function on hn; most combinations of osx, sandbox, app, apple will yield results just one example: https://news.ycombinator.com/item?id=3191021 https://news.ycombinator.com/item?id=3191021
Perdition 12y ago
People shriek because Apple isn't giving the device owner any option to get around the security if they want to. Apple aren't using that model just for security, but also so they can tightly control the platform and restrict what the device owner can do on it.
- x0x0 12y ago
  on my mac: apple -> system preferences security + privacy General tab Under "allow apps downloaded from:" * Anywhere As for ios, if you don't believe that users would click "yes" to whatever dialogue was required to make an app run, you simply don't interact with users. Allowing users to opt-out defeats the purpose. For example, my so's mother regularly gets her gmail hacked because she will respond to any google-skinned input box asking for her password. The only way to secure the majority of users is to not allow them through their actions to un-secure themselves. Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary.
  - Perdition 12y ago
    > As for ios, if you don't believe that users would click "yes" to whatever dialogue was required to make an app run, you simply don't interact with users. Allowing users to opt-out defeats the purpose. It does not require "Click here to get owned" level of work around. I'm perfectly fine with needing to boot into the equivalent of single user mode and entering some security key. But if I want to break the security model on a device I own I should be able to. > Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary. That is circular reasoning. The "dependency" doesn't exist on iOS because Apple tries very hard to prevent non-appstore distribution being a viable avenue for app developers.
- janfoeh 12y ago
  > People shriek because Apple isn't giving the device owner any option to get around the security if they want to. You are misinformed. Right click -> Open instead of double click overrides my current signing requirements and executes the app anyway.
gurkendoktor 12y ago
I think that Apple is, on the whole, doing the right thing. But it's unfortunate that these three things (kind of) coincide: * The Mac App Store's business model, i.e. no upgrade pricing, no trial versions; content-wise, nothing that you wouldn't sell in Disneyland * Paying $99/yr for a developer account, even for free apps * App sandboxing And even then, this still doesn't mean that all apps on the App Store are safe. Because you used to be able to submit unsandboxed apps; as far as I know, they have never been removed? Sigh... But at least many of the currently un-sandboxed apps are moving to the browser (MS Office & Skype being my biggest worries).
- x0x0 12y ago
  I totally agree. But here's the thing: if you want a secure platform usable by the majority of people, the best choice (by a lot) is ios, followed by osx. The app store is certainly imperfect, but hopefully that will get tightened up over the next couple years. Relatives who've been hacked ask for how not to get hacked, and my best answer is the above: use ios, particularly for banking. For a laptop, use osx and buy programs either from well known brands (adobe, microsoft) or buy app-store apps.
Igglyboo 12y ago
You can't opt-out of Apple's sandbox.
- alwillis 12y ago
  Apparently you can opt-out at some level. I’m running Yosemite 10.10.1; according to Activity Monitor, Dropbox, VimR and Terminal aren’t sandboxed. Of course, many low-level processes aren’t sandboxed either.

by x0x0 12y ago

higherpurpose 12y ago

It's ironic that even Android now has SELinux enforced by default, yet most Linux distros do not, even though they had support for it since a decade ago.

vidarh 12y ago
The reason for this is that SELinux is a nightmare to configure, and lots of peoples expectations break when dealing with it and they usually don't know how to fix things without just disabling SELinux entirely. For Android peoples expectation has from the beginning been set to expect to run into security restrictions.
- jfindley 12y ago
  That's much, much less true than it used to be. These days there's great tools for managing and modifying selinux policy, and much better reporting of what was denied, when and why, and how to fix it. The "Selinux is too hard for mortals" thing is a relic from the early days of its inclusion into linux, and turning around this attitude is important.
  - viraptor 12y ago
    Depends how well integrated it is into the system. I tried to add any MAC to my Arch and discovered that: 1. doing everything from scratch for Tomoyo, including plugging it into grub config and creating your own policies is easier than even getting proper tools for selinux 2. Tomoyo behaves like Apparmor (policies on names not inodes), but can do more (ioctls, devices, more granular network controls) 3. Nobody uses Tomoyo and I really don't get why...
    - jfindley 12y ago
      Yeah, it's going to be an uphill struggle on any distro that it isn't already well integrated into - there's a lot of effort that goes into making SELinux in fedora/RHEL/etc JustWork(tm). Duplicating this on a distro without tight SELinux integration is going to be hard - but I tend to feel that if you use arch, linux from scratch or other similar distro, it's not really fair to blame SELinux ;)
  - badgersandjam 12y ago
    I disagree. The tools are awful and terribly slow to execute at best. Then you occasionally get shafted with a relabel.
    - jfindley 12y ago
      Can you be more specific? There's lots of different tools available - there might be some better options available than what you're using. And while tools that change things (e.g. setting booleans, changing context rules, etc) are unlikely to be instant in the near future, as the policy needs to be re-compiled, this has been improved, particularly for booleans. You can also batch updates together, which is a much nicer experience if you're trying to set a bunch of things at once. e.g. semanage -i <( echo -e "boolean -m --on httpd_use_nfs\n boolean -m --on httpd_use_sasl") That said, "this admin command I rarely use takes 30s to run" (30s seems to be about the average on RHEL 6/7) is to me an odd reason to try to avoid an important security feature. I don't recall the last time I had to do a full relabel on a production system. Not saying it hasn't happened, but I can't recall an instance. Overall, I spend less time managing SELinux (and that includes the custom policies I maintain) than I do managing IPTables. It's really not the nightmare it's made out to be.
  - vidarh 12y ago
    It's not that it's too hard for mortals, but that it provides a level of resistance people are not used to, and don't know how to deal with, and where the easiest solution is to turn it off. Whereas on Android, people expect the barrier, and developers don't expect to be able to disable it.
- drzaiusapelord 12y ago
  This is what people were saying not too long ago on Windows when we'd complain that the apps didn't work if the user running them wasn't a local admin. Now you'd be hard pressed to find non-legacy software that doesn't work as a non-admin. In the commercial world, pressure can be brought down from on high - executives and IT purchasers discriminating against shitty software. What about FOSS? If the community has a 'meh' attitude with SELinux then things won't be easily SELinux compatible because devs don't give a shit. The same way most devs don't give a shit about most security related topics. I'm really worried that Linux has become a liability. The lax security practices of the culture its part of are obvious. What now? Do we migrate to OpenBSD? I've been considering this at work. It just seems that the culture surrounding OpenBSD just takes security more seriously. The idea that we can just put a application on the internet sounds dangerous to me. If its isn't hardened by something like apparmor/selinux and also behind some kind of application-level firewall (or at least snort), then we're just asking for trouble. Something has to change. The status quo is now failing us. How many high-priority patches have there been in the FOSS world this year? Sadly, I worry more about my linux machines than my windows machines.
slgeorge 12y ago
What "most Linux distros" are you talking about? Ubuntu has Mandatory Access Control in the form of AppArmor (https://wiki.ubuntu.com/AppArmor https://wiki.ubuntu.com/AppArmor). It's switched on with a set of policies on the desktop (do sudo apparmor_status to see) and on the server. On the mobile side a lot of work has been done to confine individual applications in a manner similar to Android. That's future work that could go into mainstream Linux eventually. On the traditional server side both RedHat and SUSE have MAC on by default - for them SELinux I believe.

tormeh 12y ago

If only we could abandon c and c++. That would make most security bugs go away. Source: Mozilla

Havvy 12y ago
It would make most security bugs caused by unsafe by default memory management which do account for a high percentage of security bugs, but logic bugs also cause security issues. See for instance SQL Injection attacks.
- tormeh 12y ago
  Yes, but I can't help but imagine how an OS written in Rust would look. Probably a lot better than what we have today. A combination of Rust and D would probably be capable of doing everything C and C++ can, and much better.
  - 72deluxe 12y ago
    Let the language wars commence! In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. As with ANY language, if you write it badly, bad things will happen. The language choice doesn't mean bug-free code.
    - zxcdw 12y ago
      > In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. So, in essence this would mean to many that Rusts safety focus happens too late for it to be a big enough benefit for having to give up the investment in modern C++? As in, memory safety is a solved problem with modern C++?
      - 72deluxe 12y ago

jeffdavis 12y ago

"people shriek" Can you expand on that?

x0x0 12y ago
there's a search function on hn; most combinations of osx, sandbox, app, apple will yield results just one example: https://news.ycombinator.com/item?id=3191021 https://news.ycombinator.com/item?id=3191021

Perdition 12y ago

People shriek because Apple isn't giving the device owner any option to get around the security if they want to. Apple aren't using that model just for security, but also so they can tightly control the platform and restrict what the device owner can do on it.

x0x0 12y ago
on my mac: apple -> system preferences security + privacy General tab Under "allow apps downloaded from:" * Anywhere As for ios, if you don't believe that users would click "yes" to whatever dialogue was required to make an app run, you simply don't interact with users. Allowing users to opt-out defeats the purpose. For example, my so's mother regularly gets her gmail hacked because she will respond to any google-skinned input box asking for her password. The only way to secure the majority of users is to not allow them through their actions to un-secure themselves. Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary.
- Perdition 12y ago
  > As for ios, if you don't believe that users would click "yes" to whatever dialogue was required to make an app run, you simply don't interact with users. Allowing users to opt-out defeats the purpose. It does not require "Click here to get owned" level of work around. I'm perfectly fine with needing to boot into the equivalent of single user mode and entering some security key. But if I want to break the security model on a device I own I should be able to. > Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary. That is circular reasoning. The "dependency" doesn't exist on iOS because Apple tries very hard to prevent non-appstore distribution being a viable avenue for app developers.
janfoeh 12y ago
> People shriek because Apple isn't giving the device owner any option to get around the security if they want to. You are misinformed. Right click -> Open instead of double click overrides my current signing requirements and executes the app anyway.

gurkendoktor 12y ago

I think that Apple is, on the whole, doing the right thing. But it's unfortunate that these three things (kind of) coincide: * The Mac App Store's business model, i.e. no upgrade pricing, no trial versions; content-wise, nothing that you wouldn't sell in Disneyland * Paying $99/yr for a developer account, even for free apps * App sandboxing And even then, this still doesn't mean that all apps on the App Store are safe. Because you used to be able to submit unsandboxed apps; as far as I know, they have never been removed? Sigh... But at least many of the currently un-sandboxed apps are moving to the browser (MS Office & Skype being my biggest worries).

x0x0 12y ago
I totally agree. But here's the thing: if you want a secure platform usable by the majority of people, the best choice (by a lot) is ios, followed by osx. The app store is certainly imperfect, but hopefully that will get tightened up over the next couple years. Relatives who've been hacked ask for how not to get hacked, and my best answer is the above: use ios, particularly for banking. For a laptop, use osx and buy programs either from well known brands (adobe, microsoft) or buy app-store apps.

Igglyboo 12y ago

You can't opt-out of Apple's sandbox.

alwillis 12y ago
Apparently you can opt-out at some level. I’m running Yosemite 10.10.1; according to Activity Monitor, Dropbox, VimR and Terminal aren’t sandboxed. Of course, many low-level processes aren’t sandboxed either.