Something I belatedly realized: enforcement of trusted path execution can in fact be realized with AppArmor; albeit in a somewhat kludgy way, using profile inheritance on the window manager or desktop session. e.g. say you're logging into a Fluxbox desktop. You could then have a profile like this Code: #include <tunables/global> /usr/bin/fluxbox { network, # network clients will not work otherwise signal, # needed to allow suspend/terminate of processes, etc. dbus, # so programs using dbus can interact with each other # Note: Ux means unrestricted exec, but scrub the environment first. # setuid stuff shipping with Linux is presumably secure enough, but who knows... /usr/bin/sudo rUx, # obviously needed if you want to elevate to root in terminal windows /usr/bin/pmount rUx, # needed in my case because I use pmount instead of udisks # Use DAC for filesystem read/write permissions # One could of course experiment with further general restrictions here... /** rw, # Allow executables from root-owned system paths only /usr/** rix, /bin/* rix, /sbin/* rix, } To emulate GrSec's addition of user-owned files to the trusted path, you could put in this line: Code: owner /home/** rix, Problem of course is that this only applies to desktop logins under a particular window manager... Really, it would probably be better applied as a profile for XDM/LightDM/etc. In any case a console login will bypass it. But anything launched from Fluxbox, or from child processes thereof, will inherit the restrictions. The only exceptions are sudo and pmount, which are explicitly given unrestricted exec perms (with a scrubbed environment). .. Also, the console login will only be able to bypass it locally, from the physical machine. This is because what isn't in the profile is as important as what is listed: Code: proteus@harvest-lore:~$ ps auxx | grep firefox proteus 3407 10.0 3.5 959320 270896 ? Ssl 12:54 1:23 /usr/lib/firefox/firefox --no-remote --ProfileManager ... proteus@harvest-lore:~$ strace -c -p 3407 strace: test_ptrace_setoptions_for_all: PTRACE_TRACEME doesn't work: Permission denied strace: test_ptrace_setoptions_for_all: unexpected exit status 1 The inherited AppArmor profile blocks ptrace, too. So ptrace cannot be used to coopt processes outside of the restricted desktop session. Further Thoughts - Obviously this is not as protective for individual programs as a program-specific sandboxing profile; it's more a general system policy thing. Note that I'm thinking especially of keeping a lid on user hijinks, on multiuser Linux workstations. (Especially the exclusive root/owner execute thing.) Though, for a multiuser situation, the profile would definitely have to be applied to the login manager. - I'm not certain, but I suspect calls to dbus might be abused to control other processes from the original compromised process. It might be worth looking into further restrictions on dbus communication. - I would not lump any of this under "high security policy", more just "sensible default policy." Users only being allowed to execute stuff owned by themselves or root, for instance, seems like a bit of a no-brainer to me; as does whitelisting of setuid/setgid functionality. - As noted a above, "general policy" profiles would probably best be applied to the login manager. Or, maybe better yet, to the system POSIX shell. The latter would probably be quite reasonable when combined with unrestricted/scrubbed exec on sudo, as above. Edit: hmm, maybe not the POSIX shell. The login manager systemd-logind might actually be a better candidate, I think.
Interesting! I think I have to test this approach with the Debian system I'm running in Virtualbox. FWIW, you might be interested in the AppArmor policy presented here.