Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I disagree with your summation.

Which part? Gatekeeper is part of launch services. If you're actually a developer and you want to correctly open external executables, you can execute them with launch services and gatekeeper will kick in. If you just fork/exec or spawn something, of course gatekeeper isn't going to kick in.

But like dozens of people have said, the app can do anything it wants once you agree to it, including launch apps. You're agreeing that you trust this app because it has an identity attached to it, that's all gatekeeper is.

As an example, download VLC, open the DMG and drop it on your desktop. Now, if you double click that with gatekeeper on, you'll be blocked (in the default setting). However, if you simply execute it, it will just launch. Open a terminal window, and run `~/Downloads/VLC.app/Contents/MacOS/VLC` and it will start right up. Finally, invoke it using launch services (either using the framework, which is a bunch of work since it can't present the gui and will just fail), or again, using terminal, `open ~/Doanloads/VLC.app` and you'll see gatekeeper block it as expected.
 
Which part? Gatekeeper is part of launch services. If you're actually a developer and you want to correctly open external executables, you can execute them with launch services and gatekeeper will kick in. If you just fork/exec or spawn something, of course gatekeeper isn't going to kick in.

But like dozens of people have said, the app can do anything it wants once you agree to it, including launch apps. You're agreeing that you trust this app because it has an identity attached to it, that's all gatekeeper is.

As an example, download VLC, open the DMG and drop it on your desktop. Now, if you double click that with gatekeeper on, you'll be blocked (in the default setting). However, if you simply execute it, it will just launch. Open a terminal window, and run `~/Downloads/VLC.app/Contents/MacOS/VLC` and it will start right up. Finally, invoke it using launch services (either using the framework, which is a bunch of work since it can't present the gui and will just fail), or again, using terminal, `open ~/Doanloads/VLC.app` and you'll see gatekeeper block it as expected.

I don't feel it's necessary to repeat myself.
 
Also, Gatekeeper does have to do with the App Store, they go hand in hand... just check the 3 options in system preferences. In the first iterations I think it was only 2 options App Store or allow everything if I remember correctly.
As much as I remember it had always three options.
 
  • Like
Reactions: Carlanga
Right, that would be a Gatekeeper status escalation. Unless Gatekeeper status is set by adding the app to (user) group which has higher privileges.

No, it works with file attributes and some hanky coordination with the ls database. But it's mostly built on the old quarantine extended file attribute. It doesn't ever add it to any other user group or context. It has nothing to do with system privileges, it just prevents launch services from launching the app if it violates the gatekeeper policies.
 
But wait ... how can this be true ... when I go into an Apple store they tell me their systems are invulnerable, they never get viruses, they are impervious to attack, and Microsoft is the devil because their systems are junk ... I thought "the infallible" Apple is suppose to protect us all against the horrors of the world ... oh the humanity /sobbing.
 
If you lived in the days where an IM contact can eject your CD tray at his will, you know this is nothing to be worried about.
 
The problem is that the malicious developer doesn't need to get a developer ID from Apple at all. By bundling their unsigned application with two particular Apple-signed applications in a .dmg, they can have their software run without any Gatekeeper prompting, even when Gatekeeper is on the highest setting ("Only allow applications from Mac App Store").

This is incorrect. Under this "exploit", the only way that software runs without Gatekeeper is if it is invoked by a Gatekeeper-allowed application. Bundling mymalware.app with someonesvalidapp.app won't get past Gatekeeper unless someonesvalidapp.app calls mymalware.app itself.

The only real attack vector here is for the third party to:

1) Identify an application bundle that includes helper applications that are invoked by a developer-signed application

2) Modify/replace one or more of the helper applications to include your target payload

3) Distribute the modified application bundle as if it were the real thing

This is a real potential problem, but only under these specific circumstances. Download applications directly from the developer/vendor using their defined mirror sites, and you limit your vulnerability. Checking digital signatures and checksum/hash key values is an extra layer of protection, when provided by the developer/distributor
 
Number of vulnerabilities and end user safety are only marginally related. You are also cherry picking data by not including the vulnerabilities in applications that is listed right below the chart you included.

Why would I list the applications that makes no sense. He said youre much safer on a mac, not youre much safer on safari(webkit).
 
Apple has traditionally been so slow in terms of security updates, that we are not seeing a ton of malware only because Mac OS has such small marketshare, particularly in the backwoods of Russia, Ukraine and China....
But security by obscurity is not realy something to rely on in the long run...thankfully if the person sitting in fromt of the computer knows at least a bit ablout what he/she is doing, all current OSs are pretty safe (granted 100% safety is and probably will always be an illusion)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.