OS X – Safe, yet horribly insecure
allthatiswrong.wordpress.com
allthatiswrong.wordpress.com
The article also seriously underestimates the benefit of the centralized App Store model (which has an equivalent in Linux, but not Windows); despite all the horrible rejections and review issues, if it becomes the usual way to obtain Mac applications, it will greatly reduce the chance that users will come into contact with malware.
This would be "grandparent proof" and would prevent trivial kinds of social engineering used by MacDefender (which targeted clueless users).
With a bit more polish, a Linux locked to a rigorously maintained package repository could also fill this niche.
So far, she has been very happy with it. She is now using Natty and quickly transitioned to the Unity shell.
Every once in a while, I log in remotely and brush the machine's teeth. Never found anything remotely suspicious.
Parental controls will, however, disable installing apps for the user completely. They get a prompt asking for the admin password. As far as I can see there is no way to enable users to only install apps from the app store. By the way, there is such an option in iOS.
I don't think anyone ever complained about them adding options to the parental controls, so Apple could absolutly add an option to install only App Store apps to the parental controls.
That's why it's more secure. Complexity means you don't know what's going on. Complexity means you will forget something. Complexity means there's more likely to be a way to squeeze through, more likely to be a bug, more likely to be a little thing that is forgotten.
This is also a problem with complex cryptographic APIs, overly complicated things like PKCS11 and X.509, etc. It's curious that security-related systems are among the most complex, since complexity is inherently bad for security.
I call it a lack of "situational awareness."
Restrictive security that just gets in people's way is terrible security. Just like forcing people to change their password every 14 days results in people using the same password repeatedly and incrementing a digit on the end (or writing the password down and sticking it on their monitor), creating overly complex rules means that people who absolutely must deal with these things (or who have the time) do so, and everyone else just turns it off and forgets it ever existed.
The fact is there are a lot of things that SELinux makes easier. In SELinux you have your services run in contexts and you can say what they can do (e.g. can listen on port 80 but not make outgoing connections, etc.). You no longer have this ridiculous need to run as one user (root) and switch to another.
Unix security is so simple that, for my tastes, it's actually more complex to set up securely than SELinux. If you use a distro that supports it SELinux is drop dead simple anyway.
With SELinux I no longer have to worry about any switching-user nonsense. I can just give that service those specific rights. In that sense it is a lot simpler than the overly simplistic approach we've been using.
These are all standard features in most ACL-based multi-user environments.
Unix file permissions don't use ACLs, so off the top of my head I'm not sure how you would set this up on Unix. For one thing, I am pretty sure w implies delete permissions. So that group can't even exist, and if it could, there's no easy way to have that group be different from the read-only group, and still have a no-access-at-all group.
I suspect most complicated requirements can be resolved with some combination of sudo and traditional permissions but it's not always straightforward and probably won't be exactly equivalent to the way you would do it in Windows.
This complaint doesn't hold water. Those features are available within standard Unix environments (Solaris probably counts the most as a real Unix, OS X is technically certified Unix as well!).
So Unix file permissions can use ACL's. The default is POSIX file permissions but they aren't the only ones available.
It's mostly pointless to debate whether one is "better" than the other. There are advantages and disadvantages to both approaches, and it's trivial to screw up permissions either way.
The biggest advantage of unix permissions is the culture and history surrounding them, as well as the design and conventional use of the system itself. On unix, application developers, maintainers and administrators have a pretty good idea about how permissions should be set. Generally, the need to run as root is fairly well quarantined to system administration tasks. It's not perfect, but it's much better than what I remember of windows, and a quick search suggests the situation hasn't much improved. Here's a user who discovered a problem using visual studio, he was able to solve it by running as Administrator:
https://crmbusiness.wordpress.com/2011/05/12/gotcha-visual-s...
If a unix OS were to abandon too much of the conventional unix way of setting permissions (regardless of whether ACLs are used or not), you could begin introducing similar problems.
In Windows, it's there by default. I'm not claiming that windows is better or more secure, I am simply answering the question that was posed.
And that is exactly what makes it more secure than ACLs which are extremely complex and unwieldy to setup and manage.
If you can attain security by trivial actions... that's a lot better than having to be really clever about it.
I've always found compartmentation to be a far better strategy than granular control. Mostly because it means you can reason about a system at a much higher level and you do not need to keep a lot of knowledge about state in your head while doing so.
In fact, on most well-run UNIX systems I have seen, compartmentation seems to be the dominant strategy for managing security. The simplest form of which is to assign different users to different subsystems and to restrict access to these users as much as possible. For instance, if you run a database, you create a user owning all the data files managed by the database. You then, very selectively expose only what is needed to interact with the database to other users. (Interestingly you usually do not let the database user own the binaries since there is no need for the database user to manage these files).
On various UNIXen, tools for offering compartmentation have been around for quite a while. Ranging from various forms of "jails" all the way to running virtual machines. I've even been involved in running a startup that sought to harden the Linux kernel in various ways to provide some tools to make compartmentation better (although this was never any sort of commercial success -- we ended up finding success in entirely different areas :-) )
My experience with operating systems and security is that it is extremely hard to make something that is both secure and user friendly. I do not expect operating systems that are appropriate for general consumer use to become particularly secure any time soon. We make security sacrifices because quite frankly we don't know how to reconcile these problems.
It is also my experience that anyone claiming that OS A is inherently more secure than OS B is usually full of shit. In particular, anyone claiming the opposite of what empirical knowledge suggests, is a moron. Empirical knowledge seems to suggest that there is more malware and more problems with malware on Windows than any other OS, thus the statement that Windows should somehow be more "secure" is pure nonsense. Yes, it may present a larger target and more effort may have gone into making windows more secure, but to claim that it IS effectively more secure is, to be quite frank, a little bit insulting since it is a departure from observable reality.
Note that I am not saying that Linux or OSX or FreeBSD is inherently more secure than Windows, but I will say that I think the traditional way of reasoning about security in UNIX environments is a lot simpler than in Windows environments.
And simplicity is extremely important in security.
Good thing that Lion jettisons both (Samba for going GPLv3, and Java is non-core download)
The firewall functionality in OS X is impressive, but hardly utilized. The underlying technology is ipfw
Also changed in Lion, which now uses OpenBSD's pf. Apple doesn't make much more use of it though.
It has been a shame to see the sandboxing functionality introduced in Leopard not being utilized to anywhere near its full capacity.
That's changed as well in Lion, as any Mac App Store developer can tell you.
No piece of software is synonymous with insecurity -- except, perhaps, Sendmail. ;)
(Yes, I know that 'pf' started on OpenBSD.)
Shall we discuss why pfSense is based on FreeBSD, not OpenBSD?
Here’s the talk, slides (check slide 11), and related blog post:
http://www.viddler.com/explore/rentzsch/videos/31/
http://www.slideshare.net/tqbf/c42-software-security-present...
http://chargen.matasano.com/chargen/2009/9/24/indie-software...
Is this really a commonly held belief? I've never encountered anyone expressing this opinion.
I know a fair few people at Microsoft, and elsewhere, and I've never seen evidence that the engineering talent distribution at Apple is really all that different from the talent distribution anywhere else. There are superstars and dolts in the expected proportions.
that said, Steve Jobs seems (at least from external appearances) to have far more thorough top-down control over the company's engineering efforts than Steve Ballmer does; the highest I ever see engineering efforts come down from is our division director.
I compare that to Apple, which seems to have a top-down vision, from which all project behaviours and priorities descend. Lion's adding support for auto-save? You'd better believe that implementing auto-save support into iWork is a top priority, regardless of what the iWork PM thinks about it. That said, Apple seems to rarely hire people who don't share the same vision, and with that comes a certain uniformity of direction that tends to reduce inter-project scuffles.
Also, I get the sense that if (for example) the project manager for iWork was causing unnecessary friction with other teams instead of working with them towards a common goal, he'd be replaced with someone else who's more of a team player.
Also, user experience is a part of good engineering.
http://news.softpedia.com/news/Steve-Jobs-Not-Shy-of-Using-t...
we can both play this game all day.
user experience is indeed a part of good engineering, but it's not the be-all and end-all, and eventually you will /always/ run into a place where you must compromise between a system which is well-engineered and one that behaves in accordance with user expectation.
this is why OS X doesn't have full ASLR and DEP, because it can cause applications to start crashing at random because they were poorly written in a way that used to be invisible.
this is why UAC on Windows Vista is a terrible experience, because even trusted applications need to prompt the user to make sure they approve of them executing on an administrator token.
this is why our operating systems still have to reboot while applying security updates, because long-running services and the kernel have to be replaced and there's no good way to do it seamlessly yet.
And I disagree that you will always need to compromise between good engineering and good UX, for example you can certainly have ASLR and DEP with the same UX OS X currently has, they don't add any burden on the user.
Of course sometimes you need to compromise, but it's not everytime.
UAC is, in principle, not at odds with equating good user experience with good engineering. It’s all about tradeoffs.
why does the UAC need to gray/black out all the display?
It's such a mess, especially when you have more than one monitor. Is there a technical reason or is it just UX?
Right. There are ways to do it, but not any /good/ ones. Good here meaning "while still letting the software execute efficiently and without a ton of added complexity"
Good engineering is good user experience.
An app can be beautifully engineered by have an awful UX. The inverse is less likely to be true (because bugs and obvious flaws like long delays and unresponsive UIs can quickly degrade UX), but still possible.
I sincerely hope that Microsoft can turn the ship. They've got lots of really smart people and a lot of cool ideas.
This comparison doesn't even make sense, comparing a decades old UNIX design to a comparatively newly designed OS (Windows NT). POSIX permissions have stood the test of time for a long time and by far were much better than what was available in Windows for the longest time. Off course Windows NT has improved on what was available at the time.
That being said, Mac OS X since 10.4 has had ACL, so that argument goes right out of the window. ACL's are enabled by default and they function as designed.
touch testing
chmod 700
chmod +a "otheruser allow delete"
su - otheruser
ls -lahe testing
rm testing
That is because they use that exact open source software. This is a simple no shit sherlock kind of deal. Luckily those are going away and won't be in Lion. Java will be an extra download, like Adobe Flash and Samba won't be included by default because of the GPLv3.
Apple's policy regarding third-party software vulnerabilities could definitely be improved, and they already have, but it could still be better. Ultimately many of the third party tools they ship are never used by consumers and even though they may be exploitable they aren't accessible to an attacker (looking at you PHP ...)
> They are extremely difficult to deal with when trying to report a vulnerability, seemingly not having qualified people to accept such reports. Even if they do manage to accept a report and acknowledge the importance of an issue they can take anywhere from months to a year to actually fix it properly.
This has been fixed recently, they have a new head of security [1] and have increasingly shown that they are getting faster at closing bugs and bringing out updates to fix issues. Look at the Pwn2Own contest iPhone bug, Apple was notified and an update was made available that fixed only that one flaw.
Do I think they are doing the best of job? No, MSFT has them beat by a mile with their security response team (really impressive), however the above sentence makes it sound like this is still the case which is no longer true.
--
It is a pretty good article in that it shows that there are certain issues that Apple could definitely improve upon, but completely ignoring any development to OS X for the past couple of years doesn't look good at all especially when the flaws you are attempting to point out have already been fixed.
[1] http://threatpost.com/en_us/blogs/apple-hires-new-security-c...
If the user is able to escalate his privileges (whether with UAC or sudo, the OS doesn't matter) in order to install malware then he loses.
It's somewhat scary, but I'm starting to think that we will be forced to adopt something like that. Computers are used for serious stuff too (payments, medicine, things like that), and, apparently, way too many people can't be trusted to administer their computers securely. Right now people are mostly damaging own life, but if this starts happening to medical records, it's going to go beyond personal security.
It's too bad, really. Even if "developer programs" were free -- i.e., just required asking the corp for a developer key (this could be enforced on state level), it would be more of a hassle than it should be.
on an os x laptop, you can be the logged-in user and read everyone's data. file permissions don't really mean much when everything of importance on the system is owned by one user (which is running dozens of applications with large attack surfaces).
that's not really a criticism of mac os, because it's the same on a windows desktop. you need elevated privileges on both systems to be able to do certain things to the system, but if all you want to do is steal sensitive documents, spy on the system's webcam, launch DDoS scripts, or add a command to the startup/login sequence, there's no need to bother elevating privileges.
one way to fix that problem is to make the system actually use the file permissions and user separation that the system already has, so that safari is running as a separate user with no access to the operating user's home directory, and that itunes has no access to the machine's webcam.
i haven't really looked into the sandbox feature of lion, but i'm assuming it does pretty much that, just like ios' concept of each 3rd party application being segregated from each other and not able to read files it's not supposed to.
> on an os x laptop, you can be the logged-in user and read everyone's data
Shenanigans. Unless you have the password of the logged in user, you can't read stuff belonging to other users. Further, if the user in question does not have an Admin account, you're shit out of luck even if you do know their password.
Their home directory defaults to world readable, and the default umask is set so documents created are world readable, so you can read things in their home directories.
The Desktop, Documents, and so on directories are 700, so things in those should be unreadable.
if you have physical access you can do anything
If you have physical access to a machine, then you can almost always read the files off of it, except in certain cases with encrypted volumes.
MS's first multi-user OS was Windows NT in 1993, which shipped with ACLs.
That said, I agree with pretty much all of what you said.
Yeah, I get that OSX is not secure. Now move on and tell me why.
In short, I wish the author would not write like a lawyer (unless of course he IS a lawyer).
Perfect? Probably not, but it's still the OS I'm going to recommend to my mom.
If you look at the numbers for OS X as opposed to Windows XP, OS X has 1,544 vulnerabilities in 153 advisories (~10.1 vulns/advisory) and Windows has 472 vulnerabilities in 358 advisories (~1.31 vulns/advisory).
Unless you have a good reason to believe that bugs in Windows are nearly eight times "more unique" than bugs in OS X, please don't compare advisories.
I don't want to point fingers at Chicken Little, because I agree with the thesis; Apple needs to be more serious about OS X security.
Okay, beside the snark it is true, Apple should maintain security bugs better and "File Quarantine" looks to me rather rudimentary: http://support.apple.com/kb/HT3662
But as long as the "Trojan Botnets" he mentions are simple PHP scripts which are distributed years ago by pirating Photoshop and are simply killed by deleting the file and a reboot I personally stay feeling pretty secure.
That one thing has more security value than any of the advanced security techniques listed in the article like "stack canaries" and "fine grained ACL".
It's too bad there are so many security consultants that focus on the technology instead of user behaviour. If they would just look at the statistics they'd see that >90% of security issues are not technology issues, they are behavioural issues.
Sure, it would be nice to have a few of those advanced security techniques in OS X if they don't cause too much usability or performance issues, but it will have very little effect on security as a whole.
Fixed with this CSS snippet: p { font: 16px "Lucida Sans Unicode", "Trebuchet MS", Verdana, monospace; }
Security starts with an aversion towards complexity. No point in reading the rest of the article.
On the enterprise side, it's much much worse. AFP is heinous. Their kerberos implementations are painful.
They actually have checkboxes in OS X server config screens that say: "Prevent man in the middle attacks? Yes or No?"
As for kerberos, that is painful on any platform. At the moment at work I am trying to figure out why Mac OS X takes 10 minutes to connect to a Windows Server 2003 based file share, all I see with Wireshark is a bunch of Kerberos stuff being thrown around, whereas Windows clients connect without issues, but without ever attempting to use Kerberos.
anyway, hope you figure out the problem. :)
I don't really understand the point of OSX Server beyond possibly render farms (for music / movies)
Small businesses, because they are very easy to manage.
More importantly though, Mac imaging. You can't run DeployStudio on anything but a Mac running OS X Server. So if you have more than 5-10 Macs to manage, having an OS X server around is a no brainer. It doesn't cost much and it makes managing & imaging Macs as simple or simpler than PCs. This is by far its most legitimate use.
Likewise, with proper security knowledge, the holes that Apple leaves unpatched for months are "minor threats." For example, disabling Java in the web browser when there's a known vulnerability. It's an inconvenience, but so is having to always be on the watchout for things that are out of place.
Apple is not fantastic on security, but they are good enough for the current threat level, as long as you take basic security precautions.
"the impact [is] negligible as long as you follow basic security practices and can recognize when something looks out of place" is a worthless statement, because the majority of users have repeatedly proven to be unable to do that (hence MacDefender, hence the largest families of malware on Windows being fake AV.)
it also makes it too easy to hand-wave away security threats. you got a trojan on your MacBook? you obviously weren't following basic security practices.
And in the servermarket, OSx is hardly around, and is the share of various Linux servers growing larger then Windows, even.
either for what its worth osx really provides nothing impressive on the security front
Deleted comment