Mandatory access control, how to not make it broken on desktops.

Discussion in 'other security issues & news' started by Gullible Jones, Sep 8, 2015.

  1. Gullible Jones

    Gullible Jones Registered Member

    May 16, 2013
    I'm going to submit a bunch of opinions here.

    1. Restricting arbitrary desktop applications should never, ever require root privileges.

    2. Removing privileges from a program should be one-directional. A limited user should be able to *easily* revoke rights from a running program, but never add them back.

    3. Any arbitrary desktop application should be trivial to restrict, in terms of filesystem access.

    4. Furthermore, it should be easy to set up *default* restrictions for applications, based on root-owned config files. Users should be able to hierarchically apply further restrictions, but not remove them.

    5. And even further: it should be possible to have a reasonable default profile for ALL arbitrary X11 applications, that at a minimum allows it to function.

    Linux currently offers MAC via a bunch of LSMs (ignoring the various kernel patchsets for the moment.)

    AFAIK, every single on of those implementations fails every single one of the above criteria.


    What's my ideal? Ignoring GUI level isolation stuff, I'm basically thinking of something like a limited-user version of chroot.

    Say you have a binary called, oh, "firefox." On first launch, a directory $HOME/firefox is created. Firefox now treats this as $HOME, and creates all its config stuff there. The real $HOME becomes inaccessible to it, and all its child processes.

    Now say you have anothe program, "vlc". On first launch, the $HOME/vlc dir is created, and VLC treats that as *its* home. Likewise its child processes.

    Now say you download an MP3 in Firefox, and you want to play it in VLC...

    The file manager (say, Thunar) is preconfigured with a profile that lets it access the whole home dir. You can further *restrict* it if you want, but you cannot lessen those restrictions as limited user. So, per default, you can just drag and drop the file from $HOME/firefox to $HOME/vlc, and then double-click to open it. VLC will see it that way.


    Is there a technical term for this? I don't know. It seems to me a little like meta-discretionary access control, perhaps; i.e. discretionary control *of* mandatory access control. Kind of like being able to set niceness or ulimit values, except for filesystem read/write/execute permissions.

    In any case, ping
    @Hungry Man
    because I want some technical feedback on this...
  2. summerheat

    summerheat Registered Member

    May 16, 2015
    Isn't what is said in this post in the Firejail thread basically what you are looking for? (I've never tried it myself bot others obviously have.)
  3. Gullible Jones

    Gullible Jones Registered Member

    May 16, 2013
    @summerheat thanks!

    Edit: not exactly what I'm looking for (in terms of default settings and hierarchical one-way limits) but close, I think.

    Edit 2: I guess part of my point is, this stuff should be default. Not "available by default", not "set and forget", but *transparently set up out of the box*.
    Last edited: Sep 8, 2015
  4. Hungry Man

    Hungry Man Registered Member

    May 11, 2011
    Maybe, but consider the disaster that is userland namespaces in the Linux kernel. Moving the ability to create namespaces has been a consistent source of local privilege escalation vulnerabilities.

    Certainly. If there's ever a requirement to add a new privilege the 'job' should be handled by a separate process with that privilege.

    Perhaps ideally, but perhaps not. What if you have a security application and malware gains access to the system - providing that malware with the ability to restrict other processes, without rights, is dangerous. File system limitations are OK but not nearly powerful enough, given that systems are much more complicated than the fs.

    Yep, it should be. It sort of is, apparmor defaults are very often enough to at least get basic functionality out of a program.

    Isolating applications from each other within a user is difficult. What if Firefox wants to launch VLC to play a video you've just downloaded? You'll need some sort of broker process to make that decision.

    I came up with what I think is a solid design for this problem a long time ago but never implemented it because:

    1) Windows kernel programming is annoying
    2) Bromium came out a bit after and I expected them to do more than they have, though I've never been a fan of hardware virtualization for security
    3) Access control is a small picture. I would do it on Linux with LSM but I don't believe Linux provides what I need to get it working (ironically, Windows does).

    I'm confident that if it were implemented properly it would be quite powerful for the average user, but edge cases would be very annoying, and it relies heavily on the operating system and certificate system, neither of which I consider particularly robust.

    Because of that I have dozens of pages of docs, research, and snippets of kernel drivers lying around (I hope) and very little desire to push forward on it.
  5. Gullible Jones

    Gullible Jones Registered Member

    May 16, 2013
    True. :)

    I figured this would be, in part, a defense against privilege escalation via the same mechanism. If it's only one way... Of course, the devil is in the sordid little details of the implementation.

    Some things on that:

    1. This is why I specified the hierarchical design. My thought was, any process can remove privileges from a child process running as the same user, via a system call. (Err... kind of like how seccomp works I think.) But no chlid status and/or different user, then no. And no privileges can be added back except by superuser.

    2. Security applications => simple, you don't have them on a desktop. Userspace stuff should be strictly an arbiter, the kernel should manage all MAC. No setuid binaries should be involved. As for third-party "security" applications involving privileged binaries or services, well... My view of those is similar to yours.

    3. More generally, if a setuid program is succesfully attacked, you've lost everything anyway. The best one can do is to block arbitrary programs from accessing setuid stuff (which is one reason why you want MAC in the first place).

    4. As for X11, that's already being handled to some extent - the X server can now run as a dedicated user on several distros, due to kernel modesetting drivers (including an unaccelerated one for unsupported hardware). It can even run as the desktop user, though IIRC with the limitation of needing a console rather than a DM login.

    Wait, what defaults? Last I checked, AppArmor would not restrict anything without a profile for that specific executable, by path, no?

    (TomoyoLinux OTOH can do the whole-system-MAC thing, but is a royal pain to administer.)

    The correct way IMO is to prohibit Firefox from launching anything. Stuff should be launched from the file manager. :p But seriously, I think it's better to just eliminate the broker, and preclude that functionality. If a browser wants to do it and can't, that's not the operating system's problem; feature creep in a browser falls on the browser developers.

    ... Although I would also point out that, with AppArmor at least, you don't need a broker; the kernel decides it all, based on filesystem path. I mean, I would suppose that the actual files with text strings are converted into appropriate structs for kernel consumption by userspace utilities; but AFAIK the "brokerage" is all in kernel space.

    ... Oh wait N/M, I see what you're saying. Unprivileged user processes can't change the MAC settings because that would be dangerous, so you want a broker process to deal with it, with just the necessary privs. Kind of like how Android works, except with MAC instead of just abusing discretionary stuff. Got it.

    (And things get even more complicated when you use multiple Firefox profiles. Really Firefox should include its own sandbox of some sort, but I strongly dislike the idea of leaving sandboxing to userspace devs; even if the resulting sandbox is theoretically better. The operating system should enforce policy - to hell with UNIX ideals.)

    I feel like to some extent, relying on hardware implemented stuff may be better, because... well... physics. Better to etch the access control mechanism into silicon where it cannot be tampered with. That said I know zippo about hardware design... so.

    A lot of people seem to agree with you that LSM is inadequate. Not only GrSecurity, but also the developers of RSBAC and the original TOMOYO patchset.

    I'm not surprised about Windows in this case BTW; it's included structs related to MAC since at least Windows 2000, possibly NT 4 or earlier. However it's obscure stuff, nobody uses it except Google engineers, and more to the point, I don't trust the Windows kernel and its collections of deeply nested Matrioshka structs. This is the kernel that gave us null pointer derefs in window scrollbars, and renders Turing-complete font bytecode somewhere in its own Byzantine intestines. The ideas may be good - who am I kidding, it was originally headed by the guy behind DEC VMS - but the implementation seems godawful.

    Not like edge cases aren't a problem already, on every platform ever...

    Operating system though, yeah. Certificates likewise.

    Huh. I'd actually be interested in hearing about this, if you're ever willing to make it publicly available. Though admittedly I can't even hack Linux kernel coding yet; WinNT kernel stuff would be untenable for me.
  6. Hungry Man

    Hungry Man Registered Member

    May 11, 2011
    I'll consider writing about it at some point, perhaps, if I review it and decide I really won't ever implement it. Haven't decided exactly what I want to do with it yet. I have another project with a low barrier for entry and a simpler business model so I'm working on that in my free time... except that I barely have free time, mostly working on other things.

    Moving the decision from Firefox to the file manager won't change anything, as I see you've realized. After all, something has to run the file manager, what if the file manager wants to launch something? If you ever try sandboxing something like Unity you'll notice very quickly how useless it becomes.

    Most distros will provide a default #include for Apparmor profiles that contains home directories, fonts, libraries, etc. Any profile you generate will automatically include this.

    There will always be a few major issues:

    1) Backwards compatibility
    2) Getting devs to keep it in mind in the future (who owns these policies? Who gets called when something breaks?)
    3) Complexity in implementation - in modern operating systems things interact in weird ways, and generic policy generation is difficult
  7. Gullible Jones

    Gullible Jones Registered Member

    May 16, 2013
    Heh. I definitely sympathize re the free time; I have little enough myself at these days.

    My thought was, the file manager has the characteristic of being a desktop's major arbiter between files and the applications that read them. It should therefore "naturally" be the one desktop program that can do pretty much anything, within the limits of DAC.

    ... Until one notices that file managers can also do bad things. A good example of this is the Windows Explorer LNK vulnerability. I would bet Thunar et. al. have similar vulnerabilities lurking around, and if the file manager is the least protected program on the desktop, it will become the biggest target. Sigh.

    Hmm, interesting. How globally can one apply this though? I mean, I suppose one could get to the "bottom" of the desktop stack by restricting bash for limited users, but that would be a really tenuous sandbox, I would think.

    Less of a problem on Linux, I would think, where the norm for most software is source rather than binary compatibility, but yes. If it weren't for this little issue, things like object-capability security might be mainstream...

    Hmm. Adopt AppArmor utilities - or a seccomp broker, or whatever - as part of the systemd utility collection? It fits IMO. While I don't like all the design decisions in systemd, it does consolidate much of the Linux base system in one place; MAC would logically belong there too.

    Tell me about it. :( The more nightmarish aspects of my last job basically hinged on that.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.