Clever idea, however keep in mind that you are trusting both your file system permissions to be sane and your kernel to enforce them correctly (I.e. Not have bugs). a lot of projects have tried to do this (i.e. SeLINUx, trusted bsd) and it turns out to be surprisingly hard to build isolation policies that are useable and practical. I think one very cool solution recently has been qubes-- it runs each application in its own, temporary VM and provides secure UI magic for file opening, clipboard, etc
Thank you! This leans more towards the client side than the server side. It's certainly in the hackish and glitchy direction, and has no guarantees for success.
Qubes looks really interesting. I'd love to give it a try some time. I've just grown rather attached to my FreeBSD setup and this seemed like one of the ways I might be able to improve security on it.
Why does it seem like every time -sec comes up it is either "must be able to protect against state actors" or not worth doing?
Everything has bugs once you look hard enough. But this would still require more work to bypass than some random "malwaretisement" is likely to put in.
Reusing unix user ids as application ids is an excellent idea, and it has worked reasonably well in android so far. Good to see this being applied to X/desktop.
I liked this idea so much that I made an improvement: Instead of running a user-specified command, it runs a randomly chosen command as a randomly chosen[0] user!
From looking around an Android device via ssh a long time ago (still in the "wow, linux on my phone" phase), I remember that all apps that are installed also have their own user installed. Access to various resources was then done via the groups that user is in. But of course then there is no real "main" user and multi-user wise it is back to Win95 level. I assume that has not changed much.
And back when the first commercial games for linux came out, I did not want to trust binary-only executables and added a user plus a script so I could run anything via passwordless sudo and then did and still do the same for my web-browsing. Since these have their own ~, the data is persistent, but for something you totally do not trust raru looks nice.
This of course requires root access, automatic /home/me/home2 (or /home/me_home2) generation with optional persistence and isolation might be a next step. But I have no idea what the current state of more fine-grained control via cgroups etc. is. It is probably more complex than the true and trusted method of just adding another user.
But what I still miss (and never really looked at) is an ACL or so system to make the game or webuser completely transparent/subordinate to my main user, meaning I can read, write and take ownership of any files of these sub-users but they have to obey standard permissions wrt. my files.
Check out
Http://ccl.cse.nd.edu/research/subid/ Ctrl+f for sub-identities
Disclaimer: roughly what this project does was the topic of my (somewhat silly) masters thesis. I even did roughly the same x11 nesting, and I took it a little farther and made a kernel module that lets "parent" idebtities behave as "effectively root" to their child identities.
I was also wondering about that. With El Capitan there was the big 'root' change. I guess they probably didn't break setuid, so this might still work.
I'm not sure about xraru working or not. If vncviewer runs on OS X, maybe? It might actually be a convenient way to run X programs in general.
Although if I add in any logic for auto-scaling, it'll likely break on OS X. But it'd be even more important because of the crazy retina resolutions.
xhyve, by the way, is an awesome hypervisor for OS X. It's pretty light. Not raru-light, but as light as you can get for proper hardware virtualization.
Won't this cause any files/folders created by the process to be owned by said random uid? Seems like a great way to litter your filesystem with unreadable files/folders.
CLONE_NEWUSER doesn't actually change what your user is outside of that container/namespace. You get to map exactly one outside user to exactly one inside user. On systems where unprivileged users are permitted to call it, you can map your host user account to exactly one account inside the namespace, of which root is basically the only useful choice. Any interactions between the namespace and the rest of the system continue to treat you as your original UID.
The original implementation of CLONE_NEWUSER did actually convert users to vectors, or at least namespace-user tuples, which would have allowed unprivileged users to use the kernel UID mechanism for actual privilege separation. But that was dropped, I believe mostly because it was too much churn to the rest of the kernel and thus too risky. The current approach means that code that just thinks about root-namespace users continues to do the right thing.
The primary thing Chromium's sandbox seems to gets out of CLONE_NEWUSER is the ability to call chroot without shipping a setuid binary.
Oh, of course you're right. I implemented this stuff in gaol and completely forgot I had to stay as root inside the namespace because you can't setuid to unmapped users.
I've never heard of CLONE_NEWUSER before, it looks interesting. I don't think it's in FreeBSD.
My concern is that you can clearly browse and save files, so there is something that has access. Maybe it's much more secure than I thought, but I tend to be really skeptical towards programs of such length being perfectly secure.
CLONE_NEWUSER / user namespaces is Linux-specific, yes. (Though see my other comment.)
I believe the Chromium sandbox mostly applies to things like renderers, where you can just hand it a buffer and a bunch of inputs and it'll effectively contain things like HTML parser bugs or libpng buffer overflows. I'm not totally sure if browsing itself is sandboxed.
