Linked by Hadrien Grasland on Sat 25th Jun 2011 08:55 UTC, submitted by John
Mac OS X "Using a Mac may certainly be a safer choice for a lot of people as despite being vulnerable they are not targeted. However this is not the same as Macs being secure, something Eric Schmidt erroneously advised recently. I may be able to browse impervious to malware on a Mac at the moment, however I personally would not be comfortable using a platform so easily compromised if someone had the motivation to do so. In this article I address just why OS X is so insecure including the technical shortcomings of OS X as well as Apples policies as a company that contribute to the situation."
Thread beginning with comment 478638
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Just another article
by Alfman on Sun 26th Jun 2011 07:49 UTC in reply to "RE[5]: Just another article"
Alfman
Member since:
2011-01-28

Neolander,

Those things would be practically free (given the ability to sandbox an app in the first place). So it makes so little sense that we're not doing those things today. They're obvious improvements to typical security models in use today.

Operating systems also need to do a better job of managing fine grained access.

On one system after an upgrade, I was troubleshooting a mysql issue. It would fail for no apparent reason - it indicated a file didn't exist, but it did and was owned by mysql. I ran strace against mysql, and to my surprise linux was reporting that the file didn't exist. I was extremely frustrated and straced mysql as root, which worked fine. Long story short, unbeknown to me, ubuntu's "apparmor" package made the file inaccessible to mysql. I admit inexperience with apparmor, however the level of grief caused by it was totally unacceptable. A normal user might have given up and run mysql as root.

I know there's a delicate balance to be reached somewhere, but the simple rules described by Neolander would go a long way to improving usability and security.

Reply Parent Score: 3

RE[7]: Just another article
by Neolander on Sun 26th Jun 2011 08:16 in reply to "RE[6]: Just another article"
Neolander Member since:
2010-03-08

I think your post contains the description of why we're not doing sandboxing in all modern OSs already.

When you have thousands of legacy applications lying around which were never designed for a sandboxed environment in the first place, patching that huge mass of code until it works, like Linux distros which use SElinux or AppArmor try to do, is quite a challenge.

This is why I think that Apple have hugely messed up by not making sandboxing a core part of iOS' design while they could. But well...

Reply Parent Score: 2

RE[8]: Just another article
by Alfman on Sun 26th Jun 2011 09:38 in reply to "RE[7]: Just another article"
Alfman Member since:
2011-01-28

Neolander,

"When you have thousands of legacy applications lying around which were never designed for a sandboxed environment in the first place, patching that huge mass of code until it works, like Linux distros which use SElinux or AppArmor try to do, is quite a challenge."

Well this is a given. And it's made all that much more confusing due to the fact that between posix user/group/other bitmasks, ACLs, SeLinux/AppArmor, and NFS shares, the access rights can be totally contradictory. There's just no practical way to determine access rights under linux without actually testing them. The gnome file browser (along with nearly 100% of tools) doesn't even display ACL. I don't think *nix will ever recover from it's POSIX roots.

When I was a windows admin, I never had this problem even with complex DFS file systems across servers.

I'm curious about what MacOS does.

Reply Parent Score: 2