PAM configuration files been restore after upgrade to EI Captitan

Hi guys,


I insert some PAM stacks in the /etc/pam.d/other in 10.10. like this

auth sufficient pam_xxxx.so


Then I upgrade to EI Capitan beta 1, I just found my pam configuration files are been restore to original.

Same for other system pam configuration files, like login, sshd, sudo...


Can anybody tell me if this is a bug or not ?

It don't quite make sense for me, so any app that need to modify PAM would break after upgrade ?

Answered by Max108 in 43967022

Hi again,


/etc (including pam.d of course) is protected by SIP by default.

The following folders all are (you can see for youself: /System/Library/Sandbox/rootless.conf)


/Applications/[All OS X Component Apps]

/Applications/Utilities/[All OS X Component Utility Apps]


/System

/System/Library/Caches

/System/Library/CoreServices

/System/Library/CoreServices/Photo Library Migration Utility.app

/System/Library/CoreServices/RawCamera.bundle

/System/Library/Extensions

/System/Library/Extensions/

/System/Library/LaunchDaemons/com.apple.UpdateSettings.plist

/System/Library/Speech

/System/Library/User Template

/bin

/private/var/db/dyld

/sbin

/usr

/usr/libexec/cups

/usr/local

/usr/share/man

/etc

/tmp

/var


Therefore the logic of reseting /etc/pam.d in case of it having been compromised holds. Rootless is precisely designed to restrict the power of root - for the reasons described in my first reply.


I hope this helps to clarify things.


Max.

Hi bzwesoft,


It makes more sense from the perspective that El Capitan is explicitly focused on tightening security around root access to system files. One of the main security issues in Yosemite and earlier was that, because many consumers opererate their Mac with just a single account, which necessarily has admin rights, there were various exploits that could take advantage of the habit of many users to trustingly enter their password when prompted, for example by an app requesting permission to install a helper program or to make a necessary change for the app's functionality, thereby granting unresticted "root" access to the system. System Integrity Protection (a.k.a. "rootless"), just one of the new security measures in 10.11, is designed to address that.


With that in mind I can see the logic in all systems related to authenication, like PAM, being reset in case they had been compromised while vulnerable on a previous version of OS X.


Max.

Thanks for the answer, Max108,


But I think PAM files under /etc/pam.d is not protected by "rootless", right?

If user got root permission, he or she still could modify those PAM files in EI Capitan.


If a malware have a way to get root access modify these files in 10.10 or prior, they could probably

do that in 10.11. like you said, simply cheat user to enter their password...


So I think it's not quite helpful to reset thess PAM files, it would also bring trouble for App upgrade,

if the good app needs to insert PAM stack to run, how can they be survive after the 10.11 upgrade??

So user have to reinstall the App again?


"rootless" should just restrict the power of root, should not corrupt configuration files, that's what I thought.


Looking forward your reply and regards,

bzwesoft

Accepted Answer

Hi again,


/etc (including pam.d of course) is protected by SIP by default.

The following folders all are (you can see for youself: /System/Library/Sandbox/rootless.conf)


/Applications/[All OS X Component Apps]

/Applications/Utilities/[All OS X Component Utility Apps]


/System

/System/Library/Caches

/System/Library/CoreServices

/System/Library/CoreServices/Photo Library Migration Utility.app

/System/Library/CoreServices/RawCamera.bundle

/System/Library/Extensions

/System/Library/Extensions/

/System/Library/LaunchDaemons/com.apple.UpdateSettings.plist

/System/Library/Speech

/System/Library/User Template

/bin

/private/var/db/dyld

/sbin

/usr

/usr/libexec/cups

/usr/local

/usr/share/man

/etc

/tmp

/var


Therefore the logic of reseting /etc/pam.d in case of it having been compromised holds. Rootless is precisely designed to restrict the power of root - for the reasons described in my first reply.


I hope this helps to clarify things.


Max.

Thanks for the reply, Max108!

I understand this is and intended behaviour in 10.11 now.


I also get the answer from Apple Bug Report.

------------

This is expected behavior. We can’t possibly know whether the custom changes that have been made to this file are still valid under the new major OS, and we have to deliver an OS which functions correctly out-of-the-box. Advanced users such as yourself will understand how to put it back.

PAM configuration files been restore after upgrade to EI Captitan
 
 
Q