Sandboxing the X server with AppArmor. Sane?

Discussion in 'all things UNIX' started by Gullible Jones, Jun 7, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    So on another computer forum I saw some references to AppArmor profiles for the Xorg setuid binary. Is this at all reasonable? AppArmor can restrict even root processes as long as they're not running in kernel mode, correct?

    Assuming the policies can be enforced at all, this actually does seem reasonable to me. Granted, someone who's hijacked the Xorg binary can probably sneak into any X11 client application, but if AppArmor makes that significantly harder it would still be useful.

    e.g. I believe Xorg doesn't actually have to launch anything directly, GUI applications are started separately as clients that communicate with it. And Xorg is not even multithreaded. So why allow the setuid binary to invoke fork or exec system calls? At least make it really annoying for an attacker to spawn a root shell.

    Likewise, there are a bunch of filesystem areas and devices that only client software should need access to, not Xorg itself, right? So why not block the X server from reading that stuff?

    On the other hand, the server can freely grab keystroke data and such from any client, and that is extremely hard to mitigate. So while not futile, even a working AppArmor profile for Xorg might not be as broadly effective as one would hope.

    I'm also interested in the possibility of sandboxing other setuid binaries. e.g. pmount does not need access to things like the screen device, audio devices, keyboard... And, again, it does not need to fork/exec anything.
     
  2. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    Very sane, and I think very hard .... I'd like to see many more standard profiles available that actually work before this....

    One of the big problems with AppArmor is that it takes too much individual work to get standard things to function out of the box. I know it's possible to tweak, but AppArmor's not going to go anywhere if those standard profiles are not available on the mainstream distros and they work.
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    In this case I think "hard" translates directly into "not sane." The X binary needs to be able to execute an unrestricted shell session too! So the answer unfortunately is that attempts to restrict X's permissions are not getting anywhere.

    Please consider my question answered. And be advised that, if you are running X with AppArmor restrictions, you are not getting any benefit from it.
     
  4. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    8,698
    No, completely unneeded.
    A recipe for disaster.
    Someone with a hijacked and whatnot ...
    Slow down. Make sure you don't get to that step, and that's it.
    The likelihood of you ending up with a bad binary on your host, LOW.
    Unless you try hard.
    Mrk
     
  5. tlu

    tlu Guest

    Besides, we'll have Wayland in the foreseeable future which is far better if it comes to security.
     
  6. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    And, while we're on the subject of alternatives, Qubes.
     
  7. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    While I appreciate the concept of Qubes, I think it has a bunch of failings.
    1. Effectively single-user, so only good for a home environment
    2. Xen + desktop running in dom0 = instant suckage
    3. It relies too much on the user deciding how to partition things

    I'd be more interested in seeing if something similar can be done with LXC and AppArmor, or some other less inherently complex setup. To my mind the most interesting thing about Qubes isn't the hardware virtualization based security, it's the trusted dom0 window manager that allows secure clipboard sharing and such under X11. I'd like to see that eventually ported to other more manageable security frameworks.

    That said, I don't have a hundredth of Rutkowska's expertise on security matters, so...
     
  8. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    8,698
    Let's be practical about this. Honestly, apart from some serious and fun hobbying, this is totally way, way above any reasonable threat landscape requirements. You're more likely to lose data and productivity due to security products than the would-be threats they are designed to protect from in the first place. I am not saying this out of malice, but it's like nuclear weapons. Relax.
    Mrk
     
  9. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    I'd really love to be able to have AppArmor working for a browser, email client and office suite out-of-the-box; the reality is that it is not. Perhaps I've been spoiled by Sandboxie.

    I do see a realistic threat landscape right now, for browsers and Flash, whether Windows or Linux, which AppArmor would help with. And I'm afraid that I don't think I can be vigilant enough at all times (nor are the people around me).

    Agree with the comments about Qubes, and love the concepts involved. It's doing stuff I already do with VMs manually but much better, and I quite like the ability to define your own domains, I think that reflects reality.

    I'll be very interested to see how the concepts could be built into the OS and window manager though - a built-in apparmor plus lightweight VM....
     
  10. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    The problem with pathname based access control is that people tend to have different requirements. It's hard to have an OotB configuration for AppArmor, for browsers and such, that's both secure and convenient. (You can see this with the old Firefox profile on Ubuntu, which basically let the browser do everything.

    That said, I can think of sane settings for a lot of applications. e.g. Right off the bat, programs like
    * Browsers
    * Media players
    * Office suites
    * PDF viewers
    Should never ever be allowed to execute a binary that isn't owned by root. IOW they should be specific targets for a Trusted Path Execution policy. AppArmor and such can do that very easily, without any incompatibility or inconvenience for the user.

    Note that by server standards this is extremely insecure (it gives full read-write access to your home folder!). But it does meet the bare minimum qualifications of "Don't let my applications run trojans, kthxbye." And on a desktop that's what counts 99% of the time.
     
  11. shuverisan

    shuverisan Registered Member

    Joined:
    Dec 23, 2011
    Posts:
    185
    This is something I've been thinking about lately. I've made a lot of custom Apparmor profiles for people across multiple distros and have considered uploading them to my site or submitting chunks to Git. The main reason I haven't is because...these are CUSTOM profiles. Desired or sometimes even basic functions work but some things don't. That's by design.

    The moment you take into account a bagillion different usage scenarios, the profile's security needs to be expanded (read: weakened) and you're diluting their purpose. The abstractions used in the out-of-the-box profiles, and many of the profiles themselves, are insufficient for hardened mandatory access control but when you've got 5+ different desktop environments to keep happy, what else can we expect? Profiles for some things like ping or netstat are decent enough as they are, but a browser or mail client profile written for all desktops will never compare to one specifically written for your needs on your hardware in your desktop environment of choice.

    This will always be Apparmor's biggest hurdle. One interim solution could be to have base abstractions tailored to the DE and OS architecture pulled in with apparmor-utils. That requires some rewriting and package reorganization but is nothing prohibitively difficult. It's at least a start to remove the pit of abstractions within abstractions, blanket library & driver access and unconfined & unisolated executions.
     
  12. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    Thanks - any working profiles are welcome, because most of the published ones are several years out of date. I guess I have the fond notion that for the very popular distros, the major app providers could ship working profiles that could then be further adapted to your particular requirements - that's me being lazy and naive.... For a lot of the apps, I think the useful stance is that either they are internet focussed and need minimal file-system access to allow them to run and persist, or they are filesystem focussed and should have minimal/no internet access. It's the rather convoluted and path-dependent aspects of the profiles that makes them harder to build, copy and maintain, and perhaps a form of abstraction compiler could be very useful for that.
     
  13. shuverisan

    shuverisan Registered Member

    Joined:
    Dec 23, 2011
    Posts:
    185
    What DE, architecture and programs are you interested in?
     
  14. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    My preference is LM17, or Ubuntu based. I haven't yet checked the ones that ship with Ubunutu 14.04. Primarily to cover FF and/or Chromium, Thunderbird, pdf viewer and Libre Office (IOW, anything exposed to material from the big bad world).
     
  15. shuverisan

    shuverisan Registered Member

    Joined:
    Dec 23, 2011
    Posts:
    185
    Didn't mean to leave you hanging but I started piling together some profiles for whoever wants them. Here are Firefox and Thunderbird made specifically for Mint 17 with Cinnamon. They're base profiles, meaning Some Assembly Required so you'll have to add in your own allowances for plugins, hardware and any subdirectories in /home that aren't part of necessary acces (~/Documents, etc). The logprof tool would be good enough for that but see the README for more info.

    I'm finishing something for Chromium (lots of changes there from 13.10 to 14.04) and I'll try to get a messenger program up over the next few days, Pidgin or maybe Empathy.

    http://thesimplecomputer.info/apparmor/
     
  16. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    Very grateful for any form of base set for these! Thank you.

    Chromium & Pidgin would also be welcome.
     
  17. shuverisan

    shuverisan Registered Member

    Joined:
    Dec 23, 2011
    Posts:
    185
    Added Chromium (need both files), Pidgin, Evince and an abstraction for printing from any of these programs. Also updated Firefox and TB. For what works and what doesn't, see the readme.
    http://thesimplecomputer.info/apparmor/
     
  18. tlu

    tlu Guest

    I would like to add that xorg-server 1.16 has landed in Arch Linux about 2 weeks ago. And it's no longer running as root process unless it's started by a display manager (like gdm or kdm). After disabling your DM you'll have no GUI at the end of the boot process anymore. Rather, you'll land in the default shell where you have to login (which is not very different from a DM). What is different, though: You have to execute startx either manually or automatically.

    Result: top shows Xorg.bin running as a user process. :)

    Code:
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    1240 tlu       19  -1  451944  59744  45100 S   0,3  0,7   0:43.63 Xorg.bin
    Have other distros also upgraded to the new version already?
     
Loading...
Thread Status:
Not open for further replies.