Bug#1008082: How to --lock an account
On Sun, Aug 07, 2022 at 01:05:13PM -0400, Jason Franklin wrote: > On Wed, Jul 27, 2022 at 03:21:08PM +0200, Marc Haber wrote: > > > Before I start, I want to make sure we agree on what should be done. > > > > > > I asserted that two things were sufficient: > > > 1. Put a '!' in front of the user's password in /etc/shadow > > > 2. Expire the account > > > > > > This makes it trivial to unlock an account with all of its attributes > > > intact, including login shell. > > > > I think that having nologin as a shell has the advantage of giving a > > clear error message IF somebody manages to log in to the expired account > > with an invalid password. > > The message with /usr/sbin/nologin is indeed nice. On my system, I get > something like... > > | $ su --login foo > | Password: > | This account is currently not available. Yes, that's what I'd like to have, but of course, if the account is password-locked and expired, getting at this point is already a bug. > With password locking plus account expiration, I get... > > | $ su --login fish > | Password: > | su: Authentication failure > > I find it odd that I get a password prompt for an account that is > expired, but so it is. I think that the idea is not to give information that an account is expired, indicating an unused accout. > My only reason for saying it's not necessary is that someone being able > to log in to an expired account would indicate a bug somewhere else that > should be fixed (in shadow, maybe?). If account expiration cannot be > relied upon, we have a bigger security concern, I think. I think so, and it's not our bug anyway, but it would probably be nice to implement Defense in Depth. > > For a normal user account, I am undecided whether: > > > > - leave login shell intact, leaving a possible security hole > > Again, this is where I am not so sure. > > If there is a security hole, it would be someone else's, right? Right. > Account expiration is either reliable or it is not. If a system account is migrated to a directory service (which is possible), we might not have write access to the account expiration data and to the hashed password. > > - set login shell back to the default when the account gets reenabled > > - save login shell somewhere to reinstate if on reenabling. > > > > I'd say, do it as you see fit, changing that at a later time would be a > > rather isolated change so I'm fine with going ahead either way here, > > while still having a personal preference for the third possibility, but > > I am not the one who decides that. > > This is fair. > > As soon as I'm done with the other bug I'm working on, I'll move to this > one and proceed with the stateless implementation. > > Saving and restoring a user's shell can be added later if needed. > > Sound good? Proceed, but please document that we are still considering to change login shell at a later time. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1008082: How to --lock an account
On Wed, Jul 27, 2022 at 03:21:08PM +0200, Marc Haber wrote: > > Before I start, I want to make sure we agree on what should be done. > > > > I asserted that two things were sufficient: > > 1. Put a '!' in front of the user's password in /etc/shadow > > 2. Expire the account > > > > This makes it trivial to unlock an account with all of its attributes > > intact, including login shell. > > I think that having nologin as a shell has the advantage of giving a > clear error message IF somebody manages to log in to the expired account > with an invalid password. The message with /usr/sbin/nologin is indeed nice. On my system, I get something like... | $ su --login foo | Password: | This account is currently not available. With password locking plus account expiration, I get... | $ su --login fish | Password: | su: Authentication failure I find it odd that I get a password prompt for an account that is expired, but so it is. Changing the shell won't hurt, of course. My only reason for saying it's not necessary is that someone being able to log in to an expired account would indicate a bug somewhere else that should be fixed (in shadow, maybe?). If account expiration cannot be relied upon, we have a bigger security concern, I think. > For a normal user account, I am undecided whether: > > - leave login shell intact, leaving a possible security hole Again, this is where I am not so sure. If there is a security hole, it would be someone else's, right? Account expiration is either reliable or it is not. > - set login shell back to the default when the account gets reenabled > - save login shell somewhere to reinstate if on reenabling. > > I'd say, do it as you see fit, changing that at a later time would be a > rather isolated change so I'm fine with going ahead either way here, > while still having a personal preference for the third possibility, but > I am not the one who decides that. This is fair. As soon as I'm done with the other bug I'm working on, I'll move to this one and proceed with the stateless implementation. Saving and restoring a user's shell can be added later if needed. Sound good? -- Jason Franklin
Bug#1008082: How to --lock an account
[just writing the bug report after realizing that that one forwards to adduser@p.d.o anyway] On Wed, Jul 27, 2022 at 05:52:03PM -0400, Matt Barry wrote: > On Wed, 2022-07-27 at 15:21 +0200, Marc Haber wrote: > > On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote: > > For a normal user account, I am undecided whether: > > > > - leave login shell intact, leaving a possible security hole > > - set login shell back to the default when the account gets reenabled > > - save login shell somewhere to reinstate if on reenabling. > > Maybe have adduser prompt when using --unlock (and without -s) whether > to reset the shell to the default? (just #2, but more explicit) If we don't have state, what would be the alternative to setting it back to default? I'd say a warning that the shell is being reset to the default. > Then again a single colon-separated file to check *before* selecting > the default isn't a ton of added complexity. Yes, we need some kind of state sooner or later anyway, so we'll have /var/lib/adduser anyway. > Contrary to the behavior of usermod(8), I personally think adding the > additional barrier to access is a feature. The additional barrier of having nologin as a shell, you mean? Just making sure. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1008082: How to --lock an account
On Wed, 2022-07-27 at 15:21 +0200, Marc Haber wrote: > On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote: > For a normal user account, I am undecided whether: > > - leave login shell intact, leaving a possible security hole > - set login shell back to the default when the account gets reenabled > - save login shell somewhere to reinstate if on reenabling. Maybe have adduser prompt when using --unlock (and without -s) whether to reset the shell to the default? (just #2, but more explicit) Then again a single colon-separated file to check *before* selecting the default isn't a ton of added complexity. Contrary to the behavior of usermod(8), I personally think adding the additional barrier to access is a feature. > I'd say, do it as you see fit Me too :) mb signature.asc Description: This is a digitally signed message part
Bug#1008082: How to --lock an account
On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote: > On Wed, Jul 27, 2022 at 12:09:27PM +0200, Marc Haber wrote: > > > > > I think Jason was working on this? > > > > > 1008082/1008084/390457 --system --lock functionality > > > > > > > > I hope so, that should be the next important big step, maybe a team > > > > effort? Can this be sensibly split into work units to distribute? > > > > > > Happy to help if I can (divisible work units would help). > > > > Jason, that's your call then. > > I am currently working on the "--homeless" option, which I own in the > BTS listing. Nice. Good! > Before I start, I want to make sure we agree on what should be done. > > I asserted that two things were sufficient: > 1. Put a '!' in front of the user's password in /etc/shadow > 2. Expire the account > > This makes it trivial to unlock an account with all of its attributes > intact, including login shell. I think that having nologin as a shell has the advantage of giving a clear error message IF somebody manages to log in to the expired account with an invalid password. I am not sure whether we actually need to save the login shell, the intended usage is a maintainer script, to have the account locked on purge. The use case for re-activation here is reinstallation of the package, with the normal postinst running as if the account didn't exist, so the package maintainer is either fine with getting the default login shell or has one specified in their adduser call. So, for a system account, we can overwrite the login shell without causing harm. For a normal user account, I am undecided whether: - leave login shell intact, leaving a possible security hole - set login shell back to the default when the account gets reenabled - save login shell somewhere to reinstate if on reenabling. I'd say, do it as you see fit, changing that at a later time would be a rather isolated change so I'm fine with going ahead either way here, while still having a personal preference for the third possibility, but I am not the one who decides that. > Not sure if we reached agreement here. See discussion.. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008082 > > Just let me know. Thanks! Cc. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
