> Don't use Safari. The code is a mess and security vulnerabilities are frequent, but slow to patch.
Over the last two years, Safari has had half the vulnerabilities [1] as Chrome [2] or Firefox [3]. Security updates are frequent [4].
As to code being a mess... perhaps there's a particularly offensive part of the WebKit code style guidelines [5] that make them less secure than Blink code style guidelines[6]?
Yeah, I find the claim that Safari "is a mess" compared to Chrome extremely unfair (if not just plain insulting to the WebKit contributors), given that Blink and WebKit are so close to each other. The overall architectures of the two engines are incredibly similar, despite having diverged somewhat over time.
As an aside, the number of people who are qualified to speak about the "messiness" of rendering engine architecture is incredibly low.
Chrome is subject to analysis by much more people than Safari by virtue of its larger market share and cross-platform nature. In addition, Google pays a great deal for security researchers to actively find bugs in Chrome. I would take the higher number of CVEs of Chrome as a positive sign for its security, in that they are preemptively searching and fixing security vulnerabilities.
Take a closer look. Let's pick 2014 since it's a full year's data but any year will do
Safari:
61 DOS
64 Code Execution
52 Overflow
61 Memory Corruption
Chrome
86 DOS
5 Code Execution
28 Overflow
9 Memory Corruption
Of those only Code Execution matters AFAICT. That the one where someone owned your machine or at least read everything in ~/.ssh and ~/Application Support. On that Safari is ~13 times worse than Chrome.
PS: The numbers don't add up to the total because a single vulnerability can be tagged as causing more than 1 of the issues.
> That the one where someone owned your machine or at least read everything in ~/.ssh and ~/Application Support.
Not if they didn't combine it with a sandbox escape, and Safari is sandboxed too. (The profile is less restrictive than that of Chrome, but both would disallow reading your SSH keys.)
Also, counting vulnerabilities like this is pointless, given that the two browsers share a very similar rendering engine and there's a not-insignificant chance that vulnerabilities in one engine apply to the other.
Maybe you should look at how they are architected. There's a HUGE difference in how they operate. In Chrome the code the pages run in themselves can't do anything. Not true in Safari. The two are night and day different.
I'm a contributor to both Chromium and WebKit.
Sure at some level they share some code. Chrome tho pretty much implements an entire virtual and secured OS in which it then executes Blink. Safari does no such thing for WebKit.
> In Chrome the code the pages run in themselves can't do anything. Not true in Safari. The two are night and day different.
By "the code the pages run in themselves can't do anything" do you mean that Chrome is sandboxed and Safari isn't? That's not true. WebKit rendering happens in a "WebProcess" which uses the Mac Seatbelt framework for sandboxing. The sandbox file is WebKit2.framework/A/Resources/com.apple.WebProcess.sb.
Sure, Chromium's sandbox is more restrictive. It proxies more things out through the broker process. But the difference is a matter of degree, not a fundamental architectural difference.
Does it matter that Safari typically runs on Mac hardware? I would suspect having a sandboxed solution as well as teh ability to control the hardware, software and OS would be very secure, but it must be quite good that they have end to end control over the hardware and software and can integrate it.
Chrome runs as more of an application "anywhere that google can go TM". So they have to provide better sandboxing as they likely don't control the hardware/must make it easier to ship?
On Mac hardware, what do you think is "safer" ceterus paribus, Safari or Chrome?
At the danger of oversimplifying sings severely. While WebKit is open, the rest of Safari is closed source. In this day and age it should be the most common heuristic that you should always prefer more open software over less open (aka closed) software if you have a choice and security matters to you.
Sometimes it's not practical (otherwise the advice could simply be "just don't use OSX") but for browsers you do have a pretty decent choice.
I haven't exactly measured is but Apple patches for Safari also seem fairly slow compared to Mozilla or Chrome so I agree with that (same argument posted on the github)
Not in any effective way. I'm pretty sure you can take Chromium, replace the logo and branding, compile in mp4 support and drop in the 2 plugins (ppapi flash, and ppapi pdf viewer) and you'll end up with Chrome. No difference
I don't use Safari, not because of privacy concerns, but because
1. I hate the address bar how it partially hides the URL
2. It adjusts colors. Not only for images with an embedded color profile, but many colors defined in CSS are brighter in Safari than in Firefox or Chrome. This messes up my web development.
This guide has some useful tips (enable filevault2, disable mdns advertise), but recommends wholly disabling most of the usable functions of applications like calendar, finder, spotlight, etc in the name of "security", which is futile considering every single security update for OSX addresses tons of userland and kernel remote-code execution or local r00t privilege escalations[1][2][3], as well as the well publicized thunderstrike[4] family of vulnerabilities which allow for osx hw/sw compromise.
Every major/minor system update (IE 10.10.x, 10.11) will require these tweaks be reapplied as well.
Lets not call using ruby to run curl to install homebrew secure either.
Just because homebrew doesn't need sudo doesn't mean it's inherently secure, and the dependency tree of some of the software the guide recommends you install come with their own set of security issues which need to be manually maintained outside of OSX update procedures.
I'm typing this from an OSX machine with a few of these tweaks applied already, and I love using it for my desktop OS -- but if you really need to be this paranoid about security, you shouldn't be using OSX.
There are several security-or-paranoia oriented linux distros you can run.
I think you may have missed part of the title. The author isn't aiming only for security, but also privacy. Disabling calendar & spotlight seem to be aimed at privacy, not security. I'm not sure I follow you when you claim the author has disabled "applications like...finder"--I didn't get that from the article. It sounds like the author really doesn't like apps that phone home to Apple, though.
It might have been nice for the author to state explicitly which steps are aimed at security and which for privacy.
It's definitely a comprehensive guide, and disabling "phone home" services is the heaviest-hitting bit — but it's not a single large script for a reason, and as the guide mentions you should at least scan the list before blindly disabling agents named "CoreLocationAgent" and "notificationcenterui" and "TMCacheDelete".
If you'd prefer being harder to track over having Time Machine, push notifications, and several sync services work, then you can disable most of them; if you'd prefer services to work and usability of your applications, none of them.
If you're not sure of the nuances (or the pros/cons of using a "secure" Mac OSX install vs a secure Linux distro), you should research each of the services you're disabling to at least appreciate the attack surface each surface adds to your machine.
The Linux Foundation published a guide recently[1] which has recommendations for desktop.
Take into consideration that unless you're running SELinux in full-enforcing mode (NOT targeted-enforcing, the default!), you still have a HUGE attack surface on your machine if you're using a web browser alone.
This presentation[2] also goes into some detail about an overall layered security approach and touches on workstation security.
If you really-really-really need security, you could consider something like QubesOS[3] to segregate your applications.
It "just works" if the package you're installing has a corresponding SELinux profile. If it doesn't, you're in for a world of "fun" trying to come up with a correct profile.
(I've played with both SELinux and Grsecurity MAC systems in the past. I know that it's not impossible to create these profiles. I also know that it's not infrequently an enormous pain in the ass, and a thing that even experts sometimes get wrong.)
If something doesn't have a profile then it runs unconfined. That's simplified, but really does work out of the box unless you do something weird (then you flip a boolean) or very weird (then you create a custom module).
I wonder if grsec's MAC system has grown an equivalent feature in the past four or five years. (If I overlooked the existence of such a thing in grsec, I'm gonna be so embarrassed.)
For GNU/Linux I find that if you stick with the commonly used packages things in your distributions repositories (on supported hardware) things do just work and it is that simple. However, (and it is a big however!) the moment you go try something slightly different good luck to you...
OSX is not an OS one should be running if one cares about security (but then neither is unhardened Linux). Guides such as these are meaningless at best and can give people the illusion of security or worse, you can't build a fortress on top of shifting foundations.
I expect there to be a lot of criticism in this thread. May I suggest that you direct your energy towards the guide by opening an issue or pull request instead. It's a better medium for discussion and there's a chance the guide will be improved, benefiting everyone.
This looks great. However for a document that is so hyper vigilant about preventing little phone-home-to-Apple behaviors, isn't there some cognitive dissonance in the fact that it recommends installing Google Chrome? What am I missing?
The fact that, much like Mac OS, all of the phone-home-ness of Chrome can be turned off (regardless of how much doing so might be more of a threat to you)
Chrome sends every URL or key stroke in the URL bar home in the guise of checking if they are search terms, and nothing short of not using Chrome helps that.
In addition, installing Chrome created a situation where every few minutes something is connecting to Google's servers. I disabled updates, uninstalled Chrome, and removed everything Google, followed instructions for removing the updater - and something is still pinging Google every few minutes.
If there is a way to shut these off, then the author should detail this, as much as he has detailed how to fix Apple's phone-home behaviour.
> Chrome sends every URL or key stroke in the URL bar home in the guise of checking if they are search terms, and nothing short of not using Chrome helps that.
I believe you're referring to DNS prefetching [1], which is mentioned in the guide. I'm curious to know how you're determining that something is "pinging Google every few minutes". Maybe you could open a Github issue and I'll investigate it for the guide. It's definitely good to enumerate Chrome's behavior w.r.t. privacy.
> The amount of bad faith people ascribe to basic usability functions utterly astounds me.
I think most of it comes from how Google (and the industry in general) has evolved. There was a day[0] when things were labeled clearly and the default behavior wasn't to vacuum up as much data about users in the name of basic usability functions.
The amount of trust people have in companies to keep their private information safe from prying eyes is what's truly astounding.
For me, it's mostly because I believe that bad press is enough of a motivator for companies to not turn completely evil. We know the damage that Snowden did to the public image of the NSA. Imagine the NSA being a publicly traded company, it wouldn't have been pretty.
I'm sure some company will turn evil and abuse the trust that their users have given them. (I assume it will be Facebook.) But I also, maybe naively, assume this will not impact my life in a significant way.
I have all those boxes unticked, and yet Little Snitch shows me it still keeps trying to connect to Google's servers, around every 15 minutes and on start up at the very least. I asked it not to store passwords too, and it still pops up the password box to access my keychain.
Apps need access to the system keychain to do things other than store passwords, (accessing certificates for authorization is a common one), and those connections sound like the automated update checks based on their behavior. (Which I don't think you can disable- but why the hell would you?)
If you want to test that, temporarily disable the little snitch rule and keep an eye on the top right hamburger menu - it'll turn green or orange if updates are pending.
It sounds like you've decided to treat Chrome as a hostile app and are going to evaluate everything it does negatively in that light. If that's the case, why not just uninstall it?
It's not asking for access to the system keychain. No, those aren't the automated update checks because I already dealt with those. Yes, I'm treating it like a hostile app - it's an app I didn't write, has recent history of sneaking in sneaky things, ignores the settings I've chosen, and repeatedly phones home even though I've disabled every single available setting that would need to do anything other than get me the webpage I ask for. My evaluation is based on those reasons alone, not your straw man.
It has a better version of Flash, that's the only reason I keep it around.
You really don't know why anyone would turn of automatic updates? Really?
Really? I got rid of Chrome when I saw Google-stuff constantly connecting to different servers even when Chrome wasn't running. And I was kinda surprised what a bitch it was to uninstall. Google put stuff everywhere :-/
I keep Chrome around just for the occasion that I ned to use Flash.
Chrome happily installs from an OS X standard account, it does not need to be installed by an administrator. As such, it probably isn't able to put stuff "everywhere".
BTW, maybe it's just me, but I have installed Chrome as its own user. That makes it more difficult for it to spy on my day-to-day activity.
2) Frankly, Google is far more trustworthy than almost any randomly selected software company. (Don't forget that there are far more software companies out there than either of us are aware of.)
3) Unless you've taken the time to configure a MAC system, software that runs as you can access any data and transport mechanism that you can access. That's a fact of life. Anything you run on your computers can also act as a little snitch.
1) Agreed. As soon as I hear about any software doing similar even by mistake I consider whether to stop using it.
2) I sort of agree with this. Google certainly don't want to sell my keystrokes on the black market. However, they do want to store them and learn more about me and my personal autonomy and privacy mean that I don't want them to have all my data.
3) Which is exactly why one should be careful what software one installs!
Please do not enable "stealth mode" in the ALF. This violates applicable standards, impedes system and network management, and provides no additional security (as anyone with nmap can readily verify). Hosts are required to respond to unicast ICMP echo requests, period [0]. No exceptions.
"Impeding system and network management" is potentially a real argument (though one most OS X users, whose machines are not rightfully overseen by any network manager, might dismiss).
But the appeal to IETF standards that brackets that argument, with it's "period, no exceptions" language, is a bit galling. Who cares? The IETF has made all manner of silly rules in its history. Why isn't this simply one of them?
Totally agree. It's fair to realise that there are consequences to deviation from standards, but (like many people) I don't consider the fact that IETF makes something a standard to be a binding requirment on me to do something on my boxes.
For one thing, the standard was built for an extremely different internet than the one we have today.
Or at least re-enable in advance those if you call your ISP and complain about any connectivity issues. You're unlikely to know this, but some engineer will thank you in their mind.
(I've used to work at ISP. ICMP echoes towards the customer's machine is a first step in diagnosing what could be wrong - and sometimes it really helps to get an image of what's going on. Sadly, a lot of machines do not respond to those.)
While I agree this is the case for servers and workstations connected to the internet with a public IP. Wouldn't this be different for laptops and PCs that are NATed 10 ways to sunday?
They're still required to respond; it's just not possible to reach them in the first place. Which also means that there cannot possibly be any meaningful security improvement to be had by not responding. Which is to say, turning this off is even more pointless than it would be otherwise.
> Basically it's an attempt to reduce surface area as much as possible.
Attempts to reduce surface area that fail to actually achieve their goal and impede the proper functioning of networks the affected system connects to should be avoided whenever possible, no?
Hang on, if I'm going to be a real pedant, that section says that the host must implement an echo server that can reply to ICMP echo requests, it doesn't say that the host must reply to those requests. By that standard, OsX is compliant because it has the server. You don't have to enable the response.
The exception in 3.2.2.6 is for requests sent to multicast or broadcast addresses, not unicast. Or are you citing some other standard that supersedes this one?
Out of curiosity, does the recovery-mode download verify the integrity of the downloaded image (either with HTTPS or with some sort of static signature check)?
Author of AutoDMG here, and since imaging is my day job I was happy to see that the article starts with a solid introduction to deploying OS X. However I'd do a few things differently:
* It's best to build the image using a full installer of the latest version of OS X downloaded from the App Store (currently 10.10.5 14F27). Do not build a 10.10 14A389 image and apply the combo update to it as updates are meant to be installed on live systems and occasionally causes headaches.
* Rather than installing packages into the image you can include them but install them on first boot, e.g. with Outset: https://github.com/chilcote/outset
* Even better, it's easy to set up Munki for software management, this way you can keep your machines updated too: https://github.com/munki/munki
* If you build your image with AutoDMG a recovery partition should be included in the image and created automatically when you restore with asr. If for some reason it's missing you can create a package that will create it for you (again using the latest OS X installer): https://github.com/MagerValp/Create-Recovery-Partition-Insta...
gotta love how it gives out hashes for the OSX install image, and then ignores all that nonsense when installing homebrew with shellcode directly from github.
Would you mind explaining why you think that's a contradiction? The "shellcode" is downloaded over SSL from a very popular repository on github. I'm genuinely interested in your alternative approach to securely downloading and installing programs from source, and why you think this way is problematic.
You should publish the hash of the script, then the user should download it to disk, verify the script and then execute it. The same as would apply to any binary download - if a binary can be compromised so can a shell script.
Alternatively you can code review the script before executing it, which is a plus.
Hashes are useful when software is hosted on third-party mirrors or CDNs. If the software is hosted on the same server as the webpage about it, then anyone in a position to replace the download can and will replace the hash as well.
You have to trust someone to build trusted chain. Trusted CA roots from SSL are good practical choice IMO. May be NSA or China government theoretically could crack that setup, but for other adversaries it would be much harder.
anybody knowledgeable could comment on the list of disable services and agents? I can't find a good site discussing what each service/agent is and what it is for
even better, let's just execute the random contents of a URL with a Ruby interpreter. Pretty sure curl's -f will suppress any SSL errors you'd receive as someone MITM's you...
This is a commonly-repeated cargo-cult security trope: if you're going to run arbitrary code from Homebrew, your risk exposure is no different whether you download the installer and run it as two separate actions or one combined command.
The option you're thinking of is -k — -f simply tells curl to fail silently on errors, not ignore them:
This isn't exactly an answer to your question, as I do not know what the common belief could be and, as well, without doing serious research through the exploration of blogs, social networks and such to determine what said belief could be, it would be impossible to give a definitive answer.
That being said, I don't think Ubuntu is any more or less secure than OS X.
By default, neither operating system is running any publicly accessible services. By that metric, they're equally "secure" by virtue of not having anything an attacker could attack on first startup.
After that, you could look at browser exploits as the most common attack vector. They tend to go back and forth, but all of them get pretty quickly rooted in competitions like Pwn2Own.
I'm not on El Capitan, but does disabling them in the GUI work (Trust: Never)? I think that's better than removing them anyway, as it seems to persist across OS upgrades.
Over the last two years, Safari has had half the vulnerabilities [1] as Chrome [2] or Firefox [3]. Security updates are frequent [4].
As to code being a mess... perhaps there's a particularly offensive part of the WebKit code style guidelines [5] that make them less secure than Blink code style guidelines[6]?
[1] http://www.cvedetails.com/product/2935/Apple-Safari.html?ven... [2] http://www.cvedetails.com/product/15031/Google-Chrome.html?v... [3] http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?... [4] https://support.apple.com/en-us/HT201222 [5] http://www.webkit.org/coding/coding-style.html [6] https://www.chromium.org/blink/coding-style