Untouchable Core Services Directory in ElCapitan?

[AdamH]

I normally modify a few things in the Core Services directory when prepping a new build config, such as persistent apps and Captive Network Assistant...
Looks like in 10.11 that directory is completely off-limits. I can't even make changes manually while logged in as ROOT.

Any ideas how to navigate around this issue?

[SGill]

An option to turn off System Integrity Protection or "rootless" mode should be available soon with Cmd-R startups…not seeing anything yet though…would love to know more if you find it:

http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really

[SGill]

This just in:

http://www.macworld.com/article/2986118/security/how-to-modify-system-integrity-protection-in-el-capitan.html

[milesleacy]

I would advise against disabling or modifying System Integrity Protection (SIP) in the strongest terms.

When a client in my org is compromised and the postmortem shows that the attack was possible because I turned off a core Apple security feature, well... I would expect to get fired and possibly sued or prosecuted depending on the nature of the breach.

[SGill]

Of course it's a good idea to leave it and all security enhancements on…but in the end the result has to be a workable solution for mass managers.

The same things got said about enable/disable of Gatekeeper, until people realized that a lot of 3rd-party vendors weren't going to go to the trouble of obtaining certs approved by Apple.

Luckily Apple OSX is a very secure OS any way you cut it….

[gachowski]

Sean,

I kinda disagree, the "but in the end the result has to be a workable solution for mass managers."

I think we should be follow Apple rules/guidelines. If we continue to "create" workable solutions that are out side of Apple rules, we are enabling Apple not to meet our needs.

Using your Gatekeeper example, I think we are part of the issue why "3rd-party vendors weren't going to go to the trouble of obtaining certs approved by Apple." We as a group should have blocked all non signed apps and then have our users push the 3rd-party vendors to sign their Apps.

When you think about it, it's really crazy that anybody would want unsigned apps on their computer.

C

PS I am kinda upset that there is away to disable SIP :) If you understand the details what it's doing, the thought of turning it off is really really crazy.

[SGill]

Good points…would love to see that there is a way around these concerns for users that are in charge of more than just a few computers.

Of course the changes are for the better if there are methods offered to go forward with them.

[milesleacy]

The "workable solution" must be provided by the 3rd party vendors.

If we allow 3rd parties to still take our money while not following Apple's rules, therefore making more and sometimes impossible work for us, then we've created our own problem.

If product X is incompatible with OS X in it's Apple-recommended configuration, then the vendor needs to provide an update that is compatible. If the vendor fails to do so, that vendor needs to be replaced.

If you keep giving a vendor money in exchange for a shoddy product, they've got no incentive to improve the product.

[ernstcs]

I'm sure keeping it protected is the right thing to do, but how ever will I load libdvdcss.2.dylib? ;)

[SGill]

But that is often the problem....many vendors aren't replaceable easily, and just because a vendor should doesn't mean a vendor will... :)

[milesleacy]

In the cost/benefit analysis, which is better... replacing an app/vendor or reengineering OS X and taking full responsibility for your unauthorized modifications?

[RobertHammen]

If you're turning off Gatekeeper in 2012, that's one thing, but if you're turning it off in 2015, you're Doing It Wrong™.

Same story with SIP. Don't turn it off, pressure vendors with incompatible/unsigned KEXTs/drivers and software that wants to put itself in /System or /bin or /sbin to fix their stuff. This is a big step to increase the security of OS X and at some point the ability to disable SIP will probably go away (maybe by the time 10.12 is out).

[frank]

I agree with @milesleacy and @RobertHammen on this. Apple has designed these security features for a reason and while change isn't always easy, we all work in a industry where it's expected month to month year to year.

The principle you should all take is "guide don't manage" when it comes to looking after your users or implementing solutions supporting the Apple platform. Everything else is determined by Apple and 3rd party vendors who develop for the platform, we are only here to make the process easier for the end user where possible :)

[cwaldrip]

I'm also with @milesleacy and @RobertHammen. Developers should keep up to date on these security features and adopt them in the best interest of their customers and their reputation ("Look at us! We're current!"). If we have to hack things to work, that's more work for (all of) us, and the developers are less likely to fix things.

One of the first internal app installers we tested was putting a launch daemon plist in /System/Library/LaunchDaemons. I had to explain to the developers that since we're not Apple, we should probably be using /Library/LaunchDaemons/ since that's for third parties. Of course they just released a new web app that relies on Chrome and Silverlight (i.e. oil + vinegar). They're telling people not to update Chrome. D'oh! >.<

App security certificates come with the annual developer program subscription ($99/yr) and the certs are good for all their apps. I can understand if a dev making an open source port of something doesn't want to drop a c-note for it. But if their stuff is important enough to enough people maybe he can solicit some funds for that? That solves Gatekeeper.

Kernel extensions (kext) have to be signed for 10.11, but anyone writing a kext should probably already have an Apple developer account.

As for dylibs - well, 3rd party dylibs aren't required to be stored in /usr/lib. Apps are going to need to be re-written to look elsewhere (probably /usr/local/lib/). And on the horizon they'll be replaced by tbd files from what I understand (i'm not a programmer though).

Of course this sucks if you're using some legacy application. Maybe the developer gave up and packed it in to go to high school. Maybe the developer just doesn't give a damn. Or Maybe the contractor hired by your company did his job, got paid, and wants more cash to update the app. In all three cases you should probably be looking at an alternative. In the last case you should probably also be telling management the dev has your sensitive bits in a vice so either pay up or walk away.

[SGill]

No worries...I like everyone else here have full centralized control of Gatekeeper and its settings. I was only speaking of realities, not would-be-great-ifs regarding the third party software world. Sure, older unsupported software should be kicked out as soon as possible. And default security settings should always be preserved.

Not trying to argue against any positive security measure Apple might implement...just talking about things we see out in the field all the time with OS X in real-world use.

[pblake]

As an admin, what is the harm in turning off SIP making a few controlled changes, like deleting the persistent apps in the Dock and then turning SIP back on? If Apple has a way to disable it, then they built that in to be used in a controlled circumstance. I completely agree with everyone that it should be on and used, but I don't see the harm in temporally disabling in it to edit your base config, if you know what you're doing.

[cwaldrip]

I think when you re-enable SIP it will remove files that don't belong. I haven't tested this, but that's the behavior if you upgrade to 10.11 with files in the wrong places - they get removed.

[rtrouton]

SIP will not remove files. The move process is part of the OS X installation process, so non-System items will be moved out of SIP-protected areas when you upgrade to El Capitan. Once the upgrade process is complete, anything added afterwards will not be moved.*

*Until the next time Apple decides to move stuff out of SIP-protected areas.

[mm2270]

*Until the next time Apple decides to move stuff out of SIP-protected areas.

Love the asterisk on the above, because ain't that the truth. We don't know (yet) if a 10.11.1 for example will remove those files again. Certainly a possibility, so I would either just forget about doing it, or give it a shot and hope Apple doesn't trample on your stuff. Personally I think we may just forget about making such changes going forward.

[bpavlov]

@mm2270 I think that's exactly what Apple wants. Personally it's not a MAJOR issue for us. When I got to my position my first task was to move everything to profiles. However there are some pesky preferences that you can't really do it on. But it's not a major impact or showstopper.

For reference:

for USER_TEMPLATE in "/System/Library/User Template"/*
    do
    #Set the Favorite servers
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.sidebarlists favoriteservers -dict-add CustomListItems '( { Name = "afp://server1/"; URL = "afp://server1/"; }, { Name = "smb://server2/"; URL = "smb://server2/"; }, { Name = "smb://server3/"; URL = "smb://server3/"; }, { Name = "smb://server4/"; URL = "smb://server4/"; } )'

    #Turn off "Back To My Mac" and "Bonjour" in sidebar. Turn on "Connected servers" in sidebar.
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.sidebarlists networkbrowser "<dict><key>Controller</key><string>CustomListItems</string><key>CustomListItems</key><array></array><key>CustomListProperties</key><dict><key>com.apple.NetworkBrowser.backToMyMacEnabled</key><false/><key>com.apple.NetworkBrowser.bonjourEnabled</key><false/><key>com.apple.NetworkBrowser.connectedEnabled</key><true/></dict></dict>"

    #Show External Hard Drives on Desktop
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.finder ShowExternalHardDrivesOnDesktop -bool true

    #Show Hard Drives on Desktop
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.finder ShowHardDrivesOnDesktop -bool true

    #Show Mounted Servers on Desktop
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.finder ShowMountedServersOnDesktop -bool true

    #Show Removable Media on Desktop
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.finder ShowRemovableMediaOnDesktop -bool true

    #Set Finder new window to open User Home folder by default
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.finder NewWindowTarget -string PfHm

    #Show Status Bar in Finder
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.finder ShowStatusBar -bool TRUE

    #Set Safari to not open downloads automatically
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari AutoOpenSafeDownloads -bool FALSE

    #Set Safari to confirm when closing multiple pages
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari ConfirmClosingMultiplePages -bool TRUE

    #Set Safari homepage
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari HomePage -string www.company.com

    #Set Safari new tab behavior to open a blank page
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari NewTabBehavior -int 1

    #Set Safari new tab behavior to open home page
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari NewWindowBehavior -int 0
done

And that's only because we wanted those settings to be applied only once.

[milesleacy]

@pblake

As an admin, what is the harm in turning off SIP making a few controlled changes, like deleting the persistent apps in the Dock and then turning SIP back on? If Apple has a way to disable it, then they built that in to be used in a controlled circumstance. I completely agree with everyone that it should be on and used, but I don't see the harm in temporally disabling in it to edit your base config, if you know what you're doing.

The problem is that we don't know what we're doing. Or more accurately, we don't know what Apple is doing or will do in the next update. Given this, I can't see the value in disabling SIP, even temporarily, especially for the purpose of doing things Apple says we shouldn't do.

We can accomplish our goals in the Apple-approved directories. It is safer to observe Apple's "keep out" signs.

[gachowski]

It's both We and Apple don't know what we are doing, from what I have read SIP is much bigger than most people understand. I would define it as cutting edge!!!

C