5 ms·

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 b

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
> I think you're describing how to lock down an appliance. I'm talking about a development workstation. No, any production system, even a dev workstation would have IDEs and browsers restricted but their new code or anything else theh need would be permitted. I suppose the entire non-LSMed Linux/Unix acl system is broken by modern standards. (Windows as well in many similar regards), a process being able to rwx its own memory makes sense. A separate process being able to rwx any process memory so long as the target process is owned by the same user violates principles of mandator access control because it isn't mandatory for arbitrary processes with no explicitly defined relationship to alter each others' memory. In essence if I could summarize this, the permissions model is not granular enough to apply on a per-process runtime basis. You can alter the memory anyways so who cares about preloading and ptrace? That has been the thinking all along but this thinking had not adapted to modern threats and mitigations. I suppose an LSM is the only option and I wouldn't suggest fixing the root cause here due to political impracticality but it would be nice if any desktop and server distro enforced MAC adequately and at least per-process and this shouldn't be considered locked down just normal. Modifying a file, usage of the glibc feature LD_PRELOAD, ptrace,etc... while write and executing while writing and executing a file somewhere in vfs can eventually allow that, these are distinct things,it shouldn't be left for the admin to figure out the implications, the implications should be explicit by design in an ideal world. If there is no explicit permission to specifically allow an operation that constitutes a security risk the OS should prevent that operation. You only described how badly broken things are. > 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. Yes but then the attacker would have to tamper with top (if some other security measure permits it) or use a kernel mode rootkit instead. Security controls address specific risks, in this case LD_PRELOAD is frequently abused by even the most trivial coinmining malware so that specific risk would be addressed as should any other risks in the best way possible. There is no way outside of an LSM for a developer to say "please don't permit preloading,ptrace, memory tampering unless it is this explicitly defined process because bad guys like to abuse these features against me, unless the user is explicitly warned about the dangers and permits the feature" In reality you can and people do this with selinux and the like wich are fairly cumbersome to manage by an admin (not end user). But allowing devs to declare specific risky features else defaulting to a deny would not be burdensome on devs, admins and it would make the effective security model and interface user friendly. The same thing can be said with windows process access, debug, thread/dll/code injection,etc.... these security models are outdated and user unfriendly. "If you get pwned, all bets are off" is not a good way to look st security these days.

_8j50 4y ago

> I think you're describing how to lock down an appliance. I'm talking about a development workstation. No, any production system, even a dev workstation would have IDEs and browsers restricted but their new code or anything else theh need would be permitted. I suppose the entire non-LSMed Linux/Unix acl system is broken by modern standards. (Windows as well in many similar regards), a process being able to rwx its own memory makes sense. A separate process being able to rwx any process memory so long as the target process is owned by the same user violates principles of mandator access control because it isn't mandatory for arbitrary processes with no explicitly defined relationship to alter each others' memory. In essence if I could summarize this, the permissions model is not granular enough to apply on a per-process runtime basis. You can alter the memory anyways so who cares about preloading and ptrace? That has been the thinking all along but this thinking had not adapted to modern threats and mitigations. I suppose an LSM is the only option and I wouldn't suggest fixing the root cause here due to political impracticality but it would be nice if any desktop and server distro enforced MAC adequately and at least per-process and this shouldn't be considered locked down just normal. Modifying a file, usage of the glibc feature LD_PRELOAD, ptrace,etc... while write and executing while writing and executing a file somewhere in vfs can eventually allow that, these are distinct things,it shouldn't be left for the admin to figure out the implications, the implications should be explicit by design in an ideal world. If there is no explicit permission to specifically allow an operation that constitutes a security risk the OS should prevent that operation. You only described how badly broken things are. > 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. Yes but then the attacker would have to tamper with top (if some other security measure permits it) or use a kernel mode rootkit instead. Security controls address specific risks, in this case LD_PRELOAD is frequently abused by even the most trivial coinmining malware so that specific risk would be addressed as should any other risks in the best way possible. There is no way outside of an LSM for a developer to say "please don't permit preloading,ptrace, memory tampering unless it is this explicitly defined process because bad guys like to abuse these features against me, unless the user is explicitly warned about the dangers and permits the feature" In reality you can and people do this with selinux and the like wich are fairly cumbersome to manage by an admin (not end user). But allowing devs to declare specific risky features else defaulting to a deny would not be burdensome on devs, admins and it would make the effective security model and interface user friendly. The same thing can be said with windows process access, debug, thread/dll/code injection,etc.... these security models are outdated and user unfriendly. "If you get pwned, all bets are off" is not a good way to look st security these days.