Generalized AppArmor profiles for desktops and trusted path execution

Discussion in 'all things UNIX' started by Gullible Jones, Sep 10, 2015.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    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.
     
    Last edited: Sep 10, 2015
  2. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    729
    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.
     
Loading...