5 ms·

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 deb

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!

_8j50 4y ago
The one item I still disagree on is with ptrace and LD_PRELOAD's permission being explicit. It is not, it is implicit just as you described because for both cases their permission is implied because of who owns the process and fs acls. On my Mac for example, I couldn't troubleshoot something in my browser process both as user and root with gdb because the browser's publisher didn't give gdb an explicit permission to debug it but it turns out the "builtin" lldb had permission so I was able to attach and debug. Implying things because ownership is what I am disagreing with. Basic unix acls give read,write or execute permissions, preloading a shared library or using ptrace to attach to a process is not explicitly defined in the acl, read and write apply to the file, not the process and execute can only be execve,clone,fork and related syscalls. In an ideal world, in addition to PKI/signatures, ELF headers would contain explicit permissions like this. So, for example, htop/top would disallow LD_PRELOAD and the kernel/LSM would police against permission header tampering without root or LSM-specific credentials even by the owner (ideally not root). This would make a lot of usermode rootkits useless (forcing them to use other means of course). Execute acl only defines the permission to start the program not what others can do to the program during its runtime.
- throwaway09223 4y ago
  I understand your reasoning, but I still disagree. I'll add a bit more information as to why: > " It is not, it is implicit just as you described because for both cases their permission is implied because of who owns the process and fs acls. On my Mac for example, I couldn't troubleshoot something in my browser process both as user and root with gdb because the browser's publisher didn't give gdb an explicit permission to debug it but it turns out the "builtin" lldb had permission so I was able to attach and debug." You're just describing extra permissions in osx - I believe related to code signing. Any system can introduce additional privilege checks (linux has yama/ptrace_scope), but this doesn't change the underlying permissions model. Furthermore, the permission is absolutely implied and this can be directly demonstrated on linux: You can simply open up /proc/$pid/mem and read/write values into the process's memory. This is sufficient to do anything. All memory can be read from and written to (provided the pages are writeable). > "preloading a shared library or using ptrace to attach to a process is not explicitly defined in the acl" It is. Specifically: The executable handler for /bin/ls will be (on my system) /lib64/ld-linux-x86-64.so.2. The explicit ACL is the execute bit on /lib64/ld-linux-x86-64.so.2 (to run that linker with all its options) and the executable /bin/ls (the invoking file). There are also permission checks on all the libraries which will be linked. You can test this by copying the linker: cp /lib64/ld-linux-x86-64.so.2 /tmp/mylinker and then if you like, modifying it and running it explicitly: /tmp/linker /bin/ls There are explicit permission checks on all of these things -- they're just generally set to be accessible by everyone. Users can also compile their own linkers and execute system binaries however they wish -- it does not matter. The permission is to run code -- any code. > "read and write apply to the file, not the process" As I mentioned above, this is explicitly not true. Memory pages on linux are represented as a flat file and they have standard unix permissions allowing the user to read their own memory in their own processes. This is also true of a process's file descriptors, including ephemeral descriptors such as pipes, sockets, and what have you. It's all accessible using basic filesystem syscalls like open(), seek(), read(), write(). > "In an ideal world, in addition to PKI/signatures, ELF headers would contain explicit permissions like this." There are indeed ways to do this but- > "So, for example, htop/top would disallow LD_PRELOAD " No! Why? There is no reason for this. It's not a security feature and it cannot serve a useful purpose. Anything you might do with LD_ vars and top you could do equally well by just copying and editing top. > "and the kernel/LSM would police against permission header tampering without root or LSM-specific credentials even by the owner (ideally not root)" These are features that you would use for a locked down device, but these types of features have no use on a development workstation where users are allowed to write code. > "This would make a lot of usermode rootkits useless (forcing them to use other means of course). Execute acl only defines the permission to start the program not what others can do to the program during its runtime." I think you're describing how to lock down an appliance. I'm talking about a development workstation.

_8j50 4y ago

The one item I still disagree on is with ptrace and LD_PRELOAD's permission being explicit. It is not, it is implicit just as you described because for both cases their permission is implied because of who owns the process and fs acls. On my Mac for example, I couldn't troubleshoot something in my browser process both as user and root with gdb because the browser's publisher didn't give gdb an explicit permission to debug it but it turns out the "builtin" lldb had permission so I was able to attach and debug. Implying things because ownership is what I am disagreing with. Basic unix acls give read,write or execute permissions, preloading a shared library or using ptrace to attach to a process is not explicitly defined in the acl, read and write apply to the file, not the process and execute can only be execve,clone,fork and related syscalls. In an ideal world, in addition to PKI/signatures, ELF headers would contain explicit permissions like this. So, for example, htop/top would disallow LD_PRELOAD and the kernel/LSM would police against permission header tampering without root or LSM-specific credentials even by the owner (ideally not root). This would make a lot of usermode rootkits useless (forcing them to use other means of course). Execute acl only defines the permission to start the program not what others can do to the program during its runtime.

throwaway09223 4y ago
I understand your reasoning, but I still disagree. I'll add a bit more information as to why: > " It is not, it is implicit just as you described because for both cases their permission is implied because of who owns the process and fs acls. On my Mac for example, I couldn't troubleshoot something in my browser process both as user and root with gdb because the browser's publisher didn't give gdb an explicit permission to debug it but it turns out the "builtin" lldb had permission so I was able to attach and debug." You're just describing extra permissions in osx - I believe related to code signing. Any system can introduce additional privilege checks (linux has yama/ptrace_scope), but this doesn't change the underlying permissions model. Furthermore, the permission is absolutely implied and this can be directly demonstrated on linux: You can simply open up /proc/$pid/mem and read/write values into the process's memory. This is sufficient to do anything. All memory can be read from and written to (provided the pages are writeable). > "preloading a shared library or using ptrace to attach to a process is not explicitly defined in the acl" It is. Specifically: The executable handler for /bin/ls will be (on my system) /lib64/ld-linux-x86-64.so.2. The explicit ACL is the execute bit on /lib64/ld-linux-x86-64.so.2 (to run that linker with all its options) and the executable /bin/ls (the invoking file). There are also permission checks on all the libraries which will be linked. You can test this by copying the linker: cp /lib64/ld-linux-x86-64.so.2 /tmp/mylinker and then if you like, modifying it and running it explicitly: /tmp/linker /bin/ls There are explicit permission checks on all of these things -- they're just generally set to be accessible by everyone. Users can also compile their own linkers and execute system binaries however they wish -- it does not matter. The permission is to run code -- any code. > "read and write apply to the file, not the process" As I mentioned above, this is explicitly not true. Memory pages on linux are represented as a flat file and they have standard unix permissions allowing the user to read their own memory in their own processes. This is also true of a process's file descriptors, including ephemeral descriptors such as pipes, sockets, and what have you. It's all accessible using basic filesystem syscalls like open(), seek(), read(), write(). > "In an ideal world, in addition to PKI/signatures, ELF headers would contain explicit permissions like this." There are indeed ways to do this but- > "So, for example, htop/top would disallow LD_PRELOAD " No! Why? There is no reason for this. It's not a security feature and it cannot serve a useful purpose. Anything you might do with LD_ vars and top you could do equally well by just copying and editing top. > "and the kernel/LSM would police against permission header tampering without root or LSM-specific credentials even by the owner (ideally not root)" These are features that you would use for a locked down device, but these types of features have no use on a development workstation where users are allowed to write code. > "This would make a lot of usermode rootkits useless (forcing them to use other means of course). Execute acl only defines the permission to start the program not what others can do to the program during its runtime." I think you're describing how to lock down an appliance. I'm talking about a development workstation.