4 ms·

That's kind of what it was: https://objective-see.com/blog/blog_0x24.html https://objective-see.com/blog/blog_0x24.html

zbentley 9y ago
It seems to me that the biggest problem highlighted by the link in parent is backwards compatibility of authentication metchanisms. OSX seems to support typical /etc/passwd hashed-user-credential authentication. However, it tries to "upgrade" that authentication mode to "shadowhash or securetoken", which appear to be two new auth schemes integrated with Open Directory. All of those things might be fine, on their own. However, the biggest issue is that there are now more than one primary way to get authenticated on the system. This is likely true because network accounts need to be supported in addition to local ones (I.e. apple accounts, LDAP accounts, etc.). However, my (admittedly uneducated) impression is that the systems for handling those accounts are totally separate--the part of the auth system that is swappable between shadowhash/old-school-passwd/etc. is . . . basically the whole auth system. I'm sure that's a very quick and easy way to write authentication code, and it also preserves backwards compatibility of users doing the old method, but it seems inherently prone to more issues (even if you don't make screw-ups as obvious as this one). You have more auth stacks (and thus code) to debug in total, to say nothing of code that migrates credentials between different auth stacks. Preserving backwards compatibility is important, to be sure, but only sometimes. This seems like a case where things would have been easily mitigated if Apple had done something like "everyone must sign in with their Apple account, now, as the sole authenticating credential for this operating system" during some OS upgrade (or "/etc/passwd no longer works; all these systems have been refactored to use a single central credential database in Keychain Services, update any code that cares since it's being aggressively deprecated", though that would probably have been both harder to implement and harder to sell to the user/developer-base). However, I'm far from an expert here, so maybe the "just expand on the existing UNIX local auth system" option is less-infeasible than it seems (linux ditched this too for network accounts, though, which doesn't give me confidence). Either way, an old-auth-system removal like that would have crippled some of my workflows/code, and others', but it also would have allowed Apple (if they followed it up with a dead-systems-removal pass) to remove many of the then-redundant authentication systems in OSX. TL;DR Linus isn't always right, backwards/userland compatibility shouldn't always be held paramount, especially when you're developing parallel systems for something as critical as authentication. Sometimes the pain caused by deprecation is worth the removal of a security risk.
- biggieshellz 9y ago
  Mac OS X has always used POSIX compliance as a selling point. Would the change you're suggesting break that?
  - zbentley 9y ago
    I think they have already broken POSIX compliance in this area. A lot of the /etc/passwd entries don't do anything by default (like the root entry, in this case, whose significance in that file changes based on an external, second, unrelated-to-POSIX auth system). While the file is still there in the same form it would be on a truly POSIX compliant system, the functionality is not. The change I proposed, or other equivalent changes, might "loudly"/fatally break programs that rely on the /etc/passwd style of auth, but if those programs are depending on POSIX-compliant behavior based on that file on OSX systems already, they are likely "silently"/more subtly broken (which, when it comes to code that interacts with the security system, is a much worse thing, I think). It's the same old accessibility/security compromise as ever though.
- benmmurphy 9y ago
  i think the problem is it is difficult to upgrade a password from one scheme to another scheme without the user presenting the password so they just decided because they are changing both systems and password schemes they would do the migration from the old system to the new system when the user logs in.
- Macha 9y ago
  After all the shit MS got for very strongly nudging users into using MS accounts instead of local accounts and Apple's low key effort to promote OSX and iOS as better for the user (including privacy) than Windows/Android, I can't see mandatory apple account usage being a realistic probability.

It seems to me that the biggest problem highlighted by the link in parent is backwards compatibility of authentication metchanisms. OSX seems to support typical /etc/passwd hashed-user-credential authentication. However, it tries to "upgrade" that authentication mode to "shadowhash or securetoken", which appear to be two new auth schemes integrated with Open Directory. All of those things might be fine, on their own. However, the biggest issue is that there are now more than one primary way to get authenticated on the system. This is likely true because network accounts need to be supported in addition to local ones (I.e. apple accounts, LDAP accounts, etc.). However, my (admittedly uneducated) impression is that the systems for handling those accounts are totally separate--the part of the auth system that is swappable between shadowhash/old-school-passwd/etc. is . . . basically the whole auth system. I'm sure that's a very quick and easy way to write authentication code, and it also preserves backwards compatibility of users doing the old method, but it seems inherently prone to more issues (even if you don't make screw-ups as obvious as this one). You have more auth stacks (and thus code) to debug in total, to say nothing of code that migrates credentials between different auth stacks. Preserving backwards compatibility is important, to be sure, but only sometimes. This seems like a case where things would have been easily mitigated if Apple had done something like "everyone must sign in with their Apple account, now, as the sole authenticating credential for this operating system" during some OS upgrade (or "/etc/passwd no longer works; all these systems have been refactored to use a single central credential database in Keychain Services, update any code that cares since it's being aggressively deprecated", though that would probably have been both harder to implement and harder to sell to the user/developer-base). However, I'm far from an expert here, so maybe the "just expand on the existing UNIX local auth system" option is less-infeasible than it seems (linux ditched this too for network accounts, though, which doesn't give me confidence). Either way, an old-auth-system removal like that would have crippled some of my workflows/code, and others', but it also would have allowed Apple (if they followed it up with a dead-systems-removal pass) to remove many of the then-redundant authentication systems in OSX. TL;DR Linus isn't always right, backwards/userland compatibility shouldn't always be held paramount, especially when you're developing parallel systems for something as critical as authentication. Sometimes the pain caused by deprecation is worth the removal of a security risk.

biggieshellz 9y ago
Mac OS X has always used POSIX compliance as a selling point. Would the change you're suggesting break that?
- zbentley 9y ago
  I think they have already broken POSIX compliance in this area. A lot of the /etc/passwd entries don't do anything by default (like the root entry, in this case, whose significance in that file changes based on an external, second, unrelated-to-POSIX auth system). While the file is still there in the same form it would be on a truly POSIX compliant system, the functionality is not. The change I proposed, or other equivalent changes, might "loudly"/fatally break programs that rely on the /etc/passwd style of auth, but if those programs are depending on POSIX-compliant behavior based on that file on OSX systems already, they are likely "silently"/more subtly broken (which, when it comes to code that interacts with the security system, is a much worse thing, I think). It's the same old accessibility/security compromise as ever though.
benmmurphy 9y ago
i think the problem is it is difficult to upgrade a password from one scheme to another scheme without the user presenting the password so they just decided because they are changing both systems and password schemes they would do the migration from the old system to the new system when the user logs in.
Macha 9y ago
After all the shit MS got for very strongly nudging users into using MS accounts instead of local accounts and Apple's low key effort to promote OSX and iOS as better for the user (including privacy) than Windows/Android, I can't see mandatory apple account usage being a realistic probability.