3 ms·

Can somebody translate this to english? A shell was never an access control mechanism. It was a prompt at which you could type commands to run. As a hack they a

Can somebody translate this to english? A shell was never an access control mechanism. It was a prompt at which you could type commands to run. As a hack they added authentication to it some time in the 60's at MIT. > Today, the only two measures of login access control that really work in a general environment are either scrambling the login's password (and disable any SSH authorized keys) or excluding the login entirely from your various authentication data sources (your LDAP servers, your Apache htpasswd files, and so on). It's a pity that changing people's shells is no longer enough (it was both easy and convenient), but that's how the environment has evolved. This literally makes no sense. Scrambling a login password is not an access control mechanism. Excluding "a login" (a what?) from an authentication data source... the hell does this mean? You mean disabling a user account? The last part, "changing a user's shell", makes a little sense, as you used to be able to prevent a user from logging in by changing their shell to "/bin/false" or something, but that isn't disabling authentication, that's just breaking the shell. Authentication still works if the shell has changed, it just can't execute the shell after you authenticate. The proper way of disabling the account is to set the "disabled account" bit in the shadow or password file. But that's just one authentication mechanism (NSS). There is no universal authentication mechanism, so for any other given authentication mechanism, you need to disable it however that given method allows you.

deleted 3y ago
[deleted]
bananapub 3y ago
I think you've got the wrong end of the stick - it's about forcing the login shell to something (like sftp or rbash or or /bin/nologin whatever) which was a historically somewhat popular thing to do
deleted 3y ago
[deleted]
kmeisthax 3y ago
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.

deleted 3y ago

[deleted]

bananapub 3y ago

I think you've got the wrong end of the stick - it's about forcing the login shell to something (like sftp or rbash or or /bin/nologin whatever) which was a historically somewhat popular thing to do

deleted 3y ago

[deleted]

kmeisthax 3y ago

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.