8 ms·

Unix shells are generally not viable access control mechanisms any more

174 points by ingve 3y ago

dizhn 3y ago
I don't get it. When was shell involved with using Apache basic passwords or LDAP authentication? It requires extensive extra steps (pam modules etc) to plug these things into a unix system for authentication purposes. Also that would be authentication but access control implies authorization.
- totetsu 3y ago
  Yeah my reading comprehension process maxed out a core on this one. > 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?
  - tetha 3y ago
    Mh. I think the problem is: There are (at least) 2 fundamentally different use cases for linux/unix systems. One is what I'd call a shell-server. On a shell-server, I have a bunch of accounts for users, and there are services supplied for these users. There will be /home/tetha, and /home/tetha/share and /home/tetha/http. And then you have some SMB sharing /home/*/share and you login there with your password, Apache serves /home/*/http for the intranet and so on. This is a very common setup at universities, for example. The other thing is what I'd call an application server or a service server (but that name sucks). Here, you have a system and the main purpose of the system is to serve a web page via nginx, or be a postgres node and such. These service-systems tend to be both more controlled, but also simpler. You need to grant a rather small, very known set of users access to these - 10 - 30 usually. And, honestly, these service-level systems tend to have very streamlined permissions, because realistically, shell-access is enough attack profile to be considered root access unless you are very diligent. Shell-servers however are very, very complex to handle. One big shell-server can be overall more complex than many infrastructures around in total.
- mypgovroom 3y ago
  Ok. I read it twice trying to catch something but had the same thoughts as you.
blueflow 3y ago
The post does not back up its headline? How can a SHELL=/bin/false be bypassed via SSH? For the various kind of forwarding SSH supports, they all can be disabled via sshd_config.
- batch12 3y ago
  Ive used something like ''' ssh -t user@host /bin/sh ''' To bypass shell restrictions in the past, but I'm not sure if that will work with your example.
  - blueflow 3y ago
    This won't work because the command send to the server is not an argument vector, but a command string interpreted by the users login shell. `ssh -t user@remote /bin/sh asdf` would execute `/bin/false -c "/bin/sh asdf"` on the remote.
    - batch12 3y ago
      Makes sense, thanks for the clarification.
  - LinuxBender 3y ago
    Feel free to try it out sftp share@ohblog.net (no pw) # grep share /etc/passwd /etc/shadow /etc/passwd:share:x:5002:5000::/data/sftp/share:/bin/false /etc/shadow:share::19614:::::: The partially redacted /etc/ssh/sshd_config is copied to /pub/ in the SFTP account. If you can bypass the restriction please do share how it was done. I don't offer bug bounties but I think people would find it interesting. OS is Alpine Linux. All CPU mitigations are disabled in the VM. No MAC As in no SElinux or AppArmor. I won't complain, just pretty please don't DDoS the server or anything that would make that VPS do work. Feel free to also tinker with the web and voice chat server on that node.
- tyingq 3y ago
  I think it's comparing to the "old days" when there was a more 1:1 relationship of service-on-a-port plus a specific userid. Because the article specifically calls out: "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.
h2odragon 3y ago
are they speaking about changing the "shell" field in `/etc/password` as a means of broader access control? That went away a long, long time ago; the question of "which system am i authenticating myself to" was often already too complicated for that way back when when "shadow passwords" were a new idea.
salzig 3y ago
It’s always interesting to find people who don’t know about `-N` („Do not execute a remote command. This is useful for just forwarding ports.“[0]), which was quite neat to access the MySQL on the same host (with no root database Passwort, duh) at one of my previous employers. [0]: https://man7.org/linux/man-pages/man1/ssh.1.html https://man7.org/linux/man-pages/man1/ssh.1.html
fooblat 3y ago
This article could have been published 30 years ago. In professional unix admin circles this was already well known back them. Although I could be misreading it as the article is not very clear. I think this are the points it is trying to make: 1. Once upon a time you could rely on the passwd file and shell behavior as an effective means of authentication and access control. 2. It has been a very long time since that was an effective approach, for a variety of reasons, and you should not do this on modern production systems.
- Attummm 3y ago
  Would be possible to share those reasons?
  - fanf2 3y ago
    Several are outlined in TFA
    - no_time 3y ago
      Tangent, I can't find what "TFA" stands for. My gut tells me it's "The Fucking Article". Am I correct?
      - worble 3y ago
        Yes
      - InvaderFizz 3y ago
        Yes. TFA = The Fucking Article. Much like: RTFM = Read The Fucking Manual.
      - NavinF 3y ago
        Yes, but in polite company you can pretend it means "The Freaking Article"
        BLKNSLVR 3y ago
onetimeuse92304 3y ago
I pretty much assume now that if somebody has ability to run an arbitrary process on the machine (ie shell), they have root access to that machine regardless of their starting access level.
debarshri 3y ago
One of the learnings lately has been that when you think about access control, it is combination of the downstream access control mechanism + a network layer grant to access the resource. For eg. If you want to access a server or host, you have some authorization to SSH into it but also by you have network access only to that server or host from your source and then authorization is revoked also the network access to the server or host is revoked too.
AtlasBarfed 3y ago
Basically they want a somewhat poorly designed configuration map (environment variables) to be attached to these operations, but instead everything comes from adhoc/bespoke configuration sources on a per app basis (like ~/.ssh/config)
nickdothutton 3y ago
I'd better re-read this article because I don't think shells were ever (in my 20something-mumble years)a terribly strong access control mechanism(). Without putting in the effort. Meaning an appropriate (poss non-default) security model, chroot/jails, possibly pledge etc.
dboreham 3y ago
In case anyone is tempted to read the article: it's totally incoherent, even to someone knowledgeable in the field.
jmbwell 3y ago
Judging by the thread here, the very premise seems difficult to imagine today. But there was a time, indeed, when end users regularly logged in to a Unix system as themselves, and their shell specified the program they could run, like a line of business app or something, and short of exploiting a vulnerability in that app, that was all they could access, sitting there at a physical terminal typing on a keyboard. There just weren’t that many other ways to spawn a process. Meanwhile, these days, it seems like the only user ever running anything is docker, and “access control” has an entirely different set of meanings.
- djur 3y ago
  And the author is a sysadmin at a university, and universities are pretty much the last vestige of that traditional Unix login model of accessing shared services. From some other articles he's written, it sounds like his environment has been very conservatively updated over the years.
poppafuze 3y ago
At best, this is an exposition of someone's conflation of their perception of a controller problem as a view problem, with the implied model problem ignored.
dingosity 3y ago
Uhh... wat?
0xbadcafebee 3y ago
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.
KaiserPro 3y ago
I have had the pleasure(?) of running a large linux network, I don't think it was ever really the case that shells were a viable access control mechanisms on their own. Firstly it only really worked if you were all sharing the same machine with remote terminals, which most people don't do anymore. Second NFS happened when if you configured it badly you could just pretend you were any user you liked. I'm assuming this is part of the reason why kerberos was invented. Basically the only practical way to tie down a network of machines was to make sure that authentication was done with LDAP and Kerberos. LDAP did the name, UID/GID and user metadata and kerberos the authentication. You could then use that ticket to gain access to other things (yes, even over HTTP, NFS or SSH) Nowadays you'd use active directory, which is LDAP+Kerberos, but with a nice expensive gui. /etc/passwd(or shadow) died _years_ ago, It was dodgy even in the 90s, let alone now. Its fine for single user machines, but not networked.
stonogo 3y ago
Using custom shells for IMAP or HTTP auth must have been the parallel reality where checkpassword(1) never existed. I certainly never ran into this behavior in the wild and would have strenuously objected had I done so. Setting custom shells is fine for providing tunneled services over ssh tunnels or the like (many git hosts use this functionality) but using them for access control just meant your only safety net was whether the program's author was really good at preventing string overflows. This was never a good idea.
flanked-evergl 3y ago
I guess I'm just lucky that I have never ever in my life even once seen something almost similar to using a Unix shell as an access control mechanism. Maybe next we will hear that Hammers are not viable screwdrivers any more because, you know, that is also probably something everybody already knows.
- post-it 3y ago
  Yeah, this post is giving https://xkcd.com/2071/ https://xkcd.com/2071/
- totetsu 3y ago
  >In the realm of unconventional tools, the potential application of biological structures has always been a topic of intrigue. This study delves into the material science behind the potential of hamster claws to function as micro-screwdrivers, given their inherent sharpness and structure. 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.
hoistbypetard 3y ago
This is a response to the headline and not yet to the story: were UNIX shells ever an access control mechanism? I never viewed them that way.
madeofpalk 3y ago
Side note - is this author noteworthy for something in particular? Their somewhat average posts consistently make it to the front page and tend to get a more mixed/negative reaction than normal https://news.ycombinator.com/from?site=utoronto.ca https://news.ycombinator.com/from?site=utoronto.ca
chatmasta 3y ago
When you SSH into GitLab, you get a "shell," which at one point was a locked-down Unix shell where you could only run Git commands. That's a workable solution, but they (rightly) migrated off it [0], so now it's just a Go program [1] that runs an SSH server and interprets a small list of valid commands. This basically inverts the security model. The Unix shell approach is leaky, because you never know if you've plugged all the holes while only allowing the commands you want. Whereas the Go program is only capable of executing a narrow range of commands, which it interprets itself, in its own fake shell, while exposing an SSH server. Fun fact: one of the commands [2] the shell implements is `personal_access_token`, so you can programmatically mint a new PAT, since you've already authenticated via your SSH key: ssh git@gitlab.com personal_access_token someTokenName api,read_repository,read_api,read_user,read_registry 90 [0] https://about.gitlab.com/blog/2022/08/17/why-we-have-implemented-our-own-sshd-solution-on-gitlab-sass/ https://about.gitlab.com/blog/2022/08/17/why-we-have-impleme... [1] https://gitlab.com/gitlab-org/gitlab-shell https://gitlab.com/gitlab-org/gitlab-shell [2] https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/internal/command/commandargs/shell.go#L13-20 https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/inter...
- kccqzy 3y ago
  How is that different from writing your own shell that implements a tiny subset of the functionality with support for a small number of commands? You can even write it in Go if that's your preferred language.
  - chatmasta 3y ago
    That's exactly what it is, but the point is that it's not a Unix shell, and it's not running as a subcommand of SSH (which you could also do with a custom shell). There's no tty involved, and so the attack surface is reduced - if you exploit a logic error in the Go code (e.g. parameter pollution), you won't be able to do more than run one of the commands that it already runs. But if you exploit a logic error in a Unix shell with parameter pollution, then the attack surface is much greater. That said, of course if an attacker finds a bug in the Go code that enables arbitrary code execution, then the attack surface is just as wide as any other binary on the system, including a Unix shell, so you still need to lock down the privileges of the process itself.
rlpb 3y ago
I think this is being approached backwards - both by the article and by commenters here. A Unix account is a viable access control mechanism. If you create one, you give its human user access to do everything that the Unix user can do. This can be very useful. But others want to give humans users more restricted access than their corresponding Unix account. This is futile, since the Unix account is the basic unit of access control on a Unix or Unix-like system. The author is correct that if you want to do this then you must create a sandbox. General tools won't do, because they're not designed for it, and/or are generally swimming against the tide.
cardiffspaceman 3y ago
I skimmed this article using a different POV than many of you, and it made sense. From the other POV it is clear why many of you don’t like or in some cases understand it. If your idea of “Unix” is Linux kernel with Busybox and dropbear, it makes sense. I think.

174 points by ingve 3y ago

I don't get it. When was shell involved with using Apache basic passwords or LDAP authentication? It requires extensive extra steps (pam modules etc) to plug these things into a unix system for authentication purposes. Also that would be authentication but access control implies authorization.

totetsu 3y ago
Yeah my reading comprehension process maxed out a core on this one. > 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?
- tetha 3y ago
  Mh. I think the problem is: There are (at least) 2 fundamentally different use cases for linux/unix systems. One is what I'd call a shell-server. On a shell-server, I have a bunch of accounts for users, and there are services supplied for these users. There will be /home/tetha, and /home/tetha/share and /home/tetha/http. And then you have some SMB sharing /home/*/share and you login there with your password, Apache serves /home/*/http for the intranet and so on. This is a very common setup at universities, for example. The other thing is what I'd call an application server or a service server (but that name sucks). Here, you have a system and the main purpose of the system is to serve a web page via nginx, or be a postgres node and such. These service-systems tend to be both more controlled, but also simpler. You need to grant a rather small, very known set of users access to these - 10 - 30 usually. And, honestly, these service-level systems tend to have very streamlined permissions, because realistically, shell-access is enough attack profile to be considered root access unless you are very diligent. Shell-servers however are very, very complex to handle. One big shell-server can be overall more complex than many infrastructures around in total.
mypgovroom 3y ago
Ok. I read it twice trying to catch something but had the same thoughts as you.

blueflow 3y ago

The post does not back up its headline? How can a SHELL=/bin/false be bypassed via SSH? For the various kind of forwarding SSH supports, they all can be disabled via sshd_config.

batch12 3y ago
Ive used something like ''' ssh -t user@host /bin/sh ''' To bypass shell restrictions in the past, but I'm not sure if that will work with your example.
- blueflow 3y ago
  This won't work because the command send to the server is not an argument vector, but a command string interpreted by the users login shell. `ssh -t user@remote /bin/sh asdf` would execute `/bin/false -c "/bin/sh asdf"` on the remote.
  - batch12 3y ago
    Makes sense, thanks for the clarification.
- LinuxBender 3y ago
  Feel free to try it out sftp share@ohblog.net (no pw) # grep share /etc/passwd /etc/shadow /etc/passwd:share:x:5002:5000::/data/sftp/share:/bin/false /etc/shadow:share::19614:::::: The partially redacted /etc/ssh/sshd_config is copied to /pub/ in the SFTP account. If you can bypass the restriction please do share how it was done. I don't offer bug bounties but I think people would find it interesting. OS is Alpine Linux. All CPU mitigations are disabled in the VM. No MAC As in no SElinux or AppArmor. I won't complain, just pretty please don't DDoS the server or anything that would make that VPS do work. Feel free to also tinker with the web and voice chat server on that node.
tyingq 3y ago
I think it's comparing to the "old days" when there was a more 1:1 relationship of service-on-a-port plus a specific userid. Because the article specifically calls out: "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.

h2odragon 3y ago

are they speaking about changing the "shell" field in `/etc/password` as a means of broader access control? That went away a long, long time ago; the question of "which system am i authenticating myself to" was often already too complicated for that way back when when "shadow passwords" were a new idea.

salzig 3y ago

It’s always interesting to find people who don’t know about `-N` („Do not execute a remote command. This is useful for just forwarding ports.“[0]), which was quite neat to access the MySQL on the same host (with no root database Passwort, duh) at one of my previous employers. [0]: https://man7.org/linux/man-pages/man1/ssh.1.html https://man7.org/linux/man-pages/man1/ssh.1.html

fooblat 3y ago

This article could have been published 30 years ago. In professional unix admin circles this was already well known back them. Although I could be misreading it as the article is not very clear. I think this are the points it is trying to make: 1. Once upon a time you could rely on the passwd file and shell behavior as an effective means of authentication and access control. 2. It has been a very long time since that was an effective approach, for a variety of reasons, and you should not do this on modern production systems.

Attummm 3y ago
Would be possible to share those reasons?
- fanf2 3y ago
  Several are outlined in TFA
  - no_time 3y ago
    Tangent, I can't find what "TFA" stands for. My gut tells me it's "The Fucking Article". Am I correct?
    - worble 3y ago
      Yes
    - InvaderFizz 3y ago
      Yes. TFA = The Fucking Article. Much like: RTFM = Read The Fucking Manual.
    - NavinF 3y ago
      Yes, but in polite company you can pretend it means "The Freaking Article"
      - BLKNSLVR 3y ago

onetimeuse92304 3y ago

I pretty much assume now that if somebody has ability to run an arbitrary process on the machine (ie shell), they have root access to that machine regardless of their starting access level.

debarshri 3y ago

One of the learnings lately has been that when you think about access control, it is combination of the downstream access control mechanism + a network layer grant to access the resource. For eg. If you want to access a server or host, you have some authorization to SSH into it but also by you have network access only to that server or host from your source and then authorization is revoked also the network access to the server or host is revoked too.

AtlasBarfed 3y ago

Basically they want a somewhat poorly designed configuration map (environment variables) to be attached to these operations, but instead everything comes from adhoc/bespoke configuration sources on a per app basis (like ~/.ssh/config)

nickdothutton 3y ago

I'd better re-read this article because I don't think shells were ever (in my 20something-mumble years)a terribly strong access control mechanism(). Without putting in the effort. Meaning an appropriate (poss non-default) security model, chroot/jails, possibly pledge etc.

dboreham 3y ago

In case anyone is tempted to read the article: it's totally incoherent, even to someone knowledgeable in the field.

jmbwell 3y ago

Judging by the thread here, the very premise seems difficult to imagine today. But there was a time, indeed, when end users regularly logged in to a Unix system as themselves, and their shell specified the program they could run, like a line of business app or something, and short of exploiting a vulnerability in that app, that was all they could access, sitting there at a physical terminal typing on a keyboard. There just weren’t that many other ways to spawn a process. Meanwhile, these days, it seems like the only user ever running anything is docker, and “access control” has an entirely different set of meanings.

djur 3y ago
And the author is a sysadmin at a university, and universities are pretty much the last vestige of that traditional Unix login model of accessing shared services. From some other articles he's written, it sounds like his environment has been very conservatively updated over the years.

poppafuze 3y ago

At best, this is an exposition of someone's conflation of their perception of a controller problem as a view problem, with the implied model problem ignored.

dingosity 3y ago

Uhh... wat?

0xbadcafebee 3y ago

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.

KaiserPro 3y ago

I have had the pleasure(?) of running a large linux network, I don't think it was ever really the case that shells were a viable access control mechanisms on their own. Firstly it only really worked if you were all sharing the same machine with remote terminals, which most people don't do anymore. Second NFS happened when if you configured it badly you could just pretend you were any user you liked. I'm assuming this is part of the reason why kerberos was invented. Basically the only practical way to tie down a network of machines was to make sure that authentication was done with LDAP and Kerberos. LDAP did the name, UID/GID and user metadata and kerberos the authentication. You could then use that ticket to gain access to other things (yes, even over HTTP, NFS or SSH) Nowadays you'd use active directory, which is LDAP+Kerberos, but with a nice expensive gui. /etc/passwd(or shadow) died _years_ ago, It was dodgy even in the 90s, let alone now. Its fine for single user machines, but not networked.

stonogo 3y ago

Using custom shells for IMAP or HTTP auth must have been the parallel reality where checkpassword(1) never existed. I certainly never ran into this behavior in the wild and would have strenuously objected had I done so. Setting custom shells is fine for providing tunneled services over ssh tunnels or the like (many git hosts use this functionality) but using them for access control just meant your only safety net was whether the program's author was really good at preventing string overflows. This was never a good idea.

flanked-evergl 3y ago

I guess I'm just lucky that I have never ever in my life even once seen something almost similar to using a Unix shell as an access control mechanism. Maybe next we will hear that Hammers are not viable screwdrivers any more because, you know, that is also probably something everybody already knows.

post-it 3y ago
Yeah, this post is giving https://xkcd.com/2071/ https://xkcd.com/2071/
totetsu 3y ago
>In the realm of unconventional tools, the potential application of biological structures has always been a topic of intrigue. This study delves into the material science behind the potential of hamster claws to function as micro-screwdrivers, given their inherent sharpness and structure. 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.

hoistbypetard 3y ago

This is a response to the headline and not yet to the story: were UNIX shells ever an access control mechanism? I never viewed them that way.

madeofpalk 3y ago

Side note - is this author noteworthy for something in particular? Their somewhat average posts consistently make it to the front page and tend to get a more mixed/negative reaction than normal https://news.ycombinator.com/from?site=utoronto.ca https://news.ycombinator.com/from?site=utoronto.ca

chatmasta 3y ago

When you SSH into GitLab, you get a "shell," which at one point was a locked-down Unix shell where you could only run Git commands. That's a workable solution, but they (rightly) migrated off it [0], so now it's just a Go program [1] that runs an SSH server and interprets a small list of valid commands. This basically inverts the security model. The Unix shell approach is leaky, because you never know if you've plugged all the holes while only allowing the commands you want. Whereas the Go program is only capable of executing a narrow range of commands, which it interprets itself, in its own fake shell, while exposing an SSH server. Fun fact: one of the commands [2] the shell implements is `personal_access_token`, so you can programmatically mint a new PAT, since you've already authenticated via your SSH key: ssh git@gitlab.com personal_access_token someTokenName api,read_repository,read_api,read_user,read_registry 90 [0] https://about.gitlab.com/blog/2022/08/17/why-we-have-implemented-our-own-sshd-solution-on-gitlab-sass/ https://about.gitlab.com/blog/2022/08/17/why-we-have-impleme... [1] https://gitlab.com/gitlab-org/gitlab-shell https://gitlab.com/gitlab-org/gitlab-shell [2] https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/internal/command/commandargs/shell.go#L13-20 https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/inter...

kccqzy 3y ago
How is that different from writing your own shell that implements a tiny subset of the functionality with support for a small number of commands? You can even write it in Go if that's your preferred language.
- chatmasta 3y ago
  That's exactly what it is, but the point is that it's not a Unix shell, and it's not running as a subcommand of SSH (which you could also do with a custom shell). There's no tty involved, and so the attack surface is reduced - if you exploit a logic error in the Go code (e.g. parameter pollution), you won't be able to do more than run one of the commands that it already runs. But if you exploit a logic error in a Unix shell with parameter pollution, then the attack surface is much greater. That said, of course if an attacker finds a bug in the Go code that enables arbitrary code execution, then the attack surface is just as wide as any other binary on the system, including a Unix shell, so you still need to lock down the privileges of the process itself.

rlpb 3y ago

I think this is being approached backwards - both by the article and by commenters here. A Unix account is a viable access control mechanism. If you create one, you give its human user access to do everything that the Unix user can do. This can be very useful. But others want to give humans users more restricted access than their corresponding Unix account. This is futile, since the Unix account is the basic unit of access control on a Unix or Unix-like system. The author is correct that if you want to do this then you must create a sandbox. General tools won't do, because they're not designed for it, and/or are generally swimming against the tide.

cardiffspaceman 3y ago

I skimmed this article using a different POV than many of you, and it made sense. From the other POV it is clear why many of you don’t like or in some cases understand it. If your idea of “Unix” is Linux kernel with Busybox and dropbear, it makes sense. I think.