Unix shells are generally not viable access control mechanisms any more

1. They introduce their argument as if it is solely about shell access (the conclusion also only mentions "login access control"), but then the first example/statement they make is about non-shell access (Samba, IMAP, Apache).

2. The second argument conflates authentication and authorization, and concludes that to implement shell authorization properly, your only choice is to provide multiple authentication systems.

Zero effort is spent on explaining why existing/historic shell authorization systems (such as simple DAC groups or rbash) are inadequate, and it's not clear to me what threat model they are using to arrive at their conclusion.

edit: rethinking this, I think TFA is just lacking a clear problem statement. They seem to be talking specifically about non-shell services that (ab)use the user's shell field in /etc/passwd as authorization information, and then complaining that many services did not follow suit.

> First, you almost certainly operate a variety of services that normally only use Unix logins as a source of (password) authentication and perhaps a UID to operate as, and ignore the login's shell. This is the common pattern of Samba, IMAP servers, Apache HTTP Basic Authentication, and so on.

So you have a user on your server nginx:x:100:101:nginx:/var/lib/nginx:/sbin/nologin

And your also running samba network shares, you point your samba client at your server and use user nginx and inexplicably the password you also set for that user to login? This a service is using etc/shadow basses authentication but not sending the message in /etc/nologin .. presumably samba won’t work really in this case..

>In some cases you may be able to teach these services to look at the login's shell and do special things, but some of them are sealed black boxes and even the ones that can be changed require you to go out of your way. If you forget one, it fails open (allowing access to people with an administrative shell that should lock them out

Is this talking about setting up applications..like a web server, that would give a http access to a uses home for, And having these services authenticate with the servers etc/shadow or configured Pam providers, and also then check out the shell in /etc/password to gracefully handle access management and error messages?

"One of these services is SSH itself, since you can generally initiate SSH sessions and ask for port forwarding or other features that don't cause SSH to run the login shell"

But, even that sort of falls apart because we also had inetd in the "old days", which spawned lots of different things as different users without invoking a login shell.

Generally, the article seems to be lamenting that not everything is gated by userids and groups anymore. That's true, but it doesn't seem recent to me. Aside from inetd, I could (and did) massage kermit (or uucp, etc) into being a multi-service gateway in the 1980's.

I suppose it's somewhat correct in the idea that figuring how any particular service limits rights is now very complicated. You have the old familiar stuff (users, groups). But now you also have virtual machines, containers, namespaces, capabilities. And things like seccomp and apparmor. Then, various sandboxing schemes within utilities, languages and frameworks or OS facilities like ebpf.

Besides that, I don’t know.

To bypass shell restrictions in the past, but I'm not sure if that will work with your example.

  Match User anonymous
          PasswordAuthentication yes
          PermitEmptyPasswords yes
          DisableForwarding yes
          PermitTTY no

But I vaguely remember that in the past it may have been anything, including SHELL.

Using scanning electron microscopy (SEM), we characterized the microstructure of hamster claws, revealing a keratinous composition with intricate surface patterns. Nano-indentation techniques were employed to determine the hardness and resilience of the claws. Their sharpness was quantitatively assessed using a sharpness index, which considered both geometric and material properties.

To test the potential application as micro-screwdrivers, we designed a set of experiments where hamster claws were used to engage with micro-screws commonly found in electronics and precision instruments. The results indicated that while hamster claws can fit into the grooves of certain micro-screws, the torque they can generate is limited due to their flexibility and the lack of a proper grip mechanism.

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.