Raru: Run as random user | Hacker News Reader

Raru: Run as random user

github.com

65 pointssubbz24 comments

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.

This is clever. It's not running code as a random user on your system, but rather as a random non existent user id.

This has the effect of denying lots of privileges to whatever is being software is being run.

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!

https://github.com/nickodell/rarucmd/tree/master

(Don't run this on a system you care about.)

[0] Randomness may vary.

That is hysterical. I am flattered.

Reminds me of that game that would delete your files if you couldn't shoot things fast enough.

Alternatively: rudo?

That is good.

I don't get it. Is there a reference to rudo?

Random User DO, I think.

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.

Will this work on OSX? I have been looking for a lightweight way to sandbox apps on OSX.

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.

Only if the underlying directory has the "other+rw" permissions set (like /tmp).

Doesn't the Chromium sandbox already effectively do this without the suid bit by using CLONE_NEWUSER to enable use of setuid and then calling it?

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.

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 stand (embarrassingly) corrected.

How does it decide which files are permitted to be accessed by the app?

Files with readable-by-all-users / writeable-by-all-users / executable-by-all users flags.

Reply on news.ycombinator.com