What can and cannot be done with Linux ACLs

I'm kind of interested in what an end user can do with ACLs, for e.g. browser security. Would it be possible to set something up similar to Windows Vista/7 integrity levels? e.g.

- You want Firefox to have write permission only to ~/.mozilla and ~/Downloads. Is it possible to apply ACLs to those directories, and to the Firefox binary, such that Firefox can only write to them when run by your user?

- Going further: you want your email client to have read and write permissions to ~/Mail, ~/Downloads, and its configuration folder... And be unable to write to or read from anywhere else in your home directory. Possible? Impossible?

FWIW the equivalent on Windows would be setting the desired executable and the desired folder to mandatory low integrity - the executable could then only write to that folder. Are such things possible with ACLs and DAC, or is this something that can only be done through a full-blown MAC framework?

 

I am sure Hungry Man can answer this better than I but I will give it a shot.

From my understanding SeLinux/AppArmour/MACs are stronger than ACLs but are more aimed at sandboxing/isolating threats while the built in ACLs are more limited in their controls but are similar in what they can achieve. Basically you have much more fine tuned control with a full system like SeLinux.

Good article here: http://shebangme.blogspot.ca/2010/06/linux-kernel-security-selinux-vs.html

I may be missing something, hopefully some one else can post and let us know more. I mostly stick to SeLinux hardening.

 

The advantage of ACLs here is that all you need is a filesystem that supports them.

By the way, I think your link is wrong on a couple things. I know MAC systems generate some overhead - not as perceptible as from e.g. an antivirus, but servers feel the performance impact. Also, it's been a while since I used GrSec, but I recall it being almost impossible to get working - very poorly documented, and it made the X server, several daemons, and some important command line utilities inoperable by default. That was back in 2008 or thereabouts though, so I guess things may have changed...

 

edit:
https://insanitybit.wordpress.com/2012/08/01/creating-a-new-user-account-for-pidgin/

There's a guide for doing this with Pidgin. I'll get to setfacl tomorrow for allowing Pidgin to write to specific folders.

MAC systems are built into the kernel and they're very fast. There shouldn't be anything significant, especially if the program isn't violating the rules. Something like seccomp filters should have virtually no overhead except for violations as it only effects specific unused syscalls.

The ACLs work on a per-user basis. When you add a user you add a new ACL.

If you ran Firefox as its own user you could use the ACLs to allow it to only read to specific files in that users group.

Again, do the same thing for your mail program. Run it as a separate user.

You'd have to give it X11 access and then you'd give it access to the folders you like. This might get annoyingly complicated as Firefox will probably create user.firefox (or whatever) files in your user.GJones folders.

You can work around this.

http://www.linux-tutorial.info/modules.php?name=ManPage&sec=1&manpage=setfacl

You'd need to do something like:

setfacl -m u:user.firefox:rwx /path/whatever/
setfacl -dm u:user.firefox:rwx /path/whatever/
setfacl -m u:user.gjones:rwx /path/whatever/
setfacl -dm u:user.gjones:rwx /path/whatever/

Yes, but the executable would still have write access to anywhere that's low integrity.

You'd have to run it as untrusted, set any folders it needs to access to untrusted, and then restrict read access somehow (this would almost definitely break any program).

Anyways,

True but all you need for AppArmor is the Linux kernel... every Linux kernel should have support for it, the LSM framework is built in. I doubt any distro doesn't have SELinux (seriously, anything other than the ones that try to fit on floppies should) and most will have AppArmor.

There are benefits of running programs as a separate user though.

ACLs would have a performance impact just like AppArmor, both should be completely negligible.

The last 4 years has seen huge changes to Linux in general.

As for grsecurity it's easy and works fine. Once you get it configured the first time you just compile it and that's it. For me this takes about 30 minutes of it in the background (with -pipe and -j3).

Honestly, setting up grsecurity's gonna be a hell of a lot easier than trying to set up ACLs but you can do both.

I think I'll try setting Pidgin up in another user account actually and maybe I'll write a guide.

Too busy now but maybe Thursday. If I get it done I'll let you know.

edit:
https://grepular.com/Protecting_Your_GNU_Linux_System_from_Dropbox

lots of info in there btw

edit2: that was easy, I'll write a guide up.

 

Wow thanks.

Umm, re low integrity on Windows. Do you mean the program could write to any low-integrity area owned by the user running it? Or that it could write to any low-integrity area, period? If the latter, that's no better than UNIX DAC.

Edit: Hmm, I was hoping that ACLs would provide a way to avoid needing to create a new user; with that method one could probably use normal UNIX permissions to get similar results, I think.

 

I don't know the answer but I'm watching this thread with interest. I think you would end up breaking the applications if you achieved your goal, but I don't have any evidence at all to back that up.

This is 100% OT, but I am officially a Gullible Jones fan. I love the questions you ask. I wish there were a way for me to automatically subscribe to all your threads.

 

On Windows you have folders that are low integrity, medium integrity, high integrity. Any program of low integrity can read the entire file system (typically) and can write to all low integrity areas of the file system/ registry.

On Linux if I run a program as another user it can only read from its own user directory and globally readable areas.

The permissions are based on user groups so you need to use them.

 

Depends. If e.g. Firefox were unable to write to ~/.mozilla, I'm pretty sure it would break. Likewise for any program that needed to write to some config directory somewhere in ~/. But give them the minimal write permissions they need and they'll work fine. For Firefox IIRC that's write permissions to ~/.mozilla, /tmp, and wherever you download stuff to.

OTOH, I suspect that denying all access to most of your home folder, while at the same time allowing read-only access to necessary libraries, would be fiendishly hard with ACLs. That would be more of a job for a MAC framework.

(In fact, I have a vague idea of how to do it with Tomoyo - IIRC it's pretty easy.)

Thanks. I do try to ask useful questions.

Whoah. Are you sure about that? Absolutely 100% certain?

Because if Joe User's program running at low integrity can write to Jim User's low-integrity folder, that means integrity levels are completely broken for multi-user systems. And that doesn't make sense.

Not to be a jerk, but I would like to see a link to MSDN confirming that.

Unless both you and the new user are members of group X, and group X has read permissions on your home dir. UNIX permissions are powerful, but as susceptible to PEBKAC as anything else.

Edit:

Ah I see - no integrity levels (or equivalent) here.

The main problem I see with this approach is, again, making it usable on a multi-user system. If you have a bunch of users invoking Firefox as one sandbox user, they'll all have write access to each other's downloaded files, profile data, bookmarks, etc., which is not good.

 

Oh, sorry. No, the separate user account would probably work just like Linux - you can't access it.

Probably at least.

I have no idea why I wrote that in such a way that it sounded so blatantly like I was saying otherwise. Not thinking haha

Sure.

I think at one point there was a UNIX permission system *exactly* like MIAC. It was dropped because the system is a bit silly. Something like Apparmor is much more robust and way easier.

On Windows I can count the number of applications that run at LI on one hand. On Linux I can count the number of applications I *can't* apparmor on one hand.

This is because Low integrity isn't really flexible at all.

If I set up a separate user they should have their own separate UID run Firefox.

I wouldn't rely on user accounts. The biggest benefits are IPTables being easy to use for it and no X11 keylogging.

If you want to really restrict an application you're going to want either SELinux, AppArmor, or Gradm.

 

Ask and you shall receive.
http://msdn.microsoft.com/en-us/library/bb625957.aspx
and
http://msdn.microsoft.com/en-us/library/bb625963

AFAIK, each user on a Linux system has write access to his own user folder and no other. He may be able to read from other users' /home. So downloads are stored in each user's /home, and therefore are not writable by any other user. I think you have to su - to access another user's /home. Correct me if I'm wrong.

I think the limiting factor to consider with your approach is privilege escalation. If you rely on integrity levels (which are based on privileges), then they can be defeated if an attacker can successfully escalate privileges. I'm hazarding a guess that apparmor and selinux are more widely used in Linux to limit what's written where because that is harder to defeat- doesn't matter if an attacker elevates permissions within Firefox if Firefox can't make /bin calls except to itself.

 

Thanks, those appear to confirm that MIAC is not broken for multi-user. I think. It's hard to tell with all the verbosity.

Yeah, that's normally how it works. The problem I was thinking of is that, if user jdoe and user rroe are both running Firefox as user ffsandbox, they'll have access to each other's downloads, profiles, history, etc. via that same single user.

True. A local elevation exploit could also break out of a chroot sandbox... I'm thinking less about protecting the root account, than protecting user data from tampering and unauthorized viewing (and preventing malware persistence) in the event that a user's program is compromised.

That said, local elevation exploits are a dime a dozen, so I should probably be using some sort of MAC anyway.

Interesting. ACLs with integrity levels strike me as a simple, elegant security solution... I guess they fall under the pretense of simple, elegant solutions that are also entirely wrong?

For a multi-user environment that could get out of hand really fast.

Yeah, starting to look like it basically boils down to that.

BTW. How would XNest or Xephyr be for interfering with X keylogging?

Edit again: Hmm, I notice Chrome and Chromium use an empty chroot jail. How does this work? Could the trick be used with other applications to avoid the need for mount --bind kludgery?

 

Apparmor can restrict root, yes.

It also prevents exploits outright by restricting capabilities etc.

One user has limited read access to another. No write access.


@GJ,

You can harden chroots with grsecurity =p or even just apparmor and removing chroot rights can help depending on the sandbox solution (ie: chrome's tabs don't have that right but the sandbox process does, it just drops it.)

If you want t prevent user data being tampered with a separate user account isn't hard to do. It took me maybe 20 minutes last night to figure it out. Apparmor helps.

Simple is great. I like simple. But simple does not magically mean it works and in the integrity case, while it *can* work, the vast majority of developers aren't interested and there's no way for users to really work around it. With Ubuntu/Linux the OS can deploy apparmor profiles (so even if the dev is lazy it won't matter) and the user can do it as well.

Not really. Right now I have pidgin in a separate user account. If I create a new user for my friend he can run pidgin from that separate user account as well with virtually no work (you have to create a shortcut, that's all).

Not sure about XNest or Xephyr. It has to do with creating hot keys. On Wayland you create hotkeys through wayland, the individual application can't do it.

Isn't a Chroot empty until it isn't? The renderer/tabs need no file access so they never write to it.

 

The Windows Integrity Controls are a bit different than what is found on UNIX systems. The MAC systems on Linux (especially SELinux) follow the Bell-La Padula model. The Windows integrity controls follow the Biba model. You can google and read about each. Basically the rules for Biba are the inverse of the rules for Bell-La Padula.

 

Is the Wikipedia synopsis anything close to correct, i.e. Biba = "no read down, no write up" while Bell-La Padula = "no write down, no read up"? Which would make Bell-La Padula pretty useless on the desktop...

Oh, except that it builds on the DAC model that UNIX already has. I see.

Still, it looks to me like a Bell-La Padula model would require a lot of customization for desktop tasks. The Biba model looks much more suited to protecting a desktop from malware, and much easier to use.

OTOH, it also looks to me like the Bell-La Padula model would provide better protection against e.g. keystroke logging, since (in theory) apps running at lower integrity couldn't read keystrokes from ones running at higher integrity. Same for other kinds of userspace spyware.

(Incidentally I didn't know FreeBSD had a Biba model MAC module. I'll have to check that out, the man page makes it look pretty nice.)

 

It's more about the models of separation and how the applications are sorted.