11 ms·

Solution: Let's reimplement PAM in systemd! That should make everyone happy.

dale_glass 4y ago
I think that this is seriously a great idea. PAM should be a service that communicates over an UNIX socket. Upsides: * You can completely isolate it from anything else. Lock it into a sandbox. Use SELinux to ensure it doesn't do anything weird. * Much more secure -- you have a very narrow communication channel, and no exposure to stuff like LD_PRELOAD. * You avoid the mess of the above for the applications using it. Apps using PAM execute PAM code, and that means that anything that uses PAM needs to be able to do any arbitrary thing a PAM module might want to do. * Applications using PAM no longer need to have root access. Your screensaver/lock screen can be completely unprivileged. * If it can be an UNIX socket, it probably can also be a TCP socket, so you can have it run remotely if such a thing makes sense. * The protocol can be inspected * Good opportunity for updating the API and fixing anything lacking.
- krnlpnc 4y ago
  Let’s move the linux kernel and sshd into systemd while we’re at it
  - smitty1e 4y ago
    See your kernel; raise you the whole data center.
  - dale_glass 4y ago
    You're joking, but I'm 100% serious. PAM is crusty and has a bad architecture. The fact that it's written in C, and is linked into another program as a library makes it impossible to fully isolate it from its host application, and exposes it to a myriad possible exploit points. Even wrapper binaries are not a great idea because of how UNIX works. fork() + exec() means the executed binary inherits a lot of state from the caller. Open files, signals, environment variables, chroot, mlock, resource limits, seccomp... there's a myriad of mechanisms that an executed binary can be exposed to, and even if it somehow perfectly takes all of them into account and defends itself against any possible malicious manipulation, the next kernel version could add a new one. That's why I think a sane, modern version of PAM should be a service and only communicate via a UNIX socket. That way you vastly reduce the attack surface, and allow locking up the PAM bits into their own, well defended box.
    - salawat 4y ago
      You should look into GNU Hurd then. I'm being serious, as exactly what you're describing sounds an awful lot like their micro-kernel approach. At least as of the last time I looked into it.
    - throwaway09223 4y ago
      "The fact that it's written in C" The calling convention is C, but you can write PAM in any language. "and is linked into another program as a library makes it impossible to fully isolate it from its host application" Huh? You can never isolate the client side code. You will always have something in your app. "I think a sane, modern version of PAM should be a service and only communicate via a UNIX socket." So, write a module that talks to a socket. That's how like half of the PAM modules already operate. You will always have to have code in the application to talk to whatever oracle you're using. What you're describing here isn't any different from how PAM already works.
      - dale_glass 4y ago
        > Huh? You can never isolate the client side code. You will always have something in your app. Yes, and that "something" can be reduced to reads and writes to a socket. > So, write a module that talks to a socket. That's how like half of the PAM modules already operate. I mean move all of PAM to a service. So for instance currently chsh is a setuid application because it needs to be able to write to /etc/passwd. This is a requirement because the way it works is that it links to libpam, which will load a module, which will write to /etc/passwd, all inside the 'chsh' program. My suggestion would result in chsh becoming a completely unprivileged application that only deals with interfacing with the user, then passes the action to pamd, which would run with the required privileges.
        throwaway09223 4y ago
        "Yes, and that "something" can be reduced to reads and writes to a socket." Yes, and as I said that is already what most PAM modules do. That is how most things work today. "I mean move all of PAM to a service." I think you don't understand what PAM is. "which will load a module, which will write to /etc/passwd" No, this isn't how PAM works at all. PAM modules don't write to /etc/password. They just authenticate. They do not (necessarily) need root privileges. "My suggestion would result in chsh becoming a completely unprivileged application that only deals with interfacing with the user, then passes the action to pamd, which would run with the required privileges. " You have the way PAM and chsh works entirely backwards. Here's how it actually works: 1) chsh runs as root only because chsh itself needs to modify system files. This has nothing to do with PAM, and is optional (see below) 2) chsh calls pam_auth("chsh",...) to authenticate the current user, if the current user isn't really root. This is PAM's ONLY involvement. 3) chsh then directly edits /etc/passwd itself[1]. Totally unrelated to PAM. If you're on a system with directory services instead of local files, then chsh needs to change those directory services instead (and, as such, doesn't need to run as root - though it will need to authenticate to the directory service) In summary, your ideas aren't bad - it's just that they're how things already work. Most PAM modules are already just talking to a socket somewhere. They don't do the other things you seem to think they do. [1] https://github.com/mmalecki/util-linux/blob/master/login-utils/setpwnam.c#L27-L30 https://github.com/mmalecki/util-linux/blob/master/login-uti...
  - _8j50 4y ago
    Don't give them ideas, some take systemd-unikernel very seriously.
  - yjftsjthsd-h 4y ago
    Merely another part of the complete systemd/Linux operating system? ;)
    - mindcrime 4y ago
      I think you mean GNU/systemd!
- GekkePrutser 4y ago
  Aren't you re-inventing the SAML / OAuth wheel here? After all, running authentication as a service is precisely what an IDP does. But interesting option to bundle a micro IDP with the OS. Probably would make a lot of security sense and every app using it would automatically work with a real IDP easily.
- OJFord 4y ago
  I suppose it's sort of described by 'good opportunity for updating the API' - but my #1 reason would be 'you (need to) know systemd config anyway, so lets use it instead of a different thing'.
  - _8j50 4y ago
    Learn more or depend more? To each his own if you all weren't forcing this on distros.
    - OJFord 4y ago
      I'm not the one doing any forcing, I use Arch (btw) which yes does somewhat default to/most people use systemd, and I happen to like it, but you don't have to. I'm not saying PAM should disappear entirely and nobody should be allowed to use it, I'm saying as someone who happily uses systemd I wouldn't mind/would quite like similar functionality to be part of systemd, and I could stop using PAM. But if you feel you're forced to use systemd I'm not even saying you should have to use this hypothetical part of it - just like boot, networkd, homed, etc. don't have to be used just because you're using systemd at all.
      - xena 4y ago
        I think their point is that if it's in the default configuration of Ubuntu or red hat, it's "shoved down their throat" because it is on by default and they assume they are made to care about it.
        _8j50 4y ago
        No, if it is the only option on every mainstream distro and if I have to keep switching distros because they cave in to the bullshit that I cann "shoved down my throat"
      - _8j50 4y ago
        I don't even hate systemd but like it, will distro maintainers opt to support "systemd pam" alongside old pam or will they discard it? I use systemd more than when I don't but only because it was forced. I can't use devuan and gentoo everywhere. That's why I prefer fixing/updating pam with a backward compatible replacement so maintenance burden is minimized and everyone is happy. The problem is, lennart and the systemd folks are not happy with systemd being popular, they want to decimate any competition.
- _8j50 4y ago
  No. Talk about adding vomit to faeces. > You can completely isolate it from anything else. Lock it into a sandbox. Use SELinux to ensure it doesn't do anything weird. You don't need systemd for that, as it stands not having a running process means no need for a sandbox. You created the problem you are solving. Even if it needed a standalone process you don't need systemd to sandbox it. > Much more secure -- you have a very narrow communication channel, and no exposure to stuff like LD_PRELOAD. Fix the root cause: LD_PRELOAD. > You avoid the mess of the above for the applications using it. Apps using PAM execute PAM code, and that means that anything that uses PAM needs to be able to do any arbitrary thing a PAM module might want to do. Ok you lost me here. Any reason a new PAM can't have solid api boundaries and capability restrictions? > Applications using PAM no longer need to have root access. Your screensaver/lock screen can be completely unprivileged. You should always drop privilege after getting whatever handle you need anyways but this is would be great but my wish would be to have specific linux capabilities to solve this if they don't exist already. > If it can be an UNIX socket, it probably can also be a TCP socket, so you can have it run remotely if such a thing makes sense. TCP adds a magnitude of complexity, people leaving PAM exposed to the internet would be a thing. You expanded PAM to also solve SSH (which uses PAM now lol)? > The protocol can be inspected Uhhh... gdb? > Good opportunity for updating the API and fixing anything lacking. And breaking all sorts of compatibility, adding all kinds of complexity and forcing many users to forcibly pull out all the hair on their heads in frustration. "I can't login because of newpam, let me tcpdump it, decrypt it and see if it is iptables, routing issues, dns issues, app config; nope all of that is good it must me the remote end" Not very fun on top of already complex AAA policy definitions you will need. Complex solutions are bad solutions, simple solutions are ideal solutions. I think you know that but perhaps what you know and are comfortable with seems simple to you? That said I think Windows' modern VBS lsass is a good role model if it goes this way.
  - throwaway09223 4y ago
    I agree with your post but I wanted to chime in that LD_PRELOAD isn't even a problem in this scenario! If you're running code as you then the permissions model assumes you can modify/control it. Always. Whether by LD_PRELOAD, or by a debugging interface such as ptrace(2). Or just by copying the binary, modifying it and running that instead. We already disable things like LD_PRELOAD or ptrace(2) for setuid scenarios, so again there's no issue. > "You should always drop privilege after getting whatever handle you need" Wanted to chime in here too. PAM doesn't require root -- the initial assumption is wrong. You can't just drop privileges in a PAM module though, because it's a function running in the application proper so any process-global state change would impact the calling process. What you can do (and what some PAM modules I've written actually do) when invoked as root is you can seteuid() to a non-root user as long as you're sure to seteuid(0) back to root before returning from your module. > "TCP adds a magnitude of complexity" Erm, so most PAM modules already do this. This is how pam_ldap, pam_kerberos, etc all work. No big deal. But it also doesn't need to be changed. Honestly, there is a real need for a service for updating local directory files like /etc/passwd. It's very stupid that we have individual binaries with ad-hoc C code editing /etc/passwd in 2022. But the right solution is something generic and modular more akin to a local ldap instance -- not reinventing the wheel with friggin' systemd.
- nn3 4y ago
  >* You can completely isolate it from anything else. Lock it into a sandbox. Use >SELinux to ensure it doesn't do anything weird. But the whole point of the plugins is to do weird things. Otherwise it could just use the defaults.
marcosdumay 4y ago
While it is technically the obvious way to go, I just can't wait for the first time the systemd-pamd decides that no, it is working on the correct way, and every linux user that decided to upgrade to the last release-marked version should have ported all of their userland first to deal with the non-communicated change, not being able to log on their machines is their fault.
- cptnapalm 4y ago
  Systemd-pamd failed with exit code "exit-code".
throw7 4y ago
Isn't that SSSD? I don't know myself... just asking because sssd is a... daemon... or at least nominally one?
lukeh 4y ago
Actually, the Windows LSA architecture - where both verification of initial credentials (PAM) as well as network authentication (GSS) are remoted via IPC to a daemon - has a lot of nice properties. I believe sssd does something similar on Red Hat Linux.
throwaway09223 4y ago
Actually the replacement for PAM is just ... regular software modules. "Implementing in systemd" would simply be making it non-modular. I'll explain: The P in PAM stands for pluggable - as in, you can change the authentication modules your software is using without recompiling. You can configure sudo to authenticate against ssh_agent, against kerberos, against LDAP, and if systemd had an auth system it could talk to it too. You can also read and write passwords directly from the terminal, if one exists. To "reimplement in systemd" would simply be to junk the Pluggable and Modularity aspects. You're left with a non-pluggable, single-use client library that talks to systemd. The interface would necessarily be limited, which has both good and bad aspects. It would also always be possible to write a PAM plugin to talk to the same mechanism, but in a pluggable and modular fashion! Anyway, this has been done a number of times already, such as with sssd. There of course isn't any need to make it part of systemd directly.

I think that this is seriously a great idea. PAM should be a service that communicates over an UNIX socket. Upsides: * You can completely isolate it from anything else. Lock it into a sandbox. Use SELinux to ensure it doesn't do anything weird. * Much more secure -- you have a very narrow communication channel, and no exposure to stuff like LD_PRELOAD. * You avoid the mess of the above for the applications using it. Apps using PAM execute PAM code, and that means that anything that uses PAM needs to be able to do any arbitrary thing a PAM module might want to do. * Applications using PAM no longer need to have root access. Your screensaver/lock screen can be completely unprivileged. * If it can be an UNIX socket, it probably can also be a TCP socket, so you can have it run remotely if such a thing makes sense. * The protocol can be inspected * Good opportunity for updating the API and fixing anything lacking.

krnlpnc 4y ago
Let’s move the linux kernel and sshd into systemd while we’re at it
- smitty1e 4y ago
  See your kernel; raise you the whole data center.
- dale_glass 4y ago
  You're joking, but I'm 100% serious. PAM is crusty and has a bad architecture. The fact that it's written in C, and is linked into another program as a library makes it impossible to fully isolate it from its host application, and exposes it to a myriad possible exploit points. Even wrapper binaries are not a great idea because of how UNIX works. fork() + exec() means the executed binary inherits a lot of state from the caller. Open files, signals, environment variables, chroot, mlock, resource limits, seccomp... there's a myriad of mechanisms that an executed binary can be exposed to, and even if it somehow perfectly takes all of them into account and defends itself against any possible malicious manipulation, the next kernel version could add a new one. That's why I think a sane, modern version of PAM should be a service and only communicate via a UNIX socket. That way you vastly reduce the attack surface, and allow locking up the PAM bits into their own, well defended box.
  - salawat 4y ago
    You should look into GNU Hurd then. I'm being serious, as exactly what you're describing sounds an awful lot like their micro-kernel approach. At least as of the last time I looked into it.
  - throwaway09223 4y ago
    "The fact that it's written in C" The calling convention is C, but you can write PAM in any language. "and is linked into another program as a library makes it impossible to fully isolate it from its host application" Huh? You can never isolate the client side code. You will always have something in your app. "I think a sane, modern version of PAM should be a service and only communicate via a UNIX socket." So, write a module that talks to a socket. That's how like half of the PAM modules already operate. You will always have to have code in the application to talk to whatever oracle you're using. What you're describing here isn't any different from how PAM already works.
    - dale_glass 4y ago
      > Huh? You can never isolate the client side code. You will always have something in your app. Yes, and that "something" can be reduced to reads and writes to a socket. > So, write a module that talks to a socket. That's how like half of the PAM modules already operate. I mean move all of PAM to a service. So for instance currently chsh is a setuid application because it needs to be able to write to /etc/passwd. This is a requirement because the way it works is that it links to libpam, which will load a module, which will write to /etc/passwd, all inside the 'chsh' program. My suggestion would result in chsh becoming a completely unprivileged application that only deals with interfacing with the user, then passes the action to pamd, which would run with the required privileges.
      - throwaway09223 4y ago
        "Yes, and that "something" can be reduced to reads and writes to a socket." Yes, and as I said that is already what most PAM modules do. That is how most things work today. "I mean move all of PAM to a service." I think you don't understand what PAM is. "which will load a module, which will write to /etc/passwd" No, this isn't how PAM works at all. PAM modules don't write to /etc/password. They just authenticate. They do not (necessarily) need root privileges. "My suggestion would result in chsh becoming a completely unprivileged application that only deals with interfacing with the user, then passes the action to pamd, which would run with the required privileges. " You have the way PAM and chsh works entirely backwards. Here's how it actually works: 1) chsh runs as root only because chsh itself needs to modify system files. This has nothing to do with PAM, and is optional (see below) 2) chsh calls pam_auth("chsh",...) to authenticate the current user, if the current user isn't really root. This is PAM's ONLY involvement. 3) chsh then directly edits /etc/passwd itself[1]. Totally unrelated to PAM. If you're on a system with directory services instead of local files, then chsh needs to change those directory services instead (and, as such, doesn't need to run as root - though it will need to authenticate to the directory service) In summary, your ideas aren't bad - it's just that they're how things already work. Most PAM modules are already just talking to a socket somewhere. They don't do the other things you seem to think they do. [1] https://github.com/mmalecki/util-linux/blob/master/login-utils/setpwnam.c#L27-L30 https://github.com/mmalecki/util-linux/blob/master/login-uti...
- _8j50 4y ago
  Don't give them ideas, some take systemd-unikernel very seriously.
- yjftsjthsd-h 4y ago
  Merely another part of the complete systemd/Linux operating system? ;)
  - mindcrime 4y ago
    I think you mean GNU/systemd!
GekkePrutser 4y ago
Aren't you re-inventing the SAML / OAuth wheel here? After all, running authentication as a service is precisely what an IDP does. But interesting option to bundle a micro IDP with the OS. Probably would make a lot of security sense and every app using it would automatically work with a real IDP easily.
OJFord 4y ago
I suppose it's sort of described by 'good opportunity for updating the API' - but my #1 reason would be 'you (need to) know systemd config anyway, so lets use it instead of a different thing'.
- _8j50 4y ago
  Learn more or depend more? To each his own if you all weren't forcing this on distros.
  - OJFord 4y ago
    I'm not the one doing any forcing, I use Arch (btw) which yes does somewhat default to/most people use systemd, and I happen to like it, but you don't have to. I'm not saying PAM should disappear entirely and nobody should be allowed to use it, I'm saying as someone who happily uses systemd I wouldn't mind/would quite like similar functionality to be part of systemd, and I could stop using PAM. But if you feel you're forced to use systemd I'm not even saying you should have to use this hypothetical part of it - just like boot, networkd, homed, etc. don't have to be used just because you're using systemd at all.
    - xena 4y ago
      I think their point is that if it's in the default configuration of Ubuntu or red hat, it's "shoved down their throat" because it is on by default and they assume they are made to care about it.
      - _8j50 4y ago
        No, if it is the only option on every mainstream distro and if I have to keep switching distros because they cave in to the bullshit that I cann "shoved down my throat"
    - _8j50 4y ago
      I don't even hate systemd but like it, will distro maintainers opt to support "systemd pam" alongside old pam or will they discard it? I use systemd more than when I don't but only because it was forced. I can't use devuan and gentoo everywhere. That's why I prefer fixing/updating pam with a backward compatible replacement so maintenance burden is minimized and everyone is happy. The problem is, lennart and the systemd folks are not happy with systemd being popular, they want to decimate any competition.
_8j50 4y ago
No. Talk about adding vomit to faeces. > You can completely isolate it from anything else. Lock it into a sandbox. Use SELinux to ensure it doesn't do anything weird. You don't need systemd for that, as it stands not having a running process means no need for a sandbox. You created the problem you are solving. Even if it needed a standalone process you don't need systemd to sandbox it. > Much more secure -- you have a very narrow communication channel, and no exposure to stuff like LD_PRELOAD. Fix the root cause: LD_PRELOAD. > You avoid the mess of the above for the applications using it. Apps using PAM execute PAM code, and that means that anything that uses PAM needs to be able to do any arbitrary thing a PAM module might want to do. Ok you lost me here. Any reason a new PAM can't have solid api boundaries and capability restrictions? > Applications using PAM no longer need to have root access. Your screensaver/lock screen can be completely unprivileged. You should always drop privilege after getting whatever handle you need anyways but this is would be great but my wish would be to have specific linux capabilities to solve this if they don't exist already. > If it can be an UNIX socket, it probably can also be a TCP socket, so you can have it run remotely if such a thing makes sense. TCP adds a magnitude of complexity, people leaving PAM exposed to the internet would be a thing. You expanded PAM to also solve SSH (which uses PAM now lol)? > The protocol can be inspected Uhhh... gdb? > Good opportunity for updating the API and fixing anything lacking. And breaking all sorts of compatibility, adding all kinds of complexity and forcing many users to forcibly pull out all the hair on their heads in frustration. "I can't login because of newpam, let me tcpdump it, decrypt it and see if it is iptables, routing issues, dns issues, app config; nope all of that is good it must me the remote end" Not very fun on top of already complex AAA policy definitions you will need. Complex solutions are bad solutions, simple solutions are ideal solutions. I think you know that but perhaps what you know and are comfortable with seems simple to you? That said I think Windows' modern VBS lsass is a good role model if it goes this way.
- throwaway09223 4y ago
  I agree with your post but I wanted to chime in that LD_PRELOAD isn't even a problem in this scenario! If you're running code as you then the permissions model assumes you can modify/control it. Always. Whether by LD_PRELOAD, or by a debugging interface such as ptrace(2). Or just by copying the binary, modifying it and running that instead. We already disable things like LD_PRELOAD or ptrace(2) for setuid scenarios, so again there's no issue. > "You should always drop privilege after getting whatever handle you need" Wanted to chime in here too. PAM doesn't require root -- the initial assumption is wrong. You can't just drop privileges in a PAM module though, because it's a function running in the application proper so any process-global state change would impact the calling process. What you can do (and what some PAM modules I've written actually do) when invoked as root is you can seteuid() to a non-root user as long as you're sure to seteuid(0) back to root before returning from your module. > "TCP adds a magnitude of complexity" Erm, so most PAM modules already do this. This is how pam_ldap, pam_kerberos, etc all work. No big deal. But it also doesn't need to be changed. Honestly, there is a real need for a service for updating local directory files like /etc/passwd. It's very stupid that we have individual binaries with ad-hoc C code editing /etc/passwd in 2022. But the right solution is something generic and modular more akin to a local ldap instance -- not reinventing the wheel with friggin' systemd.
nn3 4y ago
>* You can completely isolate it from anything else. Lock it into a sandbox. Use >SELinux to ensure it doesn't do anything weird. But the whole point of the plugins is to do weird things. Otherwise it could just use the defaults.

marcosdumay 4y ago

While it is technically the obvious way to go, I just can't wait for the first time the systemd-pamd decides that no, it is working on the correct way, and every linux user that decided to upgrade to the last release-marked version should have ported all of their userland first to deal with the non-communicated change, not being able to log on their machines is their fault.

cptnapalm 4y ago
Systemd-pamd failed with exit code "exit-code".

throw7 4y ago

Isn't that SSSD? I don't know myself... just asking because sssd is a... daemon... or at least nominally one?

lukeh 4y ago

Actually, the Windows LSA architecture - where both verification of initial credentials (PAM) as well as network authentication (GSS) are remoted via IPC to a daemon - has a lot of nice properties. I believe sssd does something similar on Red Hat Linux.

throwaway09223 4y ago

Actually the replacement for PAM is just ... regular software modules. "Implementing in systemd" would simply be making it non-modular. I'll explain: The P in PAM stands for pluggable - as in, you can change the authentication modules your software is using without recompiling. You can configure sudo to authenticate against ssh_agent, against kerberos, against LDAP, and if systemd had an auth system it could talk to it too. You can also read and write passwords directly from the terminal, if one exists. To "reimplement in systemd" would simply be to junk the Pluggable and Modularity aspects. You're left with a non-pluggable, single-use client library that talks to systemd. The interface would necessarily be limited, which has both good and bad aspects. It would also always be possible to write a PAM plugin to talk to the same mechanism, but in a pluggable and modular fashion! Anyway, this has been done a number of times already, such as with sssd. There of course isn't any need to make it part of systemd directly.