huh, wild: SELinux separates out the permission to run an executable file, and the permission for a process to have an executable file as its entrypoint.
-
huh, wild: SELinux separates out the permission to run an executable file, and the permission for a process to have an executable file as its entrypoint.
That means you can dictate what identities a program can run as (only identities with the 'entrypoint' permission), separately from the identities that are allowed to run the program.
-
@danderson Could this relate to .so shared libraries? They are ELF executable code too, but you probably wouldn’t want to jump straight into their entry point.
-
Dave Andersonreplied to Dave Anderson last edited by [email protected]
Combined with type transitions, you can for example set this up:
systemd has a "service manager" SELinux identity. It's allowed to execute /bin/sensitive. Upon execution, the SELinux policy automatically transitions the new deamon to a dedicated "sensitive service" identity. Only that identity has entrypoint privileges for /bin/sensitive. So, not only is systemd the only one allowed to start this daemon, but regardless of what systemd tries to do, the daemon can't run with unexpected privs.
-
@marshray My understanding is the deal is fairly simple, there's conceptually one check on either side of an execve() syscall: the identity invoking execve must have read+execute permission on the binary, and the identity that starts executing the program must have entrypoint permission on the binary.
.so could be excluded by either check, but it goes deeper in that you get to restrict "what programs get to use this identity and its permissions?" on a program-by-program basis.
-
P [email protected] shared this topic
-
@marshray And then "type transitions" happen between those two checks, conceptually at the atomic instant where the program calling execve() ceases to exist, and is replaced by the new program. That's where SELinux can knife-switch the process to a new identity, so that the pre- and post-exec permission checks happen under different identities.
I'm sure it's not broken down that way in actual code, but conceptually that's what happens iiuc.
-
@danderson I wonder if they know about busybox
-
@marshray In the most common uses of SELinux, anything users touch in interactive shells are broadly shoved into an "unconfined" universe and left to themselves. It's mostly system services that get the lockdown treatment.
I'm sure NSA internally have developed much more extensive policies that are all-seeing and much farther reaching, but out there in the real world the balance skews towards "lock down the scary network-exposed stuff but nerds would rebel if we nerfed their shells"
