I didn't mean to be alarmist by posting this. I actually think SIP is probably a good thing. I just wanted to raise awareness so folks don't get bitten by it. I ran into this issue earlier trying to benchmark IO performance of my software on bare metal rather than in vagrant. Unfortunately, it seems iotop and iosnoop are broken unless I press this big red button that only experts can press to disable SIP, when all I want to do is a little system profiling. Maybe Activity Monitor has a scripting API I don't know about. I'm just kind of annoyed by this, I would rather dual boot into Linux than having to restart into Recovery Mode to get basic IO profiling. I can understand that DTrace could be a privilege escalation risk, but maybe Apple has an official recommendation for how to properly use DTrace or an analogous API. `iostat` doesn't cut it because I'm looking at a specific process which is run under my user. I'm not using dtrace to reverse engineer system libraries. (I think) Apple already compiles dtrace with hooks so that it won't trace specific processes to mitigate reverse engineering, which I can deal with. But hell, even `htop` is totally wrong now as I compare it to what Activity Monitor is showing.
You only need to boot into recovery mode once to change the setting, not every time. Turning it off isn't a big deal, and you have a valid reason to do so.
Most users never need any of the functionality restricted by SIP, and will benefit from the greater security it provides. Every step forward in exploit mitigation is usually a tradeoff - NX broke some programs. ASLR broke others. SIP is no different.
Personally I think I like having SIP. It means a webkit zero-day can't as easily load a kernel extension or edit firmware. I guess DTrace works by putting probes into other processes, so even though it is only "reading" system information, it's only able to instrument the data it reads in the first place by mutating other running processes.
You can also selectively disable the dtrace restrictions, while leaving the other SIP restrictions intact, with "csrutil enable --without dtrace" (in Recovery mode).
I think it's great you've shared this. With the recent SIP changes, thousands of Stack Overflow guides that involve "running a few commands with sudo" are now potentially broken. If devs/users are unfamiliar with this change, they might follow an out-of-date guide and become stuck for hours. It almost happened to me last week when I tried following a stack overflow post to fix some symlink issues with /usr/bin/. Fortunately I read about SIP previously on HN and was able to work around it. But I'm worried for the thousands of other devs that haven't heard of or encountered SIP. There needs to be more awareness of this change because it affects much more than people expect.
Takeaway: if you're following a OS X guide that involves sudo written before 10.11, keep SIP in mind or you might get burned.
I'm idly curious: what were your "symlink issues with /usr/bin/"? As with other unices, /usr is system-owned and anything not under the /usr/local hierarchy may be modified or destroyed during OS upgrades.
Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP.
Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.
One completely normal developer thing I need to do that involved turning off SIP is setting library and framework paths to debug an executable outside of Xcode.
We archive our daily builds so we can regress problems to a specific check-in. Now I could just roll back my source and build from that, but that takes significantly longer than just copying the regression build from the server. (Not to mention that if the revision is old enough, I need to install an older OS and Xcode just to build it.)
But our archives are straight out of an Xcode development build - they contain separate libraries and frameworks that we build and that aren't moved into the executable like during an install. So to run them from a disk image you need to set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to get the OS to know where to look for them. But this doesn't work with SIP. This is not some low-level kext-related issue. This is pretty basic development stuff with Xcode.
SIP shouldn't interfere with DYLD variables for normal (non-"restricted") executables. Unless you're using something like Java, which normally runs via a restricted launcher; but in that case you can bypass the launcher (see https://bugs.openjdk.java.net/browse/JDK-8139288).
Java troubles. A java application I needed required the latest java update but after running the Oracle updater, /usr/bin/java still pointed to the previous version. A simple solution is to point the symlink to the right place, but with SIP enabled that symlink can't be modified. Here's the stack overflow guide I was following: https://stackoverflow.com/questions/12757558/installed-java-...
Looking back, I think you are right, it would have been easier to just add a symlink under the /usr/local/bin folder. Though it didn't cross my mind at that point.
>Unfortunately, it seems iotop and iosnoop are broken unless I press this big red button that only experts can press to disable SIP, when all I want to do is a little system profiling.
Wanting to do "system profiling" for your "apps" already makes you an expert compared to the regular user.
And there's nothing much complicated to disabling SIP, you can do it in 2 minutes with one reboot and a command line command.
If you know how to use iotop and iosnoop, you know how to do that.
First, most people do not need to use dtrace. Especially on system processes. They claim that this is bad for security researchers because they can't monitor the system anymore and they showed a screenshot of dtrace not working even with SIP "disabled". However, from the screenshot, we see that SIP is, in fact not disabled because of this line
> System Integrity Protection status: enabled.
You can see here http://internals.exposed/blog/dtrace-vs-sip.html that with SIP properly disabled, you can run dtrace on system processes. Yes, it's confusing that it says "DTrace restrictions: disabled", when it should say "some dtrace restrictions".
Also, no security researcher worth their salt would be stopped by this (and no "bad guy" would be stopped from debugging either). In fact, dtrace is only a convenience and one tool in a toolbox; you have VMs with kernel level debuggers. You have object code analysis. You have wireshark and so on. If Apple can't stop people from jailbreaking their iphones (where hardware enforces the lockdown), they won't stop people from debugging their PC's kernel.
Basically, SIP is good for users (the "Ultimately this means that Apple has replaced the 'be all and end all' security barrier of the root password, with the 'be all and end all' SIP protection mechanism." argument is the same as "we shouldn't outlaw guns because people will find other ways of killing each other") since it makes compromising a system all that harder. If it hinders ANY security research, I question the skills of that researcher.
If you disable SIP and take over the kernel, you can probably trick software --- from both the bad guys and Apple --- into believing whatever you'd like.
I don't get that point. "Normal" users won't (and shouldn't) disable SIP. Those who do need to for security research won't really care that Apple knows they're poking into the system (when you disclose a vulnerability, they'll know who you are) and for the very paranoid, you can disable network or block connections to Apple or etc.
It's a strawman argument because for security researchers, there is never a problem of "we can't let them know we're looking". There's also no evidence that Apple phones home the status either.
And re:"barrier of entry". Who should we be protecting?
Amateur security researchers or mass users? As an amateur security researcher I'd happily allow my job to be 10x harder if it makes users even 2x safer.
If you're looking to hide your activity from malware, you should be incredibly excited by SIP. With SIP enabled, you have more protection from malware introspecting other processes or monitoring activity on the system. Hell, if you're a researcher building tools to detect and analyze OS X malware, you'd likely benefit from SIP by opting-in your tools to SIP's restrictions. (Tangential example: Chrome is taking this step; Canary is currently SIP restricted.)
Malware can only introspect SIP-protected activity by employing kernel exploits. If malware can compromise the kernel, it's game over. You're not going to hide anything, ever.
If anything, it sounds like you want SIP's purview expanded to encompass more of OS X.
I'd happily allow my job to be 10x harder if it makes users even 2x safer.
How did you become a security researcher? If it was 10x harder to get started, perhaps you might've never started, or given up long ago. A future with fewer security researchers is not a good thing, wouldn't you agree?
And by your argument the safest user is one who cannot do anything even remotely unsafe, which is a deeply disturbing dystopian thought. SIP is just another step toward an environment in which users are not longer users - they're the ones being used.
"I think the answer speaks plainly and precisely to a good part of the question, which is how the experience of using a shell as root will change. Sudo is now pseudo sudo."
http://elementary.io/ & http://www.linuxmint.com/ are the two distros I often hear about.
I have not tested them myself though, I might someday if OsX becomes too closed-up to be useful for my needs.
Even with all the random problems I had with the first version of El Capitan, I doubt that a linux distro can rival the polish of OsX though. Of course, I would love to be wrong.
Yet another move by apple to take away your control over your own machine. Some parts of the filesystem become off limits, even as root. But installers have access! That's kinda nuts.
Obviously: most users wont care or notice. But when you combine this with other changes apple has made; it's clear where they're taking OS X: just as unfriendly to tinkering and exploration as their hardware.
> Some parts of the filesystem become off limits, even as root. But installers have access!
Point of clarification: only Apple-signed installers can modify system paths. (c.f. https://support.apple.com/en-us/HT204899) All other installers are subject to SIP restrictions.
And Apple only added a few simple steps for people eager to tinker: reboot and disable SIP. Or reboot into the installer for the other OS with which you prefer to tinker. Or create a VM with an experimental OS. Frankly, most of those steps existed before SIP.
Most users shouldn't care or notice, and will benefit from increased protection. People who want to tinker will (and can and should!) tinker.
This and other developments around computer security and usability "for the everyman" worry me for two reasons.
First, they're taking away the "hard edges" from the system and helping create a generation of computer users who don't know how to tinker, how the inner bits work, or how to take responsibility for their own actions. If they download a virus, that's somehow Apple's fault for not developing a secure enough system. If they use an emoticon in their only root account password with FileVault enabled, it's Apple's fault that they are now locked out of their machine.
Second, and more worryingly, this works towards the "appification" of computers. The user's freedom to run whatever software they want on the desktop is a powerful check against the walled garden "app store" model where a central group (i.e. Apple) is responsible for determining what you're allowed to do. That's bad for innovation and freedom.
The famous Apple 1984 ad feels more ironic every year.
If they download a virus, that's somehow Apple's fault for not developing a secure enough system. If they use an emoticon in their only root account password with FileVault enabled, it's Apple's fault that they are now locked out of their machine.
To (rather awkwardly) paraphrase an old proverb: Protect users from doing potentially risky things one day, and the next day they'll complain when they screw up; let them make mistakes, and they'll continue to learn from them.
Thus my disappointment at the "users will never learn, we've been trying for years, so might as well mollycoddle and protect, but not try to teach them" argument that gets brought up so often. It took centuries for basic literacy to become prevalent; perhaps we shouldn't think computer literacy would come so quickly and cripple this learning process in the name of security.
> perhaps we shouldn't think computer literacy would come so quickly and cripple this learning process in the name of security.
What about SIP stops a person from learning computer literacy? Also huge numbers of people want nothing to do with computers beyond their immediate tasks like email, browsers, etc.
Illiterate people weren't required to read books all day to function in society, and trying to read a book and failing would not usually lead to one's life being ruined. The same is not true for computers. Computer security is much more important than book security — and even in the case of literacy, writers of safety-critical documents take pains to ensure that readers will understand important parts rather than tossing out impenetrable and ambiguous prose and telling readers to up their literacy if that's a problem.
> If they use an emoticon in their only root account password with FileVault enabled, it's Apple's fault that they are now locked out of their machine.
Ok, so: if you look into who I am, you can rest guaranteed that I agree with your overall point and conclusion... but this amazingly-very-real?!?[1] emoji scenario you've described is absolutely "Apple's fault"... if Apple lets me type an emoticon into that password field, it had better well support it reasonably :/. This is a legitimate screw up in the abstraction provided by Apple, not an unavoidable tradeoff in the reality of using a computer.
Exactly. Apple is responsible for a huge loss of freedom in the War On General Purpose Computing. This "appification" is exactly what Cory Doctorow was talking about in his famous essay[1]. We are already beginning to see some of the nastier effects that we warned about[2] with, for example, John Deere's attempt to retain ownership[3].
Apologists will complain that you can turn of SIP (or jailbreak your phone) to regain control over your computer, but that isn't possible for most people. Installing certain types of software went from "run the installer" to "follow these complicated technical instructions" (or worse).
What I find more worrying is how easily technical people are fooled into supporting this loss of freedom. Scream "security" and suddenly it's ok for Apple to have root but not the supposed "owner" of the device? Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions.
Well, this hubris will not last - once Apple can starts using the new Trusted Computing[4] features on new CPUs (such as SGX[5]), good luck regaining control.
It would be nice if more people actually bothered thinking about long-term consequences.
> Apple can [sic] starts using the new Trusted Computing[4] features on new CPUs (such as SGX[5]), good luck regaining control.
It seems the apocalypse came to pass a while back, with the Secure Enclave in Apple's A7 processors.
> Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions.
Here's the funny thing: normal people benefit from those restrictions. Without them, their devices – the ones you insist they should own – would quickly become someone else's: the attacker's. It would be awesome if people started thinking about long-term consequences.
Honest question: do you hate root? Should all processes run with equal privileges? Does the kernel have an evil and undesired permissions level?
> Honest question: do you hate root? Should all processes run with equal privileges?
Of course not. Stop making up straw-man arguments.
> Without them, their devices – the ones you insist they should own – would quickly become someone else's: the attacker's
So users cannot run any program they download? Or are you claiming that programs that run as a user - with no intention of touching system files - cannot harm that same user? Many past exploits and trojans run entirely as the user.
SIP may protect the OS, but it will do very little to protect the user. Unfortunately, while this should be obvious, scaring people into giving up their freedom works, even when the "solution" doesn't actually do much (or anything) to prevent the supposed threat.
do you hate root? Should all processes run with equal privileges? Does the kernel have an evil and undesired permissions level?
The key difference here is that root is well known to be the all-powerful user, the one that really owns the system, while SIP is Apple's attempt at removing the power that root should have.
Given that Apple could have actually taken away root's power if they wanted to, it seems kind of inaccurate to call this an attempt to do so. They have given the user the option to have root on or off with a default of "off." They didn't attempt to disable root and fail.
I understand your concerns about taking away user power, but this doesn't seem to be that. The user still has the power to do the same things, they just have to decide that they want it. You could just as well say that not making the system files world-writable takes away the user's power, but in fact it's just locked behind a door that the user has the power to open.
If a user can't turn off SIP they probably shouldn't turn off SIP, SIP is great for the vast majority of users ie normal users, and for those who don't want SIP it's easy to turn off. Basically I'm saying only technical people should be turning SIP off.
Note, that I'm biased for SIP because I'm implementing it for FreeBSD, even though I know I will be turning it off because SIP impedes my fuzzer development.
Why would a person turn off a feature they don't understand? Besides the only people who have issues with or even know what SIP is, are technical people. The average mac osx user doesn't even know about the hidden directories that SIP is protecting or what dtrace even is. If apple made it so SIP could not be turned off I would be with you on this, but you can turn off SIP.
Also what war on general computing? If a person want's full control of their operating system they can use one of the free open source ones like FreeBSD, one of the thousands of Linux distros, illumos, OpenBSD, NetBSD, etc, etc.
This doesn't have a damn thing to do with dtrace. This is about Apple asserting that they own your computer, de facto, not you.
Assumptions you're making:
* That the ability to disable SIP will always be available, forever, even though Apple has incentives to continue making their products more an "applicance" and less a "computer". I already said there are hardware features in new CPUs that are specifically designed to make that impossible. (see previous [5])
* That SIP will continue, forever into the future, to protect only those hidden directories.
* That Apple always knows what is better for the user, and won't exploit that power.
> turned off
Why is it that any time someone starts grabbing for power, there are always people that say we should ignore it because there is some workaround, or it's only an insignificant amount of power? Power is accumulated in small steps, with the hope that nobody notices until iti is too late.
As an analogy, you might say that I'm warning you that someone seems to be placing some gas cans around your property, and you might want to stop them before they decide to light a match. Meanwhile, you (and quite a few other people) are saying it's no big deal because you can just step over those gas cans - they aren't blocking the walkway much.
Apple is taking your root access away, and you're fine with it. They are saying that they de facto own your computer, not you. Yet you're fine with it.
> Also what war on general computing?
I'm somewhat shocked. All I can say is you have quite a bit of catching up to do. For the answer to that question, see my previous [1] and [2]. For [1], I linked to Doctorow's essay, but he links to his original lecture at 28C3 if you prefer. That lecture introduces the War, while [2] continues with a discussion of why we need to solve this problem now, as the ramifications extend much further than Apple and the ability to gain root.
Again, you might want to think long and hard about the long-term consequences of giving up root access to Apple. Security can be provided for the user without handing control over to Apple.
They don't assert ownership, they set a default setting to prohibit a potential security hole. This is the same principal as a master key, if there is a hole you can exploit, there exists a hole which someone else may exploit.
>That the ability to disable SIP will always be available, forever, even though Apple has incentives to continue making their products more an "applicance" and less a "computer". I already said there are hardware features in new CPUs that are specifically designed to make that impossible. (see previous [5])
That SIP will continue, forever into the future, to protect only those hidden directories.
* That Apple always knows what is better for the user, and won't exploit that power.*
All the assumptions he's making are about what ACTUALLY happens, today.
All your assumptions are about uncertain future events and "what ifs".
So you're saying we should inductively reason that Apple will never change their behavior even though they already restrict the iphone? This is a large claim.
Do you want a warning about the possible arsonist who seems to be stacking gas cans near your house? Do you want to insist that he isn't a problem because he hasn't burned your house down yet?
Both of those are claims about the future. I'm basing mine of Apple's history with the iphone and the direction their actions have taken over the last decade. The claim you describe as being "about what ACTUALLY happens today" is really a claim about Apple's behavior into the future. I see no contract guaranteeing they won't change SIP. What I do see is a lot of people seeing what they want to see.
>So you're saying we should inductively reason that Apple will never change their behavior even though they already restrict the iphone? This is a large claim.
No, I'm saying that what IS has more substance than the myriads of things that we're worried that CAN BE.
And, for this specific question mentioning the iPhone, I'm also saying that restricted, special purpose devices, which were ALWAYS sold as such (like mobile phones ever since the early nineties) are not the same as PCs which have other uses cases and history.
>Do you want a warning about the possible arsonist who seems to be stacking gas cans near your house?
Not when the only reason to think of them as "arsonist" is for stacking gas cans, when that also has another very logical explanation (e.g. he's building a gas station).
In the case of Apple, they're improving the security of OS releases, the same way Microsoft and other do. Sandboxes, secure modes, signed apps, are all standard things security researchers have been advising for years.
In all those years since they introduced signed and sandboxes apps, they never removed the ability to run non sandboxed and/or non-signed apps. So I also doubt they'll remove the ability to turn off SIP, as it's still needed for various use cases.
But even if they do change the SIP, no big deal for 99% of their customers. The rest can always use another platform, unless they value the (then) convenience, virus-tolerance etc of OS X more than they value the "do everything with them" openness of other platforms.
Just because some people started with a 'assemble yourself' kit PC in the 80s, it doesn't mean that the essence of having a PC is all about custom rigging it. And even more so, that was never the allure of Apple PCs (neither implicit or advertised). It was "it just works".
> This doesn't have a damn thing to do with dtrace. This is about Apple asserting that they own your computer, de facto, not you.
Dtrace is one of the features that is limited by SIP so yes this has something to do with dtrace.
> That the ability to disable SIP will always be available, forever, even though Apple has incentives to continue making their products more an "applicance" and less a "computer". I already said there are hardware features in new CPUs that are specifically designed to make that impossible.
Yes apple could get rid of the ability to turn off SIP, I don't believe they will. Doing so would anger developers and technical users, these people have a huge amount of say on what technology get used in their organization.
> That SIP will continue, forever into the future, to protect only those hidden directories.
I don't assume that it will only protect those hidden directories, because it protects other system resources as well. I also hope apple keeps adding to the list of protected resources, to continue securing Mac OSX and IOS.
> Why is it that any time someone starts grabbing for power, there are always people that say we should ignore it because there is some workaround, or it's only an insignificant amount of power? Power is accumulated in small steps, with the hope that nobody notices until iti is too late.
This is not a power grab, this is a company securing their products for their users. Even if this somehow is a power grab by apple, so what. No one is forced to buy apple's products, and if apple wants to do things that make there products less desirable, again so what, people might start switching to a competitor. It's not like apple is the government, nor is it a monopoly.
> Apple is taking your root access away, and you're fine with it. They are saying that they de facto own your computer, not you. Yet you're fine with it.
Apple has not taken root access from me, I can still do whatever I want on my Mac Pro.
> Again, you might want to think long and hard about the long-term consequences of giving up root access to Apple. Security can be provided for the user without handing control over to Apple.
Again I still have root on my laptop, yes I had to boot into recovery mode first, but afterwards I can sudo away. To me it seems like you haven't heard of Mandatory Access Controls, Operating systems have had the ability to reduce the privileges of root for a long time. Thats all SIP is a application of Mandatory Access Controls, SIP is built on top of the TrustedBSD MAC framework that FreeBSD, IOS, and MAC OSX all share. The MAC framework has been in IOS and Mac for a decade and apple have been slowly using it to hardened there operating systems and SIP is just a progression of this. You would think you would be happy that apple is trying to improve the security of their products.
So tell me the equivalent method to gain complete root access on an iphone. Not a jailbreak or unofficial firmware, an actual supported method by which you can become root and change anything on the device. Unless I am badly misinformed, this doesn't exist.
Your faith in Apple to not lock out SIP (or otherwise continue their trend of turning their products into appliances) requires ignoring that Apple already did that on other products.
> anger developers and technical users
So all Apple (or whomever) has to do to take away features is to make sure they have a way to satisfy or distract most of the developers and technical users. As this is not a large group of people, if they have a workaround, it does not change much.
I already said that this technological priesthood that knows how to work around these problems don't matter, as the average users are the people who will pay for this in practice.
Why would it hurt users? Because this kind of feature tends to always expand in scope when there is a financial incentive to do so. You even acknowledge this.
> I also hope apple keeps adding to the list of protected resource, to continue securing Mac OSX and IOS.
Securing for who? The owner of the computer? Or the vendors of their app store and music store?
> Apple has not taken root access from me, I can still do whatever I want on my Mac Pro.
Sometimes this isn't about YOU. This kind of selfish attitude is what allows corporations to continue taking advantage of other people.
> switching to a competitor
How many competitors are there for people to switch to? Are you stretching the definition and including competitors that are not compatible and would require re-purchasing software because the software they already paid for isn't compatible?
There is a huge cost to switching... which is why Apple absolutely is guilty of monopolizing (which is what the anti-trust laws ban, not a "monopoly" by some arbitrary market share).
> Again I still have root on my laptop,
Of course. Apparently you didn't read the part where I discussed this was a warning about the future, as power is taken in small increments.
More importantly, I find it interesting that you completely ignored the topic of the War On General Purpose Computing, which is central to this discussion. Doctorow's 28C3 talk directly address these problems and refutes many of your replies. Do you want to learn about this problem, which has been going on for many years, or are you an apparatchik that believes Apple can do no wrong?
> So tell me the equivalent method to gain complete root access on an iphone. Not a jailbreak or unofficial firmware, an actual supported method by which you can become root and change anything on the device. Unless I am badly misinformed, this doesn't exist
There isn't one, and there has never been a way to officially gain full root on an iphone. Which is fine, iphones were never marketed as a general computing device, it's a smartphone.
> Your faith in Apple to not lock out SIP (or otherwise continue their trend of turning their products into appliances) requires ignoring that Apple already did that on other products.
I could care less what apple does, it's not my primary operating system, FreeBSD is.
> So all Apple (or whomever) has to do to take away features is to make sure they have a way to satisfy or distract most of the developers and technical users. As this is not a large group of people, if they have a workaround, it does not change much.
SIP isn't taking away features, it is a feature. Secondly if apple has a well documented workaround for their more restrictive features, then yes this is the best of both worlds. As the OpenBSD crowd has shown, security features need to be on by default or they are rarely used. Apple can't rely on most of their user's to turn on the various security features. Most Linux user's turn off selinux because it's hard to setup, and I would wager Linux users are more technical on average then Mac users. And by allowing a way to turn off these security features for those who need to, it allows for people to do whatever they want with their Mac.
> How many competitors are there for people to switch to? Are you stretching the definition and including competitors that are not compatible and would require re-purchasing software because the software they already paid for isn't compatible?
There's plenty of competition in both mobile phones and personal computer markets. For mobile phones you can get smartphones from Apple, Samsung, HTC, Microsoft, BlackBerry, and a few more. As for personal computers there's Apple, HP, Dell, Lenovo, Asus, Toshiba, etc, etc. I also would like to add that even if these various products are not compatible it does not mean they are not competitors. Blenders from two different manufacturers are not compatible, but they are most definitely competing for customers.
> Sometimes this isn't about YOU. This kind of selfish attitude is what allows corporations to continue taking advantage of other people.
When it's about me and my laptop, Only thing I care about is whether I'm satisfied. And I think it's strange that you think this is an example of Apple taking advantage of people, when Apple has done far worse things to people, such as their use of cheap labour when they could easily afford to pay those people more. SIP is a good thing.
> Sometimes this isn't about YOU. This kind of selfish attitude is what allows corporations to continue taking advantage of other people.
The reason corporations do as they please is because people don't hold politicians accountable. Secondly I would like to say, have you thought whether YOU are being selfish? You want a company YOU don't own to change their product to satisfy YOUR view on how they should make their product. Especially considering this feature protects users from various types of attacks such as, loading rootkits, and hooking library functions.
> More importantly, I find it interesting that you completely ignored the topic of the War On General Purpose Computing, which is central to this discussion. Doctorow's 28C3 talk directly address these problems and refutes many of your replies. Do you want to learn about this problem, which has been going on for many years, or are you an apparatchik that believes Apple can do no wrong?
I ignored it because it was late and I was tired, but again reading through that first article, it seems like another case of people telling others how they run their business. The MPAA and RIAA, infuriate me, as well as DRM, So you know what I did, I stopped purchasing products that I knew had DRM, and I stopped going to the movie theater. As for the abuses of the DMCA law by John Deer and others people should be simultaneously not purchasing their products while lobbying their representative about changing this broken law.
And from my point of view there is no war on general computing, this is not the 80's and 90's where most software was proprietary. Computer user's have more choices for free, open source software then they ever did. Now were even seeing a open hardware movement!
No need to single out Apple. Windows has been requiring signed kernel drivers by default for probably at least as long.
Both systems offer ways to disable restrictions and reconfigure the systems for kernel development.
Not seeing the big deal with requiring developers to jump through a couple of hoops to disable security features that are genuinely useful for regular end users.
For everyone complaining about Apple taking away something or other that was important to you: please consider what SIP/"rootless" actually is.
What Apple have done here is not anything like the "dev mode" switch on Android, or the Gatekeeper "signed code only" setting. This change isn't another of the litany of changes that expand the gap between developers and regular users. This change is, instead, about creating a different model for how OS modifications happen.
For a while now, there have been two copies of OSX on a Mac: the "regular use" one, and the "recovery" partition. Both are full OSX, and can run arbitrary OSX software; it's basically like having a copy of the Linux Live CD you installed Linux from copied to your disk alongside the actual Linux install.
With SIP/rootless, Apple has effectively made it so that instead of the actively-running copy of the OS ever modifying itself, the OS will only ever modify the other copy of the OS on-disk. So you need to have the recovery OS running to modify the files of the "regular use" OS†; and you need to be running in the "regular use" OS to apply a recovery update (i.e. an update to the recovery OS.)
The procedures for getting around SIP by disabling it and then running things, are as arcane as they are because they're quite divorced from the reason for SIP. SIP isn't supposed to be a system for blocking and whitelisting kernel-hooking apps; it's a mechanism for making the OS into something more like CoreOS or the Wii's IOS: a system with two separate on-disc OS images, where at least one is always a Last-Known-Good configuration, and where you reboot into the "spare" one when you want to replace the previously-"active" one. You never fiddle with the "in-use" OS image; you consider it locked.
You still have root on the computer. You just have to be in OS-A to do root-level things to OS-B, and vice-versa.
An analogy: remember how it was impossible (and still is, on some OSes) to resize the boot partition you're running from, requiring you to instead boot from a USB to do that? That's basically what is happening here, except without the need for the USB. You can't do stupid things to the active OS; it's locked. You modify the OS by mounting it as a slave from another copy of the OS.
---
† I'm not actually sure how system updates from the "regular use" side work with SIP enabled. They could have a special exception in the SIP infrastructure, but I doubt it.
I would guess they work like iOS updates do: the update package gets downloaded by the running OS, and then a UEFI flag is written to tell the OS to reboot into the recovery OS in "update" mode. The recovery OS then unpacks and shoves the update, and reboots back.
If there is an exception in SIP for the Installer, it was likely considered more as an optimization over the above process—something to avoid making OSX feel like Windows XP, rebooting five times to get anything done.
> I'm not actually sure how system updates from the "regular use" side work with SIP enabled. They could have a special exception in the SIP infrastructure, but I doubt it.
Apple Signed (with Apple's special key) Installers are allowed to modify system paths, including the current running system to install updaets.
Interesting. I'm guessing that only gets used by minor "feature" updates (to e.g. Webkit, or iTunes), and not the full "OSX Update 10.11.x" releases.
My suspicion is for anecdotal reasons: I recently Internet-restored my MBP. This pushed it back down to OSX 10.11.0, so it had quite a few OS point-updates to go install. But before I let it do any of those, I enabled FileVault2 and let it finish encrypting. I then had the "pleasure" of watching this sequence of events repeat itself several times, a sequence of events which had never occurred before El Capitan:
1. The OS asks to restart to install an update.
2. The OS reboots and sits at the (UEFI?) drive-unlock pretend-login screen until I enter my password.
3. The OS boots into something that looks like my "regular use" OS—the Menu Bar appears, the cursor appears and starts working, and my regular wallpaper is rendered—but the Finder doesn't start, nor do any of my account's Startup Items or LaunchAgents (not sure about global LaunchDaemons.)
4. The screen (still with HID cursor control enabled!) gets covered in a fullscreen window (not a fullscreened app taking up a Space; wrong transition effect) that has the appearance of a big black screen with an Apple logo and a progress bar. You know, like the boot screen, or iOS's update mode, or a Mac's UEFI firmware update mode. But it's definitely just an app, running within whatever instance of OSX this is.
5. Having completed the update, the computer reboots again, I enter my drive-unlock password again, and I'm back into my regular-use session.
---
Previous to El Capitan, OSX Update packages would trigger a much simpler process, equivalent to the process Windows currently goes through:
1. Ask the user to "reboot";
2. instead of rebooting, stop all userland processes and enter a single-user/maintenance runlevel;
3. run some special privileged (kext?) code that installs/unpacks/shoves the update and directly manipulates the framebuffer to render a progress bar;
4. actually reboot.
---
It wouldn't make sense to change from the old process to the current one if it was just for the sake of putting the system into an SIP-disabled mode. Like you said, Apple-signed installers can flout SIP restrictions.
It only makes sense to add the extra reboot to the process if you're rebooting into the recovery OS, because having the recovery OS do the work is itself the goal, rather than just an idea born out of necessity.
If you're wondering about the "still has my wallpaper" part, though: it's not unprecedented for the recovery OS to be "fed" data from the regular-use OS, so that there's a continuity of control when you reboot into the recovery OS. For example, the recovery OS will receive a copy of any wi-fi AP keys you entered into the System keychain in the regular-use OS, so that you can re-install OSX even if you don't remember your wi-fi password.
(I say "will receive a copy" instead of "accesses" because it gets these even if the regular-use OS is sitting in the FileVault2 "locked" state from the recovery OS's perspective—or has already been blown away entirely—where it couldn't possibly just mount the volume to read your System keychain. It seems to be more that the regular-use OS will push a copy of these thing over into the recovery OS when you update them.)
He is right, but the market is still king. If you can't give efficiency to users by your more general computing platform than the walled-restricted one, then you'll be left resourceless, hence powerless, thus unable to defend your ideas any more.
Stallman is right, but he doesn't seem to be the solution.
