It's still possible to turn this off, but I have a feeling that we should enjoy our freedom to run GNU grep instead of BSD grep for as long as it lasts.
My favorite Mountain Lion feature, though, is one that hardly even has a visible interface. Apple is calling it “Gatekeeper”. It’s a system whereby developers can sign up for free-of-charge Apple developer IDs which they can then use to cryptographically sign their applications. If an app is found to be malware, Apple can revoke that developer’s certificate, rendering the app (along with any others from the same developer) inert on any Mac where it’s been installed. In effect, it offers all the security benefits of the App Store, except for the process of approving apps by Apple. Users have three choices which type of apps can run on Mountain Lion:
* Only those from the App Store
* Only those from the App Store or which are signed by a developer ID
* Any app, whether signed or unsigned
When I was 15 I wrote a Taskbar dialer for Windows 9x and later NT (this was in the modem days. Of course I haven't updated it in ages and the only reason my old webpage is still there is because I found it by accident in an old backup, but here is a google search for it: https://www.google.com/search?ie=UTF-8&q=RasInTask).
I published that on the various download pages and it was good enough to even be featured in dead-tree publications.
Back then I had no permission to use a computer ("they make you stupid" was my parents argument) and certainly no credit card to pay anybody to do development - and even then, as a minor I would probably never have gotten that certificate.
With this rule in place I would never have been able to publish that dialer. I would never have felt how it is to make something that others can use and find useful. I would never have ended up where I am today.
Does this stop malware? Does this stop fraudulent call centers? Does this stop malicious people from telling people to turn it off and then still installing the malware? No.
Does it stop people like me from ever getting to their career of their dreams? Likely.
I might be an old fart, but this is far from acceptable.
Yes but things change. Old fart or not, you're into technology, we all have to realize things change!
You can then publish it on websites exactly as you did and those who choose the appropriate security setting can run it. You have a smaller audience yes, but you can still do what you did.
And while this doesn't stop Malware, it does raise the bar a little higher.
Out of interest how would you feel about it if developer licenses were free for students?
I would be much happier (to the effect of actually seeing more good than bad in this restriction) if getting that ID was a matter of filling out a form an passing a turing test - so, for example, if any apple ID could be used to get a signing certificate, that would be much better.
(edit: this is not about the money. It's about they way of payment (minors don't have credit cards) and the required paperwork that, among other things, require you to be an adult)
Personally I'd like to see the price on Developer licenses dropped and made free for full time or part time students. I think it would make commercial and PR sense for Apple too - show that they are developer friendly and make the Mac attractive as the machine of choice for the next generation of programmers (who will then also be a shoe in on coding iOS apps).
It's also interesting that Apple is using the word "the _new_ Developer ID" in their developer site[1].
[1]: https://developer.apple.com/technologies/mountain-lion/
They reason the have the fee is to keep out people who aren't serious about development. If they didn't have it for example the forums would be overrun with people who just signed up to get the latest OS beta complaining about bugs (this is already a problem at $99).
People can still develop and distribute apps without ever signing up with Apple. This restriction is a good protection step for users imo.
As a rule the people who act like arseholes have at least as much money as those who don't, I don't think it's going to put them off.
I agree a nominal fee is reasonable as it puts another barrier in their way (you can check for duplicate memberships off the same card for instance so they have to get multiple cards) but the actual financial amount isn't a major barrier I don't think.
I don't see why Apple don't invite the developers of high-ranking iOS apps to an early-access program in order to keep their best apps up to date, and not invite anybody else to the beta.
Because every publisher, not just the "blessed" ones, has software in the store that could be negatively impacted by a new iOS release's changed APIs. And every publisher has potential use cases for new features Apple adds in a new iOS revision.
Apple ships major iOS releases at the same time as shipping the newest iOS device. They want a customer to unwrap their new device and have free roam of the store to download/buy as much as they can. They want the software to use the new features in iOS and they don't want their customers downloading crap that is broken.
And as a developer who isn't even close to "high-ranking" (My one paid iOS app maybe pulls in $50 on a good month) it's still not fair to me for someone to one-star my app and say "doesn't work on iOS 6" even when I've had no chance to test it before general release.
Charging $100 just to be capricious is not a good move and is certainly not a good omen for OS 10.9 "Tabby" wherein you can be almost certain they will remove the option to run unsigned software (for your own protection, of course! You don't want to pay Apple $100? What are you, poor? The computer cost $1000! $generic_strawman_argument!)
If you develop an app with the purpose of selling it on the Mac App Store for profit $100 should not be a problem for you.
If you want to distribute it yourself, go ahead. Apple is not charging you.
The need for a non-default security setting in order to run the software is a pretty big difference.
Requiring a developer license to work with the default security settings - thereby allowing Apple to unilaterally delete your application from your customer's computers without recourse - may only raise the bar a bit.
However, it is an entirely different development ecosystem from the one described. Microsoft couldn't delete your application or block customer's access to it arbitrarily back in the 90's.
If iOS is a precedent, the probability of Apple changing the terms of service in regards to their developer agreement in ways which have adverse effects on the saleability and distribution of existing applications is significant.
Gruber's article says signing will be free. No paid developer program membership required.
The computer isn't free either. And you can always build and distribute without the ID or the certificate. This is just for distribution through the App Store or to users that have it set to only allow signed apps.
Does this stop malware? Does this stop fraudulent call centers? Does this stop malicious people from telling people to turn it off and then still installing the malware? No.
"No" to the last question, maybe. On the other hand, it stops tons of malware. Signed binaries is considered one of the most successful anti-malware strategies by security experts. Are you saying otherwise?
Does it stop people like me from ever getting to their career of their dreams? Likely.
Well, if you are that easily discouraged, then maybe that career wasn't really for you, anyway.
You present an edge case ("I need to build and distribute my software to OS X users AND I want those users to not only allow signed apps BECAUSE I can't fork $100 dollars for a developer certificate").
If that kind of thing discourages you from "getting to the career of your dreams" what to say about the hundreds of thousands of dollars and years of toil needed to become a doctor, a lawyer, not to mention the hard learning needed to become a professional programmer.
The latter is the default. So for other people to use this application I wrote as a minor, my users would have to change the setting.
Well, if you are that easily discouraged, then maybe that career wasn't really for you, anyway.
This would not have stopped me, but imagine what kind of an ego-boost it is for a 15 years old sufferer of heavy bullying due to overall geekyness to see his home-grown application not just be used by other people but actually getting mentioned in paper publications.
Nowadays I couldn't even get /permission/ to try because these various developer programs require you to be an adult due to various organizational issues.
Honestly, without that ego boost when it happened, I don't know where I would stand today, if at all.
But this is my story. I have a feeling that I'm losing objectivity here due to heavy emotional involvement. I'll be quiet in this topic from now on and just turn that switch off for myself, hoping that there will be a switch to turn off in the future.
Yeah, but should users configure their systems to the distribution convenience of some developers?
Or should Apple keep signed apps forever away from OS X for the same reason?
Or should they introduce them, but make unsafe apps the default, and thus render them useless for non security minded people?
All of those options seem a little strange to me.
Nowadays I couldn't even get /permission/ to try because these various developer programs require you to be an adult due to various organizational issues.
Yes, but consider some other things:
a) nowadays computers are a dime a dozen and more kids have access to them than ever.
b) nowadays there are tons of compilers, programming environments, most of them given away for free and/or open sourced.
c) nowadays a kid can make a web app and reach millions of people worldwide. There are tons of ways to put it up even for free.
d) nowadays there are even kids making iPhone/iPad/Android apps, and some have reached hundreds of thousands of users.
e) the sound/graphics/processing capabilities of modern machines were unheard of in those times.
f) High Level languages like Python/Ruby/Javascript trump anything available at the old times for kids (mostly stuff like Basic, Logo, etc). Especially in the libraries department.
As you've decided to pick anonymous security experts, I thought I'd chip in. I don't know if I'd call myself an expert but I've over a decade in industry breaking systems, fixing software and booting out bad guys, I'm speaking at BlackHat EU next month and I co-founded a security conference so I guess that means I'm not a complete security chump. I can categorically tell you that signed binaries are only part of a strategy, and not necessarily the best one at that. If your goal is to increase the cost of exploitation then signing can help, but so can a decent access control model (into which signing becomes a part thereof).
To put it another way, it's possible to defeat applocker (windows binary signing), iOS code signing on iOS 5.0.1, the XBox and Xbox 360's code signing restrictions, the PS3's code signing restrictions, and more recently, an analysis of RSA keys showed that between 2 and 4 out of every thousand keys are insecure due to weak randomness[1].
The bottom line is that code signing, like placebos only work if you believe them to unless they're backed up by something more solid to augment them and they form a stronger coherent strategy.
At this stage all code signing settings will do is encourage developers to get Apple IDs and for customers to use the App store as they know "it's safe". Even though we know it doesn't mean anything[2] to the end user in reality. The real thing that Apple will do is further on the line when they decide to make it so that you can only run signed apps (and this is at least the direction apple are taking) through their app store.
Your edge case point applies to countless open source developers, including those that worked on the original FreeBSD code that went into Darwin. Apple are of course, under the licences they've inheritied allowed to implement code signing, but please don't think this is an anti-malware measure, it isn't. It's about control of distribution. Anyone that wants to bypass code signing on an Apple product will find a way to do it.
[1] - http://www.theregister.co.uk/2012/02/16/crypto_security/ [2] - http://thenextweb.com/insider/2012/02/15/what-ios-apps-are-g...
You mean things like sandboxing and blacklisting? Or do you think this is not (an attempt at) a coherent strategy?
"At this stage all code signing settings will do is encourage developers to get Apple IDs and for customers to use the App store"
It also (even if ever so slightly) decreases the attack surface. It is harder to infect executables if the OS checks the hash of the code every time it is run. Finally, it gives Apple a handle for disabling malware, once it has detected it. That will not prevent malware from infecting systems, but it can make it less likely that machines will keep getting infected for years after the time.
I would much rather have teenagers work to be able to pay $100 to distribute signed applications than make it free for anyone (malware makers) to distribute signed apps.
The trade off isn't even close here. It's free to develop the app, and even distribute it outside of the app store. If you want to go into the app store, you'll need $100, which helps keep software more secure for millions of people.
Will all of these OSX devices be regularly polling Apple to get a list of revoked certs?
I guess this would be useful to prevent malware being installed, but it's not going to be massively useful to remove already installed malware. Especially if that malware can interrupt the polling.
I wonder how difficult it will be to get developer IDs. Might be a market for them.
Will be fun to uninstall a developers software from every machine by stealing his cert, releasing some malware signed with it, and then waiting for Apple to push out a revocation cert.
Or, the signing key will be stolen, like it always is.
I'd wager that blackhats around the world are currently tendering to cartels for this contract as we speak.
Yeah, that.
Yes, the first problem will be to create some malware from OS X first. You know, the biggest success so far had been that Mac Defender, that was:
a) a trojan (you had to install it yourself)
and
b) only affected like 10 users
The current app eco-system doesn't allow them to just switch off the ability for people to install arbitrary apps. They need to get themselves into a situation where the vast majority of apps are signed first. Then it will be a lot easier for them to require apps to be signed. For your own protection of course.
EDIT: After all, if developer IDs are so easy and free to get, and will make it easier for people to install your app. Why wouldn't you get it signed?
Presumably, in order to keep the problem small. If OS X grows in marketshare, it will become an increasingly attractive target for malware developers. If the default is that the majority of Apple users only run signed applications (this also means that the certificate wasn't revoked), then the number of possible "users" for your malware is greatly reduced, making OS X a much less attractive target platform for malware developers.
> After all, if developer IDs are so easy and free to get, and will make it easier for people to install your app. Why wouldn't you get it signed?
If you are a legitimate developer, then there's no reason not to (assuming it actually is free and easy, which isn't clear). As a malware developer, there's little point; as soon as the developer ID is being used for malware, Apple will revoke the corresponding certificate, and your malware won't run.
I don't understand the question. Apple has been improving OS X security mechanisms in every OS X update. From "address space layout randomization" to the "first run warning". This is another step in the same direction.
Are you implying that Apple should only do something about OS X security AFTER malware on OS X get's to be a problem? Because, I'd rather they do it BEFORE.
And I fail to see how pro-actively making an OS more secure is "security theater".
Then it will be a lot easier for them to require apps to be signed. For your own protection of course.
Of course. I miss the irony here. Signed applications are touted by security experts as a highly successful security measure. Are you suggesting it is otherwise or are you just confusing the potential of misuse of that feature with that feature being meaningless?
* After all, if developer IDs are so easy and free to get, and will make it easier for people to install your app. Why wouldn't you get it signed?*
Yeah, why? Surely not for the $100 it takes.
SSL certificates cost money too, but I don't see anybody suggesting running your web app in plain HTTP is better, or that paid certificates hamper secure web application development.
You then replied by being sarcastic about how malware isn't really a problem.
I then asked a rhetorical question about why would they be doing this if not to defend against malware.
Now you're ranting about how malware could become a problem as if this is somehow news to me.
I'm sure you had a point.
No, you stated what you THINK they will do.
For one, most Macs are updated very often, what with Software Update and Mac Store updates. So updating a black list of applications wouldn't be a problem.
Second, they cannot just get a certificate, because they will have to interact with Apple and the developer program. You know many malware writers that want to give their details away?
Third, even if they somehow get through the second caveat above, revocation would just be a step away.
I then asked a rhetorical question about why would they be doing this if not to defend against malware.
No, you said that if they don't do it to defend against ALREADY EXISTING malware then it's either a security theater or a mystery to you why they'd do it.
As if defending against POSSIBLE FUTURE malware is a "security theater" or a strange notion.
I didn't think I would have to point out that I'm not psychic, and that it was only an opinion/prediction. I will try to be more clear in future.
"Second, they cannot just get a certificate, because they will have to interact with Apple and the developer program. You know many malware writers that want to give their details away?"
Sorry. I forgot that identity theft was impossible, and not rampant and easy and used as a matter of course by malware authors.
The last three lines of your comment are complete nonsense. You have failed to parse and understand what I wrote.
Yeah, because it is so off base, right, you writing:
"If malware on OSX is as small a problem as you're suggesting, why is Apple bothering with any of this? Is it to wrestle further control of the app eco-system on OSX? Or is it just security theatre? Or both? Something else?"
And me translating the above as you saying that if they don't do it to defend against ALREADY EXISTING malware then it's either a security theater or a mystery to you why they'd do it.
Ridiculous how?
It's perfectly valid, as in: VERY VERY VERY VERY VERY FEW OS X users ever had problems with malware. Less that what would be statistical noise. On top of it, all the cases of OS X malware, had been trojans. So, 99.9999% got scratch free, despite not even running any antivirus or anything.
So, an ACTUAL, EXISTING problem, it is NOT.
Now, a POSSIBLE, FUTURE problem, yeah, it can be.
This is why it looked like you were the one that was ignoring the future likelihood of malware on OSX, not me.
Go back to your first comment in this thread, and look at my most recent response to it. Then read my original comment. The problem here is that you simply misunderstood my initial comment, and replied to something which I did not say.
Because they're not thinking about their current problems, they're thinking about their upcoming problems.
"I guess this would be useful to prevent malware being installed, but it's not going to be massively useful to remove already installed malware. Especially if that malware can interrupt the polling."
You mistakenly read that as if I wasn't talking about malware that exists today. No. There are two situations:
1.) revocation cert issued before malware installed
2.) malware installed before revocation cert issued
Read what the world's biggest Mac-shill has to say to defend the world's least open company and biggest patent-troll?
Thanks, but no thanks.
I'll go for something open and free, and you wont get anything like that out of Cupertino.
You do know the core OS, Darwin[0], is open source? See also http://opensource.apple.com/ You may have even heard of a little rendering engine named WebKit that Apple helped create.
Also, do users get the choice to accept a certificate revocation?
But it's within the realm of possibility for Apple to start refusing support to users who disable GateKeeper. I would disable it anyway, but how many other users would?
The model essentially matches Debian package distribution.
(And as mentioned by oomkiller, this won't go down to unix, it is just the "application" launching.)
Edit: pilaf's reply got down voted into oblivion. What he suggests is flawed because applications are not in your PATH. But in the spirit, your application could write malware into somewhere on the PATH, and could find an exploit to get the setuid bit turned on. As soon as someone realizes this, Apple should kill your signing key thereby blocking the distribution vector. It will not help in cleaning up the mess. The victim is still looking at an "erase disk, reinstall, restore backup DATA ONLY!" recovery as they should anytime they lose control of a machine.
The safest place to find apps for your Mac is the Mac App Store. That’s because the developers who create them are known to Apple, and the apps are carefully reviewed before they’re accepted in the store.
As I've had no reason to upgrade my home PC from 10.6 to 10.7, EOL for 10.6 will probably be when I ditch the Mac and just dual-boot Linux and Windows. It's really amazing how much Apple has changed since the pre-OSX days.
There are only a few things really keeping a package out of the main Debain repositories: Being "non-free" (which takes it out of "main"), being clearly malicious, and not attracting enough interest to have a maintainer/packager.
I think we've seen with the iPhone that Apple has very, very different criteria. Further, Debian hosts something in the ballpark of 20,000 packages: I seriously doubt we'll ever see such diversity for the Mac, especially with their developer fees.
The other force driving me away is their refusal to accept GPL3 software. I don't like having to build things myself that every Linux distribution provides so easily.
The stated goals of Apple for gatekeeping apps are practically the same as signing packages in the distros: To protect unwary users from installing malicious or broken applications. I think that's a worthy goal.
But _normal_ users, that is not-very-technical people using Linux as a desktop, _never_ see that tgz. They wouldn't even know how to install it.
That's not the case with OSX, as far as I can tell.
In regards to OSX, the argument seems to be that this is a step towards not even having the switch there, and yes, they may be headed that way which is unfortunate. I think that's a mistake that would end up biting them if they tried it, but maybe I'm naive. I still think being more aggressive in only allowing signed binaries by default is a good approach, even for open source systems.
Changing a single setting in the Preferences app (once!) is "difficult" now?
Defaults matter. Non-technical users don't know about this computer magic.
Carefully reviewed to ensure they don't upload your whole address book.
There ARE ways to make a kick-ass, no hassle Linux OS, even better than OS X and more open (and still open source).
But all of them involve throwing top dollar into it, starting a few projects from scratch, forking a few existing ones and stoping the bazaar-style, design by committee, approach. You should only rely on upstream bazaar-style approach for the userland (like OS X does) and server backend stuff, not for visible UI, no core components, no libraries.
Canonical, and all other Linux companies, always just wanted to act like integrators, instead of creators. Except maybe in a few select areas.