5 ms·

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

by _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.
- _8j50 4y ago
  For most of what you said, you are right and I didn't know that, but that doesn't contradict my opposition to the original argument, you just have a better and more correct reasoning. That said, perimeter based security is dead, as in 2000's dead. There is no such thing as "if you control _____ we assume _____". No, unless explicit permission is granted by the thing controlling information, permission is denied. This could be accessing a file (basic unix acls will do) or connecting to a network service (e.g.: mtls). With LD_PRELOAD and ptrace() an explicit permissin isn't granted to the debugger by the specific debugee therfore regardless of who the user is or file acls permission must be denied. Even search order hjacking (I am only familiar with windows dlls not .so's for the record) is a vulnerability even if it is the same user running it because it can be used by threat actors for devious reasons. Especially global ld_preloading, that just has to go away. Find another way, look at macos!! > 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. Isn't that what I said by "drop privilege"? I've only used pam_exec so I never had to deal with this with pam but in general when I need root, I get whatever api handle, socket,etc.... and change uid/gid to a low-priv user. > 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. Yes, some PAM modules, that's why it is modular as opposed to the suggestion I wad disagreeing with which is having one process that does TCP and everything else you can think of and that's fine because sandbox. You can write simple pam modules or complex ones with TCP, custom protocol,etc... and that marvelous modular architecture is not faulty and should not be replaced by a giant complex systemd process.
  - throwaway09223 4y ago
    Right, we agree! I'm just adding some more information. > "With LD_PRELOAD and ptrace() an explicit permissin isn't granted to the debugger by the specific debugee therfore regardless of who the user is or file acls permission must be denied. " Explicit permission is in fact granted because they are running as the same user. There is a permission check on attaching gdb which is using ptrace(2). Regarding LD_PRELOAD or other linker instructions, again there is an explicit permissions check: In this case, the permission is the execute permission on the original binary. If you have permission to execute then you can set any linker parameter you wish, or even use a non-system provided linker! There's nothing stopping a user from compiling their own linker and using it to run a system binary, so long as it's running as them and not setuid as another user. > "Even search order hjacking is a vulnerability even if it is the same user running" It's not, and this kind of thinking is evidence of a faulty security model. Linker configuration is just one small aspect of invoking an executable. You can always simply copy and edit the executable instead, as I mentioned in my previous post. Or you can always use your own linker. Or bring your own statically linked binary, with no linking to system libraries at all. Looking for this kind of thing might be useful as a signal on an otherwise locked-down system (is development happening? Why?), but it has no place in a cohesive permissions model for a general-function workstation. It really cannot be a functional part of a well designed security architecture for a system which allows for software development. > "Isn't that what I said by "drop privilege"? I've only used pam_exec so I never had to deal with this with pam but in general when I need root, I get whatever api handle, socket,etc.... and change uid/gid to a low-priv user." Typically "dropping privileges" means setting the ruid (real uid), irrevocably becoming the lower-privilege user. This is the "grab a resource and give up access" model. This can't happen with PAM because it's a function not a separate process and it needs to return holding the same permission state it was called with. pam_exec would be forking and setting the uid in the child process prior to exec. In a single process scenario where a function must return with the process state unchanged, the euid (effective uid) can be set to a lower-privilege user. The ruid remains 0, so privileges aren't permanently dropped as they can be restored at any time with a subsequent seteuid(0) call. It's more a temporary lowering of privileges. This is not threadsafe, of course, as privilege is process-global state. > "and that marvelous modular architecture is not faulty and should not be replaced by a giant complex systemd process. " Agreed!

by _8j50 4y ago

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.

_8j50 4y ago
For most of what you said, you are right and I didn't know that, but that doesn't contradict my opposition to the original argument, you just have a better and more correct reasoning. That said, perimeter based security is dead, as in 2000's dead. There is no such thing as "if you control _____ we assume _____". No, unless explicit permission is granted by the thing controlling information, permission is denied. This could be accessing a file (basic unix acls will do) or connecting to a network service (e.g.: mtls). With LD_PRELOAD and ptrace() an explicit permissin isn't granted to the debugger by the specific debugee therfore regardless of who the user is or file acls permission must be denied. Even search order hjacking (I am only familiar with windows dlls not .so's for the record) is a vulnerability even if it is the same user running it because it can be used by threat actors for devious reasons. Especially global ld_preloading, that just has to go away. Find another way, look at macos!! > 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. Isn't that what I said by "drop privilege"? I've only used pam_exec so I never had to deal with this with pam but in general when I need root, I get whatever api handle, socket,etc.... and change uid/gid to a low-priv user. > 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. Yes, some PAM modules, that's why it is modular as opposed to the suggestion I wad disagreeing with which is having one process that does TCP and everything else you can think of and that's fine because sandbox. You can write simple pam modules or complex ones with TCP, custom protocol,etc... and that marvelous modular architecture is not faulty and should not be replaced by a giant complex systemd process.
- throwaway09223 4y ago
  Right, we agree! I'm just adding some more information. > "With LD_PRELOAD and ptrace() an explicit permissin isn't granted to the debugger by the specific debugee therfore regardless of who the user is or file acls permission must be denied. " Explicit permission is in fact granted because they are running as the same user. There is a permission check on attaching gdb which is using ptrace(2). Regarding LD_PRELOAD or other linker instructions, again there is an explicit permissions check: In this case, the permission is the execute permission on the original binary. If you have permission to execute then you can set any linker parameter you wish, or even use a non-system provided linker! There's nothing stopping a user from compiling their own linker and using it to run a system binary, so long as it's running as them and not setuid as another user. > "Even search order hjacking is a vulnerability even if it is the same user running" It's not, and this kind of thinking is evidence of a faulty security model. Linker configuration is just one small aspect of invoking an executable. You can always simply copy and edit the executable instead, as I mentioned in my previous post. Or you can always use your own linker. Or bring your own statically linked binary, with no linking to system libraries at all. Looking for this kind of thing might be useful as a signal on an otherwise locked-down system (is development happening? Why?), but it has no place in a cohesive permissions model for a general-function workstation. It really cannot be a functional part of a well designed security architecture for a system which allows for software development. > "Isn't that what I said by "drop privilege"? I've only used pam_exec so I never had to deal with this with pam but in general when I need root, I get whatever api handle, socket,etc.... and change uid/gid to a low-priv user." Typically "dropping privileges" means setting the ruid (real uid), irrevocably becoming the lower-privilege user. This is the "grab a resource and give up access" model. This can't happen with PAM because it's a function not a separate process and it needs to return holding the same permission state it was called with. pam_exec would be forking and setting the uid in the child process prior to exec. In a single process scenario where a function must return with the process state unchanged, the euid (effective uid) can be set to a lower-privilege user. The ruid remains 0, so privileges aren't permanently dropped as they can be restored at any time with a subsequent seteuid(0) call. It's more a temporary lowering of privileges. This is not threadsafe, of course, as privilege is process-global state. > "and that marvelous modular architecture is not faulty and should not be replaced by a giant complex systemd process. " Agreed!