3 ms·

Traditional Unix conflates authentication and authorization - if you can authenticate as a user you are authorized to use the computer, full stop. If you want t

Traditional Unix conflates authentication and authorization - if you can authenticate as a user you are authorized to use the computer, full stop. If you want to later revoke authorization, or only authorize certain services but not others, Unix provides no general means to do so. Scrambling the password works as a deauthorization mechanism solely because you strip the user of the ability to authenticate. This wouldn't clear authorized_keys, though; services that needed to implement new authentication mechanisms generally did not bother extending /etc/shadow or NSS in an obvious way everyone agreed upon. Changing the login shell used to work because Unix used to be used solely through the medium of /bin/sh. This, however, conflates two different signals: - Who should be allowed to start an interactive session on this machine? - What kind of shell does this user prefer to use? We pretend that disabled users just really love using this one particular shell that immediately kicks them out of their login session. The only bulletproof way to deauthorize a user is to unperson them - delete the account. Except if you do this then their old files still sit there on the disk with their user ID. If you reuse the user ID then the new user gains authorization to the old user's files; so you have to keep track of unpersons to avoid reusing their IDs or meticulously reassign their files to a dedicated cleanup user.

0xbadcafebee 3y ago
> Traditional Unix conflates authentication and authorization - if you can authenticate as a user you are authorized to use the computer, full stop. Incorrect. Nearly every service in a Unix computer has its own authorization mechanisms, there is no blanket authorization over an entire host. The login service has a "nologin" and "securetty" files. Sudo has its sudoers file. RSH has the .rhosts file. FTP daemons have their own authorization logic. NFS authorization options could override local filesystem permissions. Filesystem permissions defined the authorization for device files, but network services (such as CUPS) would add their own authorization mechanisms. Etc, etc, etc. The difference between authentication and authorization has been apparent since time-sharing systems were invented. The operators were authorized to perform different operations than the bog-standard users. There hasn't been a time since the 60's that everyone was authorized the same just because they were authenticated. > Scrambling the password works as a deauthorization mechanism solely because you strip the user of the ability to authenticate. Doesn't work. If you're using SSH key authentication you can skip password auth. With RSH, password auth isn't required if you're coming from a trusted host defined in a .rhosts file. > The only bulletproof way to deauthorize a user is to unperson them - delete the account. That doesn't always work either. There may be more than one authentication system, and they may be configured to simply skip to the next authentication method if a user account is not found. So you would have to delete the account from every authentication system connected. You have to use the prescribed deactivation method for every authentication system connected, otherwise the first auth method may skip the deactivated user but the second system would pick up its own user with that name/ID.

0xbadcafebee 3y ago

> Traditional Unix conflates authentication and authorization - if you can authenticate as a user you are authorized to use the computer, full stop. Incorrect. Nearly every service in a Unix computer has its own authorization mechanisms, there is no blanket authorization over an entire host. The login service has a "nologin" and "securetty" files. Sudo has its sudoers file. RSH has the .rhosts file. FTP daemons have their own authorization logic. NFS authorization options could override local filesystem permissions. Filesystem permissions defined the authorization for device files, but network services (such as CUPS) would add their own authorization mechanisms. Etc, etc, etc. The difference between authentication and authorization has been apparent since time-sharing systems were invented. The operators were authorized to perform different operations than the bog-standard users. There hasn't been a time since the 60's that everyone was authorized the same just because they were authenticated. > Scrambling the password works as a deauthorization mechanism solely because you strip the user of the ability to authenticate. Doesn't work. If you're using SSH key authentication you can skip password auth. With RSH, password auth isn't required if you're coming from a trusted host defined in a .rhosts file. > The only bulletproof way to deauthorize a user is to unperson them - delete the account. That doesn't always work either. There may be more than one authentication system, and they may be configured to simply skip to the next authentication method if a user account is not found. So you would have to delete the account from every authentication system connected. You have to use the prescribed deactivation method for every authentication system connected, otherwise the first auth method may skip the deactivated user but the second system would pick up its own user with that name/ID.