SIP workaround?

[AVmcclint]

I've been trying to consume as much info about SIP as I can so I can understand how it is going to affect my users and the apps they use. Correct me if I'm wrong, but if you have an app that installs into one of the protected areas (such as /sbin), you can disable SIP, install the app, then enable SIP and the installed files will remain where they were put? (and this process would not at all be scriptable or pushable via Casper) Obviously if an app tries to write to files in the protected locations as a matter of it's normal operation after SIP is enabled, then the app is probably going to fail.
- Also, if we wish to disable SIP 100% of the time, the SIP status is actually written to NVRAM and if the battery dies or we have to zap the PRAM to fix an issue, then the SIP status will return to a default of Enabled. Right?
I'm thinking of possible workarounds if some older mission critical apps we use aren't updated to work with SIP before the first OSX 10.11-only Macs ship. I do understand that there's a lot more to SIP than just protected locations and there may not be any workarounds for those aspects of it.

That raises another question: Has anyone bought any brand new Macs that can't be downgraded to Yosemite yet?

[rtrouton]

Mind if I take these apart a bit?

if you have an app that installs into one of the protected areas (such as /sbin), you can disable SIP, install the app, then enable SIP and the installed files will remain where they were put?

Correct, SIP doesn't move files. That move mechanism is part of the OS X Installer process.

Also, if we wish to disable SIP 100% of the time, the SIP status is actually written to NVRAM and if the battery dies or we have to zap the PRAM to fix an issue, then the SIP status will return to a default of Enabled. Right?

Correct, see here: https://derflounder.wordpress.com/2015/09/21/system-integrity-protection-and-resetting-nvram/

Has anyone bought any brand new Macs that can't be downgraded to Yosemite yet?

Everything shipping as of 10-7-2015 can run OS X 10.10.5.

[AVmcclint]

Thanks for confirming my thoughts. I hate being wedged into that no-man's-land that falls between the day a major OS release and the day you can't downgrade brand new Macs.

[mm2270]

I've heard rumors Apple will be releasing a new iMac soon with at least some new hardware internals. Its just that, a rumor, but if true, it will likely be the first Mac to require 10.11. If its not the iMac, it will be another one soon enough.

As for installing to SIP protected locations, yes, as Rich already mentioned, we can temporarily bypass it to get outdated products installed.
There are several issues I see with doing this though.

1. No-one really knows what Apple will be doing down the line. Will that practice continue of leaving these foreign binaries in place in SIP protected locations? Maybe and probably, but Apple could also start shipping 10.11.x updates that remove anything that shouldn't be there. We just don't know, so there's a semi risk there if you ask me.

2. It could be done as a temporary workaround, but I would be heavily pressuring any vendors still putting stuff into these directories to get their act together and update their stuff accordingly. Its not like no-one was aware this change was coming unless they were living under a rock, so, no excuses long term for not rebuilding these. Plus, who wants to have to go through such a hassle to get these things installed?

3. The other issue with this is one of motivation. If we collectively continue to work around vendors' outdated products, some of them will have no incentive to rework their software. Most developers are doing the right thing, but some are going to be lazy. Let's not reward lazy developers by continuing to use their stuff and working around their laziness.

Lastly, I'm not sure why you would consider permanently disabling SIP. Hopefully that was just a fact gathering question and not something you're actually considering doing. Doing it briefly as a temp workaround is fine, but permanently seems a bit crazy to me.

[gachowski]

Mike with the quote of the year !!!!

The other issue with this is one of motivation. If we collectively continue to work around vendors' outdated products, some of them will have no incentive to rework their software. Most developers are doing the right thing, but some are going to be lazy. Let's not reward lazy developers by continuing to use their stuff and working around their laziness.

it's not just vendors... it's also managers/bosses/users/coworkers ... we have to stop setting expectations that we can do things that Apple doesn't want/care/help us do...

[AVmcclint]

I whole-heartedly agree with the comments here. This was more of a fact-finding query than anything else. I have to know what my options are if my superiors push on the issues. I know the pressure really needs to be on the vendors, but the sad news is that many fine pieces of software have been long ago abandoned for various reasons with either poor replacements or no replacements available at all. - There are always pains with major OS upgrades, but I'm counting SIP to be on the same scale of impact as dropping Classic Environment, switching to intel hardware, and to a lesser degree 64-bit computing. I know there is benefit to moving in this direction, but damn it hurts a lot when the window of transition for the users and sysadmins is very short (the aforementioned no-man's-land).

[AVmcclint]

I've been a Mac user for a very long time and the only thing that I truly hate with every fiber of my being about being a Mac user is the forced upgrades when new hardware is purchased. As stupid as it may be, it is still entirely possible to buy a brand new PC today and install XP on it for business purposes. We Mac users have never had that option available to us. This is one reason why many enterprise IT managers (and small business owners) consider Macs to be unsuitable for business.

This is something I've heard on more than one occasion: "I've got a 5 year old program that runs perfectly fine and does 100% of the tasks we need it to do. There has never been a need to update it - it simply works. The computer it is installed on has died and can't be repaired. The computer I now have to buy to replace it will not allow that program to run. I've searched the computing world for a replacement or updated version or a hack to make it work and it just doesn't exist. I've even reached out to the original programers who created it and they wish me luck in my search." PC-based businesses almost NEVER say those words.

OK i'm done ranting. Back to drinking the kool-aid. :)

[MrP]

@mm2270

Lastly, I'm not sure why you would consider permanently disabling SIP. Hopefully that was just a fact gathering question and not something you're actually considering doing. Doing it briefly as a temp workaround is fine, but permanently seems a bit crazy to me.

Organizations with heavy hardening requirements have to modify or remove files/folders in locations protected by SIP. In order to maintain hardening across OS patches, organizations either have to disable SIP permanently or manually visit each mac to patch. Yes, I'm aware of the irony. No, the awareness of such doesn't remove the need for hardening beyond what SIP provides.

I just hope I can modify the installer to prevent the enabling of SIP to begin with or all of our systems will have to be upgraded manually by admins to prevent un-hardened systems from floating around. :-(

[gachowski]

Paul,

I am way out on a limb and I am in no way trying to get you to change what you have to to do... However that is exactly what the problem is ....

I am interpreting what you are saying is that that "Organization with heavy hardening requirements" are better at securing the Mac OS than Apple. I think when you say it like that it super crazy... I am not saying Apple is right all the time, but they are better than most orgs.

C

PS For you sports fans.. it's skating to were the puck was in 1902 not were it is today or tomorrow...

[calumhunter]

I am interpreting what you are saying is that that "Organization with heavy hardening requirements" are better at securing the Mac OS than Apple. I think when you say it like that it super crazy...

I think you would be surprised, Apple has a pretty sketchy record of keeping their OS secure.

Apple is about the every day consumer. They don't care about security in the same way that defence or other govt orgs might. So they ship their OS with secure-enough-settings for Joe Blow.

[gachowski]

Calum,

I kinda agree but I think that is still old school thinking SIP is some serious serious improvements. I am willing to bet that most admin don't understand the improvements. (if they did people wouldn't be asking to disable it) and if the admins don't understand then there is no way a manager is going to...

This is just like running AV.. most of us "have to run AV" because it's on somebody check list from 1902... when the built in Apple AV is going to be as good as anything you can buy

You get in the weeds very quick when you start comparing AV vs AV and them most managers stop listening...

My example is....
Last time I checked SEP checked for 70 defs and Apple had 40 on their list... but dig deeper and it look liked some of the 70 in SEP were for OS 9... and wait Apple can patched things and not tell anyone so Apple may have patched issues that SEP still has defs for...

C

[calumhunter]

If you're in a conversation with a 'manager' about AV product vs AV product, then you're not going to get anywhere.
You need to learn to communicate in a language they understand, which is not tech speak...

In any case I was talking about what @Dickson mentioned about having to disable SIP in order to apply hardening techniques to OS X.

In this case, yes, we often DO know better than Apple when it comes to hardening their OS. Like I said Apple release their OS for Average Joe Blow, they make compromises for ease of use and functionality. These may conflict with a org's security requirements for example.

Perhaps having an outdated version of a binary shipping with OS X is a security risk to some orgs (Umm bash anyone?) or even just having that binary at all on the system is an issue. With SIP enabled, performing hardening by removing or replacing these binaries is not possible, which prevents an administrator from applying hardening techniques.. Ironic right?

[laxthxdude]

The simple fact is SIP is good thing. Those non compliant to it (SIP) have had YEARS to see the writing on the wall and fix their stuff. If they are ignoring and didn't do so, there no excuse and it is 100% on them.

SIP is a very good thing and there is zero reason to disable it. The simple fact is Apple's responsibility to patch and update older versions of the OS are simply not sustainable or feasible. All things are connected today and every single vulnerability becomes an issue for everyone. For Apple to update and patch things outside of the latest version is nice-to-have but simply isn't going to happen and isn't sustainable. If you want evidence of this approach, simply look at Android. The only branch getting updates in a decent amount of time is Android's own Nexus branch and even now they are starting to lag by weeks past their own goals for their own devices as their Nexus device count grows with models. In short, it is not feasible for Apple to provide patches to old versions of the OS. The only solution is to keep update-to-date and keep pace with them. If you're wanting to use outdated OS versions known to be vulnerable, you are on your own and accept the risk of doing so. However I don't know of any board or upper management who is going to be pleased if you are compromised because a machine which was running an outdated and known vulnerable version of the OS (or default security like SIP is disabled deliberately) which gets compromised and ends up as the jump point to breach the entire network and systems of their company. Apple uses the OS X updates to patch a massive number of security vulnerabilities and the only way to get these patches is to update the OS to the latest version. We may not like it, but it is the simple way of world if you choose to run Macs.

If you have a requirement where you think you need to disable SIP, obviously red flag the vendor who isn't fixing their stuff. If this machine is on the internet, I suggest you isolate off the network and on its own as not to place the rest of your stuff at risk.

I also think stating that "Apple has a sketchy record of keeping their OS secure" and "Apple is about the every day consumer. They don't care about security in the same way that defence or other govt orgs might. So they ship their OS with secure-enough-settings for Joe Blow." is very native. But if you feel this way, then perhaps you'd be better of in the world of Windows or Linux.

The bottom line on SIP:
- It is a good thing (and there is no conspiracy here on why Apple included it other than it is a very good next step to securing the OS)
- If you have things that broke with SIP enabled, you are running vulnerable software and it is 100% the responsibility of the vendor to fix their software. If they refuse, then you already know the answer (and it isn't disabling SIP).

And just a reminder: Apple did $25 billion in Enterprise sales last year so I would argue that claiming they only care about Joe-Blow is a bit off base...

[MrP]

I'm weary of anyone who declares absolutes in any scenario or rule. The precursor to these claims usually is something like "I can't think of why anyone would want/need..". The words never, always, phrase 'can't think of', etc show a lack of imagination more than anything.

@calumhunter , Precisely. Apple favors usability over security, and I think that is a good thing 99.999% of the time. Why would they design their OS with 007's requirements in mind? Leave that to Q. There is the 1/1000th of us that have stringent requirements to prevent data leakage. SIP keeps the system files secure. It does nothing to prevent end users from leaking data by using tools built into the OS and forcibly kept there by SIP.

[calumhunter]

exactly my point @Dickson glad someone actually understood what I was saying.

no point in rebutting your post Corey.

[barnesaw]

@Dickson - Exactly. Apple STILL hasn't patched some of their root-escalation holes, despite patches being provided by others. They "fixed" the hole by de-rooting root, not fixing the core issue, which says that Apple is NOT all that good at actually hardening their OS. They're good at MARKETING their security, not actually providing it.

[bollman]

@barnesaw WORD!
I feel SIP is yet another excuse for Apple not to provide timely fixes to security holes.
And, when it comes to running "old" OSes: No one in the entire computer business is stupid enough to release major new versions every year. Apple do not have the time to fix problems when the deadline for next major version is one year.
One of the funniest examples (actually, it's more tragic than funny) is that there were massive problems in the Lion AD-plugin. Apples answer to bug reports: it's fixed in 10.8. What they forgot to mention: a lot of computers could not run 10.8!

[brandonpeek]

So recent testing of our additional security hardening policies led me here. I get the comments on vendors needing to get with the times and have their apps work with SIP. What gets me is that the vendor in my particular scenario is Apple itself.

My team supports a group of Mac users performing client-facing work and the clients have specific additional security hardening they want applied above our basic standard. One example is disabling iSight. The path where iSight resides is protected by SIP, so is there any but practice for still being able to disable iSight with SIP In place? I hesitate to disabled it and apply controls and prefer SIP to stay with its default configuration.

I've seen a few other hardening policies we have failing on 10.11 that work in 10.10 so I'm suspecting SIP is the issues there, as well. Again, I'm not real interested in disabling SIP, but in the end we've got client security concerns to address where me telling them "SIP replaces security for the security controls it breaks" won't fly.

[sean]

I'd actually say, that SIP is going to pressure Apple to provide more timely updates. How many people out there used the alternative 'bash bug' fix, before Apple released one? SIP wouldn't allow this. They are taking away the ability to easily self patch and in doing so they've made themselves the target for patching vulnerabilities.

In general I see SIP as a good step forward, but the above caveat will more strongly rely on Apple. It's now up to them. Didn't OSX have more zero days this year than the others? SIP is a sign that they had to listen to bad press, and yes they are better at the marketing side, but they won't want someone pointing out that SIP itself is a security issue since it will prevent patching flaws. Time will show.

@brandonpeek
As for managing cameras, can't you just use a Configuration Policy?

[chris_kemp]

@sean How would that work? The only way to disable the camera, as far as I know, is to restrict the driver files themselves. I'm not aware of any config profile option to do so, nor any MCX control that could be used to create one.

There is an allowCamera restriction in the Config Profile Reference, but it is not supported in OS X - iOS only.