The case against MAC on the desktop

Now to play devil's advocate...

While I can see the value of mandatory access controls for system services and some desktop applications, it seems to me there's an issue of diminishing returns in a lot of desktop cases.

Take for example the office suite. OpenOffice has been exploited before, and no doubt will be exploited again in the future. The problem is, you can't really limit where it has read/write access to, because the whole point of it is to be able to read and write arbitrary document files. But if it can open arbitrary document files, it can also trash the nifty article you were writing, etc.

Alright, OOO is not a major attack vector (yet). Browsers are much bigger. But what if you use e.g. Google Docs? The browser being unable to read outside your Downloads folder could quickly make things painful.

(Same can even apply to IM clients, if you're sharing files over them.)

My point here is that even a pretty silent MAC system like AppArmor takes its toll on convenience. End users don't want to deal with that; heck, I don't want to deal with that. I want my computer to "just work." Following the principle of least privilege is actually kind of hard in practice.

[noparse]TLR[/noparse] I can see where the OpenBSD crowd is coming from when they say MAC is overrrated. Not because it isn't a good security measure, but because (perhaps) it's not really that applicable to desktop systems; at least not in the fine-grained forms implemented on Linux. Paradoxically, one might IMHO argue that Windows' HIPS are saner for desktop use, due to their lack of granularity.

Obviously I'm curious about opinions on this though. How relevant do you people think MAC is at this point? Is it a good approach on the desktop, or is it inconvenient enough to be a dead end in most cases?

P.S. I can see one way around these issues, but I'm not sure if it's ever been implemented: some kind of per-process policy sandbox, that ties one process to one file, and forces a separate process to launch for every new file. But that is a godawful kludge.

 

Thankfully you can do quite a lot.

For example, with office, we can determine the file types it has to access. Let's say it only needs read/ write access to .doc files - great:

/home/**.doc rw,

Now it can only read and write to doc files. You've just restricted it a fair amount.

Consider that with OO you'd also restrict its access to other programs, to various readable files, etc. You can restrict it quite a bit.

Again, with google docs we can do the same thing - give it read access to /home/** if you'd like, and where's the hole? The nice thing is you're stopping it from mapping, you're stopping it from reading other areas (outside of /home/), and you're stopping it from writing to other areas.

I agree though, the number one issue with MAC and compatibility. Ultimately, it's the best tool we have right now, but it won't be what 'the world' ends up turning to. There are newer technologies that'll be far more appropriate.

The OpenBSD crown isn't to be taken seriously BTW.

 

I'm curious: What are you referring to?

Otherwise I fully agree with what you said.

@GJ: There is always the need to weigh up security against convenience. On the other hand, that's not too difficult in the case of AppArmor as Hungry's examples show. Although I agree that it's probably still way too complex for the vast majority of users.

 

Various ideas like copy-on-write sandboxing (LXC-SELinux on Fedora project, similar to SandboxIE) come to mind. The benefit being a much more easy-going sandbox, without a significant loss to security, and only a minor hit to performance/ disk space.

 

Umm... With COW sandboxing, can't a compromised application read data that maybe it shouldn't?

 

The default is to allow reads, but you can still deny them explicitly. Without going into too much detail I would say automated policy generation with COW sandboxing will be the future, if there is any sense in the industry (there isn't). There are a few more tricks that would be necessary to get it working properly and securely.

 

Hmm, Windows already has UAC virtualization. I bet it wouldn't be too hard for Microsoft to add COW sandboxing.

 

There are big issues with that. With UAC virtualization it's not an issue, all programs share that virtualized area. It's not meant to be secure.

For a MAC you move to a per-application virtualization. A lot of problems start to arise from this - do you use path based rules? Then the sandbox has to account for that, or it'll be weak. Hash based? Huge inconvenience, why bother? Not unsolvable problems, and not problems that I can't see solutions to, but MS would have to put a fair amount of work into it.