Apple's fruitless rootless security broken by code that fits in a tweet Apple's much-hyped rootless security mechanism in OS X can be evaded even in the latest version of the operating system, according to a top researcher. The Cupertino goliath fixed an exploitable bug in its rootless code in the latest round of patches for Macs and iThings. But that's the not the end of the story, we're told. …
"In which case this is hardly the disaster its made out to be.
But "root user can bypass SIP" doesnt have the same ring to as a headline it does it?"
Would "SIP is intended to prevent root from doing stuff, but it fails to stop root from doing stuff." be easier to take ?
What annoys me more than headlines and people trying to trivialise the problem, is that we have a security feature that fails to perform it's primary function.
These *trivial* exploits are evidence that some folks have modified very sensitive and important bits of the kernel (e.g: validation of permissions) and have failed to test their changes adequately, and what's worse the nature of the failures indicates that they don't actually understand what they are doing. There's a fair chance that those changes have broken other bits of the OS too - given that those folks didn't seem to know what they were doing - or take it seriously enough. :(
What annoys me more than headlines and people trying to trivialise the problem, is that we have a security feature that fails to perform it's primary function.
What even annoys me more than people not being able to tell the difference between and it's and its (which by default will see some grammar or spelling mistake sneak into this post) is the black and white view some people deploy when it comes to security. There is no absolute answer here and I prefer root level + SIP well over just root.
It is a vulnerability? Yes, it renders SIP less effective than it ought to be so it needs fixing, like all weaknesses ever detected. But one element of risk is also the likelihood of it hitting your system, and the writeup omits a rather vital detail in this respect: what rights does that code need to have for it to do its evil deeds. How prevalent is this code in the software you obtain? How exposed are users who stick to app store and known sources? Has it been found in the wild?
THAT is the data you need. But hey, that would required doing actual *research*. You know, real journalism.
As for "it fits in a tweet": boohoo. So does "rm -rf *" - shock, horror, that even works on Linux!
Now go away and let me sleep.
IIRC North Korea implemented the super root idea a couple years ago in it's state sanctioned Linux distro.
Is not this just another case of Apple stealing an idea from a competitor and claiming credit?
Sigh. "its" is the possessive pronoun. Hands off the apostrophe key and back away slowly.
I'm saddened, though not surprised, that this got two upvotes. I know history is hard, but really, folks, would a smidgeon of research kill you?
Some UNIX flavors had ACL support back around 1990, and some of those implementations restricted superuser access. NFS root-squashing behavior predates version 3 (RFC 1813 says "present in many server implementations"), and if memory serves was also available in 1990.
POSIX 1003.1e/2c drafts were completed in 1997, and they reflected various existing proprietary mechanisms for, among other things, reducing superuser privileges.
Others have already mentioned SELinux, which grew out of the NSA's TRUSIX working group, which was established in 1987, which also saw the initial version of IBM Secure Xenix, which later became Trusted Xenix, the first OS to achieve B2 classification. (SELinux itself was released in 2000.)
This sort of thing - reducing superuser privilege in UNIX-like OSes - is old, old, old.
Holy shit, some of you haven't read the article or understood it. This is about Apple trying to water down root's abilities and limit the damage a process with root privileges can do. You don't need to be root to wipe or siphon off the user's files, but you do need to be root to install a long-term rootkit that the user isn't aware of and cannot get rid of, for instance.
Apple, amid its constant PR campaign to persuade people that it makes super secure software, introduced SIP aka rootless, but it's not perfect and has design flaws. This is what we're pointing out.
The tweet-fitting code demonstrates how easy it is right now to bypass SIP. Fair play to Apple engineers for trying to secure their software. But there's a massive difference between claiming to protect consumers and actually doing it.
Apologies for scrutinizing a multibillion-dollar company with 1bn active devices :-(
C.
But there's a massive difference between claiming to protect consumers and actually doing it.
Hang on a second - are you genuinely stating here that Apple does not protect consumers? As far as I can tell, they still offer the safest platform out there right now for people who are NOT experts or deep digging technologists. A bug has been found in SIP, fine, that needs fixing. But a Unix + SIP is still a level up from a Unix *without* SIP, unless you want to hold Apple to a different standard as the rest.
Their hardware is decent enough to annoy law enforcement, it's considerably less risky to install an app from their App Store than from any competition in both iOS and OSX and they actively work to even further their security. I can't call that "not protecting customers".
Your fake apology doesn't work either. You're not scrutinising, you are desperately seeking for faults to confirm a bias that is actually out of character for you. You're better than this. What's up?
@AC,
"Hang on a second - are you genuinely stating here that Apple does not protect consumers? As far as I can tell, they still offer the safest platform out there right now for people who are NOT experts or deep digging technologists. A bug has been found in SIP, fine, that needs fixing. But a Unix + SIP is still a level up from a Unix *without* SIP, unless you want to hold Apple to a different standard as the rest."
Er, I think that the point really is that whilst SIP in theory has some benefit in looking after a non-technical user, in practice making that protection bullet proof is very difficult and, consequently, the advertised protection is illusory. It may be effective in stopping a user accidentally cocking things up even if they try quite hard, but that's a different use case to stopping malicious code causing havoc.
As I understand it, as the article points, out it took years for the Unix crowd to get it right, and all they were doing was trying to lock down the single binary that would elevate your privileges to root if you knew the password. All it had to do was one thing, and it took ages to get that right. Finding the bugs was like looking for a needle in a sewing box.
What Apple have apparently done is to imbue whole swathes of the OS's binaries with super-root powers, and unless they're all completely locked down too then they represent a hole in SIP's defences. That's not impossible, but just the shear amount of effort involved in ensuring that they're all bug free makes it unlikely that they've got it completely right. Finding all the bugs is going to be like looking for a needle in a hay stack, and Apple have gone and installed a whole load of haystacks.
@diodesign,
"Holy shit, some of you haven't read the article or understood it."
Oh come on, splutter splutter splutter (that's the cuppa tea gone south), how long have you been writing for El Reg?!?!? "Commentards on public forum fail to comprehend article shocker"?
Besides, it's theregister.co.uk, which means there's going to be a high background level of ironic humour, some of it possibly found in your own post :-)
Really we're just all playing nicely, nodding wisely, and gratefully absorbing the sage wisdom of this esteemed organ's journalistic output (sorry - getting all Private Eye there), and putting off the moment when we really do have to go and do the washing up. We are all really most very grateful :-)
"Would the way the OpenBSD project is going be any better with 'pledge'?
Or just as vulnerable to replacement of binaries?"
'pledge' addresses a completely different set of problems, essentially pledge reduces the window of vulnerability - and it won't make a file system immutable. I like the idea of pledge, and it has been formulated by folks who have good form on making useful (and battle proven) contributions to security, but it doesn't give me the warm fuzzies. At the end of the day pledge is an extra tool for coders to use (and abuse) and I think it's too early to judge whether it's being well used. ;)
SIP only exists because a home user will obediently type their password into anything. Now OS X always has come with a passwordless root user, to get root you use sudo -s and type your own password and if your user has admin privilidges you'll get it.
SIP isn't really necessary, what's necessary is an admin and a standard user with different passwords and a user which won't obediently type their password into anything that asks. Is that too complicated for the average home user? It seems so.
With SIP Apple is also saying they don't trust the root user or suid binaries. That is fixed by making sure OS binaries can't be exploited, not sticking a what is essentially a passwordless superroot user on top. It could be passwordless root users all the way up, it doesn't make it a particularly good design.
Pledge is a good way to defend against exploits, meaning a kernel will not allow an exploited binary to do something which in normal use it would never do anyway. They should incorporate it into OS X.
a user which won't obediently type their password into anything that asks
Yes, let's blame the user. That's been so effective in improving IT security over the past several decades.
What's needed are users who are technically competent and always vigilant. In fact, better replace all of the users with bots.
Here's an idea: What's needed is a world with no attackers. There, problem1 solved.
1For sufficiently small values of "problem". IT security is not solely a question of resistance to malice. Security, properly defined, means a system that does what it is intended to do, and no more; since that goal can only be approached asymptotically (and no one's ever gotten anywhere close), we also include various partial measures - mitigations, countermeasures, audit trails - in security systems and processes. Getting rid of attackers still leaves you with error and accident.
"Yes, let's blame the user. That's been so effective in improving IT security over the past several decades."
As the comedian once said, "You can't fix stupid," and stupid can break a lot of stuff no matter what you try to mitigate it (because the ways they can break it are often equal to the stuff they need to get their job done with no way to separate the two).
This post has been deleted by its author
This post has been deleted by its author
"Furthermore, if you read this thread, which describes a way to DOS an OpenBSD, box requiring a power cycle to fix"
Reading the original post I can see why they reacted as they did, and I can see why that irritated you to. :)
However the teasing looked fairly tame, and they did take it seriously once the difference between mount & mount_mfs was pointed out... With respect to including basic UNIX sysadmin knowledge I think you are being a little harsh because attempting to mount mfs on top of / is not something that I would expect folks to see very often...
Would the way the OpenBSD project is going be any better with 'pledge'?
No idea. It will leave it a lot shinier, though.
The one with the IKEA bills, thanks.
This post has been deleted by its author
"Would the way the OpenBSD project is going be any better with 'pledge'?
Or just as vulnerable to replacement of binaries?"
When I look back at all the security tricks we've come to take for granted I think privilege separation becoming accepted is the biggest step forward. Pledge complements priv-sep. Very crudely you could have a very simple sandbox program that makes a bunch of pledges and then calls/execs untrusted code with very little coding effort.
Watching humans trying to do IT Security... ...so cute.
It's hopeless.
Really? So why are you still online then? Give us your wisdom, oh great one. And by that I mean data generated by experience, by having been working on the topic yourself.
There are a great many people working on security who do their best to make it better. There is still room for more but it requires people who don't give up easily because you're up against idiots, and by that I don't mean users, but government officials.
Really? So why are you still online then? Give us your wisdom, oh great one. And by that I mean data generated by experience, by having been working on the topic yourself.
Indeed. While the original post might have been smirk-worthy, "hopeless" is not a useful evaluation.
Security has never been an achievable absolute. It's always been a matter of economics: push as much of the costs as possible from the system-functions-correctly side to the system-functions-incorrectly one. Some security measures are not very successful at that;1 others are in fact counterproductive, increasing rather than reducing costs for "defenders" (i.e., legitimate uses of the system in question).
At this point, SIP, like other attempts to provide finer-grained superuser privilege in UNIX-like OSes, still looks like an overall win. True, the exploits detailed in the article are classic, well-known vulnerabilities (like trashing configuration files using the output of a privileged command). But SIP is low-cost for defenders: it's not complicated and couldn't have required much effort to implement, and it doesn't require anything from most users or developers. So if it blocks some generic or unsophisticated exploits, then it's paid for itself.
1Like, say, the public X.509 hierarchical PKI, which is an enormously expensive system with bad failure modes, and which fails in major ways a few times a year, and in minor ones who knows how many times a day. It's a great example of terrible design.
Of course it isn't a magic bullet. Existing security in both the Windows and Unix-derived worlds is too close to being perimeter-only for safety. We need at least three things to make life difficult for malware and for ransomware in particular.
First, instead of accessing storage on their own user processes should go through a back-end with specific permissions. My particular experience of this is with Informix where normal usage is to assign one or more allocations of raw disk, chown informix:informix, chmod 660 but this idea isn't specific to a particular product.
Secondly, introduce a concept of application permissions that sits alongside user permissions. The backend might, for instance be run by user and group odf-storage and only accept read/write requests from odf-user which would own the likes of LibreOffice and OpenOffice applications and even then only honour requests that matched the user's permissions.
Thirdly, and this is where something like Apple's idea comes in, the kernel would lock root out from changing such storage on its own account; it would need to be authorised by a specific user, such as odf-admin for instance, to de-allocate odf storage.
There are a good many practical difficulties is this, primarily in maintaining the chain of authenticity through updates. But Unix security has been watered down over the years in the name of convenience and Windows, starting as a single user system, has found it difficult to build security in and their problems won't be addressed by simply wringing our hands when things get hard.
It would also help if email had signing built in as part of the core protocol, web-advertising would just die and web 2.0 designers didn't rely on hauling in bits of code from sites over which they have no control.
I dunno, I think that root is enough, the problems seem to have been introdiuced by tweaking the formula. As someone else pointed out, security has gotten "watered down" in an effort to make life easier, which implies that it was pretty darn good to begin with, Having a user to authorize root? Ummm... no, root should be in control, full stop.
The question "Why did Apple feel that root, administrator of the system, needed to be locked out"? Has not been answered. If the person responsible for the system borks their computer or company server then that is something that they must deal with. If the vendor has given themselves special permissions then I can not trust that my system is under my control. So what other reasons were there?
I dunno, I think that root is enough, ...
It depends on the use case though. There are situations where the fairly course grained unix permission system just isn't suitable. For example, you may have a system where root needs to administer the actual computer, but you wouldn't want the root user to have full control over the system; for example you may have sensative information on there, which the systems administrator may not be authorised to read. In these situations you do need a permission system that can allow full control of the computer but not unrestricted access to everything.
The other problem arises that the other major OS that provides a decent hierachical fine grained permission system is NT, which unfortunatly got Windows grafted onto it (and all the historical baggage that came with it), and whilst, in theory, it has a much better more fine grained system for permissions, in reality it's complex and troublesom and very very easy to misconfigure; so many people simply don't bother. (Plus I suspect it's slightly broken as I've more than once had the 'effective permissions' dialog show me I should be able to access a file....)
The question "Why did Apple feel that root, administrator of the system, needed to be locked out"? Has not been answered.
Apple don't make 'computers' in the traditional IT sense, they make computers for consumers; and sometimes, in Apple's opinion (and I must confess having done many years of 'IT support' for friends it's an opinion I can sympathise with*), sometimes consumers need protecting from themselfs; whilst still being able to install software that requires system wide accesss.
If the person responsible for the system borks their computer or company server then that is something that they must deal with.
If the person responsible is a trained IT professional then absolutly, yes. But just as we let non trained mechanics drive cars, sometimes non IT professionals need or want to use computers. Apple is trying to minimise the amount of time these people spend calling Applecare, or negative fallout from the 'I didn't click on ANYTHING, it just BROKE' crowd. Had OSX been designed from the ground up it probably wouldn't have the concept of 'root' in the traditional sense, but it's an evolution of a 26 year old OS. (with it's roots much further back than that).
*Seriously; once had a friend who on finding an issue just started randomly deleting files in C:\WINDOWS that they 'didn't like the sound of'. It didn't fix the issue. :(
"It depends on the use case though. There are situations where the fairly course grained unix permission system just isn't suitable."
Of course. :)
"For example, you may have a system where root needs to administer the actual computer, but you wouldn't want the root user to have full control over the system; for example you may have sensative information on there, which the systems administrator may not be authorised to read. In these situations you do need a permission system that can allow full control of the computer but not unrestricted access to everything."
I think those use-cases could be addressed with tools such as sudo & doas and some care. Again those tools aren't a panacea. :)
"Apple is trying to minimise the amount of time these people spend calling Applecare, or negative fallout from the 'I didn't click on ANYTHING, it just BROKE' crowd"
I suspect you are right, but the motivation is to prevent the user from doing stuff rather than securing the box. That motive would also fit with the evidence of careless design & implementation from a security viewpoint.
<quote>For example, you may have a system where root needs to administer the actual computer, but you wouldn't want the root user to have full control over the system; for example you may have sensative information on there, which the systems administrator may not be authorised to read.</quote>
So THAT is why I had my ass handed to me after opening the file:
2016Q1 Executive Bonus.xls
you may have a system where root needs to administer the actual computer, but you wouldn't want the root user to have full control over the system; for example you may have sensative information on there, which the systems administrator may not be authorised to read.
Permissions cannot solve that, ever.
If a user has full control over the computer, then that user can always look at the content of any file they want - worst case, they can go look at the raw bytes on the disk.
The only way to secure data against unauthorised access is to encrypt it and keep the decryption key secret - and not on the computer.
That has no bearing on what "root" or "admin" privileges mean.
Having a permission system that tries to prevent the admin from accessing certain files is asinine, and only serves to create a false sense of security. If you can administer the system then you can access anything, if you restrict your level of access then you can't perform your task as admin and you're just a normal user with a limited ability to change specific settings.
Consider that the administrator needs to configure backups, how can the system be backed up if some files can't be read? And even if the running kernel won't let you read them, you can always read them from the backup storage.
Instead of adding extra pointless cruft, just accept that the system administrator has full access to the system, and behave accordingly. If you want data to be private from someone, then ensure it never exists in an unencrypted form on a machine accessible to anyone you don't trust.
"Instead of adding extra pointless cruft, just accept that the system administrator has full access to the system, and behave accordingly."
That is the old system, and falls on its face because even when normal non-admin users do things, many programs escalate priveleges to root level. It is by compromising these programs in various ways that many exploits have been implemented.
So, basically, the system doesn't differentiate between a bona-fide logged in admin doing things, and a SUID root (set user ID to root) program doing things. It's just the legacy of how things work.
"If you want data to be private from someone, then ensure it never exists in an unencrypted form on a machine accessible to anyone you don't trust."
Well, if a machine has been compromised there will be many ways of accessing this supposedly secure data when it is accessed in its unencrypted form (on that very PC). So this won't solve anything when it comes to system security. It will, perhaps, solve issues such as lost/stolen PCs, hard disks left at your local dump, etc. (I just take a sledge hammer to all disk that will be disposed.)
Oh, and the issue is not about physical access from people you don't trust. Many PCs (probably millions) are "owned" by bot-networks controlled by people thousands of miles away.
"Having a permission system that tries to prevent the admin from accessing certain files is asinine ..."
It would be interesting to have the opinion of someone in management at NSA (or GCHQ, CSEC, etc) about that.
As a database and system administrator I was aware, and somewhat concerned, although not overly so, about the databases on our Unix systems, all of which were set up with only standard discretionary access controls. The situation was better on the mainframes, where the mandatory access control system (RACF, ACF-2 or Top Secret) separated system, database, and security administration. Although a system administrator could bring up a system without the MAC, it would have been quite hard to do without being noticed and reported by one of the rather large number of people present and watching on those occasions.
It would be interesting to have the opinion of someone in management at NSA (or GCHQ, CSEC, etc) about that.
We have it. That's why the NSA set up TRUSIX in 1987. That's why they came out with SELinux in 2000. Those were products of NSA eras where the people in charge were a bit more concerned about promoting IT security (which is part of their remit) than undermining it - but that's rather the point.
The situation was better on the mainframes, where the mandatory access control system (RACF, ACF-2 or Top Secret) separated system, database, and security administration.
Yes. TCSEC levels B and A require MAC support, partly for this reason (though largely to support compartmentalized data storage). We've had various UNIXes and UNIX-alikes with optional MAC support over the years, as well as various mainframe and minicomputer OSes.
I suspect it's not preventing the actual physical user using root privileges conciously that has motivated the implementation of SIP.
The problem is that many processes run AS root just to do some everyday tasks. Privilege escalation is a necessary evil to get things done (and also, unfortunately, often done for no good reason other than laziness of the implementer).
Previously, when such a process was compromised and made to do the bidding of some Trojan, it could do anything. Now it can't.
If you really do require root access that includes modifying SIP protected areas, you can still get it, but 99.9% of users will never need this.
The question "Why did Apple feel that root, administrator of the system, needed to be locked out"? Has not been answered.
Three decades of UNIX security research begs to differ.
Look at research published by TRUSIX, Trusted Systems, many researchers in academia, etc, etc. Look at the rainbow books. Consider why no UNIX-like OS with conventional superuser ever achieved better than a B1 TCSEC rating.
> and Windows, starting as a single user system, has found it difficult to build security in
The current strain of Windows has nothing to do with the single-user 9x strain. Windows NT was a clean-room re-implementation of Windows, with security and authentication built in from the start in an *extensible* model that was prepared for future enhancements. Windows 2000, XP, Vista, 7, 8 and 10 are all based on the same security model.
And it solves all of your complains about Unix.
> First, instead of accessing storage on their own user processes should go through a back-end with specific permissions
Windows (and Linux/Unix) already goes through a back-end (known as syscalls) when accessing resources. This is an ideal place to enforce security restrictions. Linux allows LSMs to intercept syscalls and perform extra access checks. Windows tokens are far more advanced than the Unix model and has catered for this type of security access checks from the start.
However, only Unix/Linux came up with the stupid idea of creating a deliberate hole in the model when they chose to elevate a single user (uid 0) to "god", by creating bypass code in every syscall to just let root through. There is no similar hole in Windows: All users - including administrators - are just users and must pass through the same security checks. Admins are only admins because of the permissions *granted* to the accounts.
> Secondly, introduce a concept of application permissions that sits alongside user permissions
Windows AppContainers (not to be confused with docker containers) was introduced in Windows 8 - and leverages the same token based security that is in Windows since the first Windows/NT. When the token contains a special SID, the process is restricted *beyond* what the user can do, i.e. *both* the user *and* the application must have explicitly granted access to a resource for the process to be able to access it.
https://msdn.microsoft.com/en-us/library/windows/desktop/mt595898(v=vs.85).aspx
> Thirdly, and this is where something like Apple's idea comes in, the kernel would lock root out from changing such storage on its own account; it would need to be authorised by a specific user, such as odf-admin for instance, to de-allocate odf storage.
And that is where is Unix model fails. Big time. This is yet another SUID/setuid fiasco. A security model where you gain *extra* privileges from the process that you run is a deliberate (but *stupid*) security hole.
What you want is to get rid of the "god" account and use discretionary privileges instead. The user's permissions should be an *upper bound*. If he/she needs to perform an action that requires permissions he/she does not hold, he/she must interact with a service instead. The service can perform authorization checks, but under NO circumstance should the process run within the requesting user's context. This latter part is why vulnerabilities such as shellshoch were so devastating.
The problem with your "user space limited permissions", is that all that auth processing is slow and the action limits mean you have to interact with additional services all the time.
Then you end up with the font system embedded in the kernel because it's quicker...
Along with everything else becoming a "driver" instead (again, kernel level), but still using user space configuration files and inputs. Unlikely to be some magical programming involved that makes your drivers immune to bugs/exploits that allow direct kernel level access to stuff. Malware running in your graphic cards memory/processor anyone?
If you want *real* security, don't use a consumer OS (or probably even consumer hardware), build your own and curate the whole stack.
Some of the UNIX variants have RBAC bolted on top, so they can support a "least privilege" model for SUID processes and the like, but it's pretty much unsupported by almost any software outside a few vendor provided binaries. Building a complex web of trust around your application, updating all the RBAC role files during install (as root, naturally!), wrapping all privileged syscalls with RBAC stuff, no-one can be arsed to do it. And even if you did, the number of people that would actually know what you had done and appreciate it would be minimal.
>Windows tokens are far more advanced than the Unix model and has catered for this type of security access checks from the start.
Your opinion. Repeat after me, UNIX had Kerberos before Windows.
>However, only Unix/Linux came up with the stupid idea of creating a deliberate hole in the model when they chose to elevate a single user (uid 0) to "god", by creating bypass code in every syscall to just let root through.
Ok, who is NT Authority\System on Windows, then ? STFU!
>> Thirdly, and this is where something like Apple's idea comes in, the kernel would lock root out from changing such storage on its own account; it would need to be authorised by a specific user, such as odf-admin for instance, to de-allocate odf storage.
>And that is where is Unix model fails. Big time. This is yet another SUID/setuid fiasco. A security model where you gain *extra* privileges from the process that you run is a deliberate (but *stupid*) security hole.
It is an option, however, I guess that as long as the program in question is safe to run ...
use their Macbooks/iMacs to read tweets?
Don't they all have iPhones and iPads for that purpose?
Now if this infected those iDevices then it would be real news but I seem to recall that Apple fixed that hole.
At least Apple are trying to keep the bad guys out. Some other systems are so wide open that they don't even rate investigation these days.
how many people use their Macbooks/iMacs to read tweets?
Ah, you've fallen for the deliberately misleading aspect of the article title, hoping to pick up everyone who has a problem with comprehensive reading.
The SIZE of the proof of concept fits in a tweet, but nobody has as yet found a way to tweet root level commands straight into the shell.
"And very few programs – the software update tool being one of them – are given this special com.apple.rootless permission"
The explanation of what is going on here, and this sentence in particular, means there is no way I will now buy a Mac. What are the other programs? Will the update tool at some point do a Windows and run without asking?
Basically an external program can bork my system and I do not have the permissions to get in and fix it. Fsck that for a game of soldiers. (Cue Mac user downvotes...)
Yep, Apple need to get off their high-horse. All they've effectively done is create a super-super user. It doesn't make root problems magically go away, it just moves the target.
Meanwhile, slightly offtopic, but try checking the details of an HTTPS certificate in mobile Safari... and you can't.
"All they've effectively done is create a super-super user."
In effect, they are trying to create an Enterprise-like structure, but for private end user machines, and making Apple the system administrator. That architecture is fine for businesses who own the machines, but private end users can't phone Apple (or get their bosses to do it) and raise Hell till an issue gets fixed.
I don't, however, expect Apple to change their entire business model just to suit people like me who are old fashioned and expect to be able to manage their own kernels. So long as I can buy a computer on which I can install a reasonable OS which is under my control, and a car which can't be updated OTA with new firmware, the rest of the world can do as it likes.
That's my problem with this. The rational part of me accepts that in our modern, connected world where our computers contain so much financial and personal information, there's a need for security.
Yet the anti-authoritarian side of me bridles at the idea that "my" computer isn't going to be under "my" control. If I want to delete every single darn file in the root filesystem, or edit every PLIST, I should be able to. Screwing up the system so it doesn't work is a risk I can accept. But being baldly told "computer says no" (or, more accurately, "Cupertino/Redmond says no") just infuriates me. UAC, TrustedInstaller and all similar mechanisms just make me see red.
Security researchers read of exploit mechanisms like the one in this article and see a vulnerability. I read the same thing, and see a chance of freedom.
Unfortunately, I'll admit, I am in the minority view on this and I don't think it's a solvable problem. How do you differentiate between "infurated geek wants total control over the filesystem because it's his computer, dammit" and "clueless user wants total control over the filesystem because he wants to run Nude-Karsashian-Pics-Not-A-Virus-Honest.JPG.EXE"? You can't, and so security has to win versus control.
Further thoughts to my comment above - because I have a keyboard, this is a forum, and I Will Speek My Branez...
1) Apple/Google/Microsoft: "There's too many rootkits and viruses out there. We're reducing the power of the root/administrator account and locking down areas of the system to ensure its integrity."
2) Me: "But that makes you the ultimate arbiters of control over "my" computer. I don't trust you, partly because your recent actions have shown that you care more about collecting telemetry or monetizing everything I do, rather than giving me the best possible computing experience. You remove my software without my permission. You foist unremoveable crap on me that I don't want, and never will want."
3) A/G/M: "You might be tricked or misled into installing malware. If it inherits your permissions, and you have total control, your system is toast. You don't want to be a victim of ransomware or identity theft, do you? Best to let us be the super-root. It's for your own good."
..repeat items 2 & 3 ad nauseam.
It's a circular argument (OK, with a soupçon of Straw Man), but I think both A/G/M and I have valid arguments. What's the solution?
There is no solution. You're up against a "dual-use" problem: something that can inseparably be used for good and ill. It a lot like owning a gun. Sure, it can be used as a last resort to defend your life, but as long as you own it, it can be turned against you as well (stolen, used by an angry spouse, etc.). Same with cars. And since the computer has no way to separate the audacious from the stupid, just like the gun can't tell between a defensive use and a malicious use (and the car), we're kinda stuck with it. To get things done, we HAVE to run the risk of being pwned. Problem being, some people are too stupid to be able to make this kind of judgment BUT must be able to use the computer to run their daily lives.
In the end, it can boil down to one of those "Book of Questions" problems where there's no real answer.
Look, you don't know what's going on, and that's fine.
It also means that SIP is nothing that will ever affect you in any way, apart from making your system a bit more secure. If you are the kind of person who usually prefers Macs, SIP makes perfect sense. Don't believe the hysterical hype from well documented Apple hating authors.
What do you trust when you do not trust your own roots?
A tree graph that sheds more and more power further from its root is a human-understandable model. Are there any others?
Will humans ever stop running stupid stuff in God-mode unnecessarily just because it was simpler than sorting perms?
To be fair, there is a requirement to be able to separate out different administration functions to non-root accounts on multi-user UNIX-like systems.
The thing is, this is a problem that was solved to some extent years ago via the normal permissions model and using groups and group administrators, and just fell into disuse.
The reason why most UNIX systems have groups like system, adm, daemon, uucp, lp etc, was so that you could use the group permissions on the programs to control the different aspects of a UNIX system, and then add the group to a person's group membership (or on really ancient UNIXes, use newgrp to change your current group) to allow you to run the necessary commands. You then restrict root access so only your most trusted users could use it, and have them use it very sparingly.
You didn't even need to be root to control the group membership. There is (was) the capability to set a password on a group, and the first member of the group would be a group administrator who could control other members of the group! You add and remove groups from someones group set to control what they can do. Even now, some of the things still persist. For example, on AIX, I believe that it is still the case that being a member of the system group allows you to do things like mount and unmount filesystems.
It's lazy UNIX administrators who got used to using root for administering everything that caused this facility to fall into disuse.
I'm not sure whether modern UNIX and UNIX-like systems still have the code to allow this to work, but the vestigial remains are still there, without most people understanding why.
It was not as flexible or as granular as the RBAC and ACL based systems used in OSX (and to some extent in the other remaining modern UNIX systems - although the ACL systems need to work better with RBAC), and the underlying mechanisms still relied on there being a 'superuser' UID, and suid, euid and sgid, but it was the case that you could administer a system day-to-day without needing to run commands as root.
You don't have to be particularly lazy to get fed up when nothing works and change permissions so that damn broken service can start working again.
To be honest it's more often a case of poor/no documentation and unfixed bugs that have caused proper use of group permissions to be a bit neglected. Although it is still very much in use.
If admins need to change permissions on files to make the services work, then they've probably already done something wrong because they've not understood how it hangs together.
The UNIX permission model has it's quirks, but it is relatively simple (actually one of UNIX's weaknesses). If admins can't understand it, they haven't a hope in hell of understanding RBAC and ACLs!
And I'm not talking about what people generally use groups for nowadays, but another level entirely (if you've got a Linux system, read the gpasswd manual page for example).
I'm thinking more in terms where the admin is also the user of his/her private machine.
I really don't think my Linux box is hardened enough as it is to make it worth spending the time to obsess about every single group access priv. Sometimes it seems someone hasn't implemented things correctly, and I can't correct it in the perfect way within a time scale that's reasonable, given my limited expected lifetime.
Yes, I'm a bad person for this.
I'm sure I'm not alone, which is why things have to 1) Work when properly secured, and 2) Not allow the user/admin to cock up too much when fatigue/desperation sets in.
I think the idea behind SIP is to avoid simple permission escalation attacks from users who also have admin roles (ie. can sudo). As such it's a nice idea as it makes "click this" exploits a little harder without taunting the user with permission requests à la Windows Vista.
However, Apple also privileges certain applications such as the software updater so that can run while the user is logged in. As opposed to forcing the machine to restart in single user mode and install whichever signed packaged have been downloaded. I wonder if this is what Windows does with some of the system updates?
It might be possible to keep SIP around if it is simplified and there are fewer exceptions. Personally, I disabled it because I wanted to downgrade ITunes. And this is an example for one of its flaws – they're trying to protect too much shit. Given how fast MacOS boots with an SSD then they might want to consider forcing more stuff to be done from a restart rather than trying to play security and convenience off each other.
Users who machines are theirs, i.e.not company machines, have sudo so they can install applications and apply system updates. Those updates come from the repositories (in Linux) and the "Store" with Mac, Android and now Windows. The basic rule of thumb given to new Linux users is this; "Unless you are installing software, and YOU specifically went to the software manager/store to do it, when something asks you for your password be very aware, even suspicious, of why you're being asked for that information".
So far no-one has messed up their machine. Can it happen? Yes. Will it happen? Perhaps. The onus is on them.
"be very aware, even suspicious, of why you're being asked for that information"
Trouble is, many computer users can't even understand THAT yet depend on turnkey and foolproof simplicity, full stop. They want unicorns and complain to high heaven if you don't deliver. Oh, and they have friends, so telling them to get lost will have knock-on effects. How do you deal with people like that, especially when they seek you out directly so go to great pains to get around your attempts to get around them?
"Given how fast MacOS boots with an SSD then they might want to consider forcing more stuff to be done from a restart rather than trying to play security and convenience off each other."
You gotta be freakin kiddin me!
And how would things get more secure because the machine reboots before implementing the end-user's mistakes?
Looks like the Microsoft reboot-always mentality has gotten to your brains somehow.
And how would things get more secure because the machine reboots before implementing the end-user's mistakes?
You seem to fail to understand the point: let a user process download signed stuff from Apple. Everything that is downloaded should be safe. But the installer cannot be hijacked or abused to do anything else because it can never be run by the user process.
He's a nice badge for you.
I disabled it because I wanted to downgrade ITunes. And this is an example for one of its flaws – they're trying to protect too much shit. ...
It wouldn't surprise me at all to discover that Apple's real agenda here is to create a protected enclave for DRM tools that even root can't violate. It comes as no surprise that iTunes is one of the things you can't manipulate with SIP running.
Actually you're back to the OpenVMS (Open is silent, remember) security architecture, which started life on VAX, upgraded transparently to Alpha, then was downgraded to IA64, and is soon to arrive on x86-64.
KESU, fine grained permissive and restrive ACLs, finer grained permissions than root/notroot, etc.
What's not to like, other than a couple of decades of vendor neglect, hopefully to be fixed in due course (not necessarily overnight).
VMS is under new management and has many of the old engineering and support team working on it.
http://www.vmssoftware.com/
Windows has all of this. Hell, the user with total access is even named the same (SYSTEM).
Look how well that worked out...
It's very hard to give _some_ administrative privileges without allowing any routes of escalation from there.
Besides, does malware really need admin nowadays? Look at all the ransomware etc. - they tend to hose you perfectly fine without even bothering to attempt escalating.
"Windows has all of this" (inherited from VMS).
[panto] Oh no it doesn't.[/panto]
WNT is not VMS++. VMS still does much the same as it always has done, plus a whole lot more. It has done it largely compatibly across three (soon to be 4) different processor architectures. Windows struggles to remain compatible with itself for longer than the blink of an eye, let alone four decades, and has never managed to really escape the world of x86. Obviously VMS has not been fashionable for decades, and it has been neglected by a succession of owners.
But you've made your mind up on this, it's not pining, it's gone to meet its maker, so let's move on.
"Look at all the ransomware etc. - they tend to hose you perfectly fine without even bothering to attempt escalating."
Indeed.
As others have suggested, this is likely about DRM. Or maybe about the avoidance of another Snowden (which is kinda the same scenario, really - the admins need to be able to safely back up or transport the files, without being able to access the contents).
What does the &- do with the redirect?
...which creates a symbolic link to AppleKextExcludeList.kext's Info.plist from /dev/diskX, and then gets fsck_cs to work on /dev/diskX and pipe stdout to that linked Info.plist file, thus trashing it with garbage
I'm not sure this is correct, surely the ln symlinks the /dev/diskXX file to the file to destroy, which fsck then treats as a block device and writes to, trashing the file. But I don't understand the redirect, and my google fu has let me down. :(
Yes, there is no pipe.
1&>- causes FD 1 (stdout) to be closed, but not to save the user from noise, this is setuid hacking 101. With FD 1 closed, the next call to fopen() will reuse the now freed up FD 1, so output intended for the user will instead end up in the opened file (disk device), effectively junking it. See pages 53-57 of Esser's paper linked from the article.
(The "[n]>&word" form is for duplicating FDs, with "-" as special case for closing the FD.)
That would be Microsoft, progressively breaking NT since NT4.0 stupidly put graphics and printer drivers in Kernel to get 10% more performance in a era when performance WAS doubling annually.
They then added al the worst features of Win98 and Win ME.
(Win2K & XP Era)
Then they fell off a cliff after Server 2003 and produced NT5.x series (Vista and then you have to pay for it "service pack fix" called Windows 7.). After the slight upward blip of Win7 they studied how office users hated Ribbon and put Zune GUI as Win 8.x
Then decided to out do Google & Facebook at creepymess to produce pointless Win 10 (for free to newer users), when what people really want is NT3.5 + Explorer and drivers for all new hardware (Basically a new improved XP). People DON'T want a 15" to 22" Windows Phone. Actually hardly anyone wants one. It's getting as popular as MS Watch, Zune/Plays for Sure and Kin.
At least Apple tries to do something, and takes security seriously.
If it was easy, it would have been solved already by all OS vendors.
Retrofitting better security into an already existing system also presents its own challenges.
It's always a balance between security and practicality.
If you allow the user and program to do nothing at all, you have a perfectly secure system -just not very practical.
It looks like Apple has some work to do yet to make it work as intended, so there will be a lot of fodder for Reg articles as new exploits are found, as well as hand-wringing over how insecure Apple's operating systems are by those who use vulnerability counts as a measure of code quality (just to point out: a root only OS with no authentication or encryption would never require security patches because anything that happens is "by design"...)
Since the basic design of Unix/Linux includes only two privilege levels, there are a limited number of possible ways to try to secure it. We've tried allowing unprivileged users temporary privileges (i.e. setuid, and Linux capabilities, which are basically finer grained setuid bits) So maybe trying to limit what privileged users can do is worth a shot. At least this starts from a position of unlimited privilege, so when bugs are found it isn't nearly so serious as finding bugs in setuid programs.
The ideal would be to create more privilege levels, but what you'd end up with would no longer be Unix by any meaningful definition.
help me corporate mommy dearest, as i cling to your skirt
i don't know what i'm doing, but don't let me get hurt
allow me to be an airhead, just keep the GUI cute
give me a slice of apple pie cos i'm too stupid for root
crippleware pc at 10x the normal cost, i don't give a hoot
i want the whole wide world to know that i'm too stupid for root
Well, most users are waaaay to "stupid" for root. "Ignorant" is a better word.
Doesn't mean they should be totally unable to get root, just that when they click that email attachment and say yes to installing that nicely named Trojan, perhaps it would be best if the system wasn't "owned"?
For some reason the article and associated comments reminded me of the 1950s Arthur C. Clarke story where a computer was enlisted to generate all the possible names of God. After which, the universe had served its purpose and peacefully self-destructed.
I expect a similar thing would happen if the day ever comes when EVERY vulnerability in any OS is named and corrected. (or if there is ever a day in my city when all the road construction is completed)
What's your definition of "OS"? The L4 microkernel running Apple's secure enclave may or may not be bug free, but I'm sure it is close, simply because it is so tiny.
If you use a true microkernel at the heart of your OS, and then have a bunch of other layers around it for stuff like networking, disk I/O and so forth that have bugs, do those count as OS bugs? You can't have a useful modern system without networking and I/O, after all. What about stuff like sshd and Firefox that are only needed if someone logs in to it, but are superfluous in an embedded device?
The trouble with microkernels is that everything has to go through it as the gatekeeper. Which breaks things like Direct Memory Access (seL4 is only verified secure when DMA is OFF), which is kind of important for high-performance tasks like graphics and low-latency networking. Which is why in the real world these kinds of drivers have to work close to the metal as a matter of necessity or they get choked. Which then brings up the dilemma of requiring a system that's BOTH high-security AND high-performance at the same time. Based on the current discussion where security and ease of use are on opposite ends of a sliding scale, it seems the only way to achieve the happy medium is with overkill specs.
Considering all the latest f*ups Apple has made in iOS and OSX, probably due to high pressure on releasing stuff or just incompetent engineers - it seems to me it will only get worse.
Also we must consider that for every bug discovered there must be at least one still hiding somewhere.
This can only mean one thing to me: Apple should SLOW DOWN in releasing UNTESTED stuff like its f*ing Android and take the time and resources to safe-guard and make stable-in-operation what they currently sell to their customers.
If Apple fucks up security and stability then its "beautiful" products will NOT be worth the money.
An Apple user.
You are overreacting.
Also you are stating obvious truths such as the fact that there are unknown bugs. Well, what a piece of news that is! There is no way to prove that software is free of bugs. This has nothing to do with Apple in particular.
In this case Apples additional security was circumvented after gaining root privileges. So no less secure than the system was before the addition of SIP.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
