Why does chrome-sandbox need root-rights (suid set) ?

Very suspicious, needs some explanation ... i'd like to know what happens on my pc.

?

Edit: Ok, i have a very bad feeling giving 4755 to a google program (even if it's open source what i doubt) leaving a succesfull attacker (like foreign firms or agencies) with root rights. And i do not understand what this has to do with unity. So, pls, some explanations would be nice.

Editedit: Running with root rights is bad practice, to say the least. There are better ways that don't smell that much like ... well you get my drift. So if unity doesn't take chrome out i'll have to install it on a separate pc.

 

chrome-sandbox requires suid root bit, because it's a sandbox - a program that creates a restricted environment for running untrusted programs, which requires privileged syscalls to setup that environment.

http://www.insanitybit.com/2013/04/29/explaining-chromes-linux-sandbox/
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox.md

Also it's open source: https://chromium.googlesource.com/chromium/src/+/master/sandbox/linux/suid/

 

Sorry, but no. It does not require the root bit to be set to accomplish that. Linux offers sophisticated means to create safe environments and that does not include opening up the machine by running programs with root rights. That is exactly the wrong way thinking.
k

 

Sorry, but yes. chrome-sandbox uses chroot, prctl and few others syscalls which can return EPERM error if the process has insufficient privileges.

 

Interesting discussion. chroot will return eperm. But chroot in itself is not safe, it's not even a security feature, root (chrome-sandbox !) can break out. To me it seems that chrome-sandbox is programmed the wrong way in respect to security. It has been hacked before (under windows) i read ? I am not a kernel-hacker but have reasonable knowledge about linux. So i iterate back to "no", were it programmed right

Unity, like all free programs, runs with very low user rights on my pc. But this is all vain if it calls an external program with perm 4755. Linux has built in "sandboxing" capabilities (a lot), no need to revert to external programs.

Why am i forced to use chrome-sandbox ? And what does it have to do with Unity ?

Have done a lot of learning about Unity/Blender/C# in the past weeks ...

pls., i don't want to sound harsh, just need some explanations.

k

 

ye i think too that it dosent need sudo, Vote NO SUDO

 

Unity supports builds for WebGL and it makes use of a browser window internally for the Asset Store. One or both of those is the most likely requirement for chrome-sandbox.

 

WebGL dosent req chrome-sandbox for sure thats even not logical.... assets store shoud not req sudo too exaple i have a game Heroes of Newarth that you can buy stuff from in internal shop and it dosent req sudo. Moste logical thing i think is unity dev put sudo cuz they were having problems with instaler and insted to fight with bla bla stuff hey just used sudo. But anywey think thay can make without sudo for sure if have time to spare

So VOTE YES against sudo

 

@Tak: Any chance we can get better information on the need for chrome-sandbox? Or has it already been stated? It seems to be worrying people so a brief explanation would be nice to link to them.

 

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md

I also think the SUID bit should go. Especially in a component developed by Google.

Doesn't Steam use WebKit w/some Chromium parts, too, and didn't they disable the renderer sandbox in their Linux client?

EDIT: Looks like even Google is moving away from SUID and towards user namespaces: https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md

 

edit: Someone from outside might get a wrong impression here: This is *not* against Unity, the game engine is *marvelous* (linux version still needs some polish *duckandcover*) ! It's on security of the os and the question who is responsible for that.

-----------------

I will not install a google kernel module, if that's what it's about (can't read it all right now, sorry, but thank you for the support !). My statement is that it i alone want to control the security of my machine on the os-level. I can see that others on a single user pc just want to outsource that task, no problem for me.

A friendly hint to the makers: many in the linux community have strong aversions against executables with root-rights and kernel modules from "untrusted sources". Network admins will probably not tolerate such programs ;-) You might - i think you will - widen your client base when you release a clean version, and i have the feeling that is exactly what you want

A question to a friendly person who installed the "plaform-agnostic" version: would you tell me if that's bundled with google as well ?

k

 

If you're concerned with security why not simply install and run Unity within a virtual machine?

 

@kemde: If you mean the .sh installer, I'm using that. It requires the chrome sandbox as well and Unity checks its permissions before starting.

@Ryiah: It sadly doesn't run that well in VirtualBox and VMware. The 3D HW layers aren't quite perfect yet and if you want to access the Unity project folder in both host and guest, shared folders are the only solution (that I know), but then Unity doesn't detect asset changes anymore.

 

I was thinking more along the lines of KVM + QEMU and passing the GPU through to the guest OS. Sharing files wouldn't be too dissimilar to how it's done normally. A VCS would handle the project folder and any other files by whatever means you normally share them (I noticed Dropbox supports LAN synching).

https://www.reddit.com/r/pcmasterra...assthrough_revisited_an_updated_guide_on_how/

 

that is a baypass for a broken hart, better w8 for hart donation

 

While you're sitting around waiting (and making stupid posts with half the words misspelled), the rest of us are actually progressing with our projects. Your choice though.

 

I... think he's just trying to say he'd rather have the SUID thing fixed rather than use virtualization as a workaround. Not sure though

I didn't know that KVM could do that. Cool!

 

grammer trol, you understand what i wanted to sey so cry more i wont change, what progression? on removing sudo or what?
See Cygon4 got it right even with my broken english. I think using Wine or some virtualisation is envading the problem

 

Sunday morning and this is totally going the wrong way. It's not my task to adapt my operating system to work around these types of mistakes, i'd rather drop the tool or have it on a dedicated machine.

Before this get's totally off the rails, i hope there'll be an official statement on the matter in the next days in order to fell a decision on the further use, that's all. No need to get personal or defensive ...

 

Is it Unity's job to adapt their software around a handful of users though? Considering how many threads are showing users testing the release it's clear that the vast majority were not concerned with chrome-sandbox.

Either way my suggestion of a VM was not entirely for the purpose of running Unity but rather to install it and then extract the files it installs sans chrome-sandbox into your host OS.

This is an experimental build after all. If you wanted an engine that was ready for production use I recommend Unreal.

That's why I tagged one of Unity's devs in an earlier post.

 

Actually, the normal way to create a restricted environment is to run a program as root so it can change to another user. This allows the program to run without the privileges of the current user, so it can't debug your programs, snoop your network connections, or copy your files--things that would allow it to, say, grab your banking passwords out of your Firefox or Chrome profiles.

To switch to a low-privilege user such as Nobody, the program first needs to be a high-privilege user (root). Typically, high privileges are used to open files; you can also achieve this by opening a pipe to the high-privilege program and then using sendmsg() to send file handles. That is to say:

• The user-owned program opens a file handle as a pipe
• The user-owned program runs fork(), and now can communicate with the child through this pipe
• The child user-owned program runs execve() on a SUID executable, gaining root and maintaining pipe communications
• The root-owned child program runs seteuid() and becomes "nobody", a low-privilege user
• The user-owned program opens files and sends their file handles to the now-low-privileged child program using sendmsg()

This requires root access for the intermediary program: a user-owned process can't change effective user ID. Every process which allows for the changing of user ID by, for example, providing a password runs as SUID root to first become the high-privileged root user. Even in SELinux, binaries requiring high privileges are SUID root, run as root, but have security contexts restricting root's privileges.

In other words: all sophisticated means to create safe environments first and foremost involve running programs with root rights. There is simply no other way to do it.

 

@bluefoxicy: Take a look at the link I posted a few posts above. The chrome sandbox already works without a SUID binary through user namespaces. And it looks like all one needs to do is flip a switch in the makefile.

It is my understanding that the SUID method of dropping privileges is being phased out. And isn't it a rather silly situation anyway that if you have a process from a vendor you don't fully trust, and that process wants to reduce its own attack surface, that you have to hand it root privileges just to do so?

Anyway, I'm happy that there is a usable Linux build of Unity at all and I've been using it, including Google's sandboxing stub, for almost 8 weeks now. I just wanted to voice in that I'm concerned about running a Google SUID executable

 

Ok, this is my last post on the subject and then i follow Ryiah's advice. I like chicks with red hair

bluefoxicy, i have read the text about chrome-sandbox and understand how it should work. But you are wrong in two ways: First, the sandbox as implemented by google is poorly programmed because it requires root rights.

Concerning your last sentence, well ... yes, when i set up the pc and the first user i had root rights. So, second: for installing and securing a program root rights are at least a bad habit, in an environment that claims to be "safe" it's dangerous nonsense.

And (pls. excuse) it seems there is a lack of understanding the problem that's connected with executables that run as root (and come from an outer source). Even if we assume that the everyone in the pipe from google, unity, the hosting servers or wherever were all nice guys still everyone can change and recompile the program. I will not let that on my network.

btw.: once done you can admin a linux-system without logging in as root, that's the way Just to enforce the "second" part.

Be it as it may, unity3d made a really good impression on me and i invested 3 weeks that now are partially in vain.

All the best !
k

 

User namespaces require the system administrator to configure the system to map a user ID to another user ID in another context, as far as I can tell. For one thing, you can't even set up namespaces (which is done by messing with the system's internal process contexts) without CAP_SETUID and CAP_SETGID, which you can only get by being root, dropping other capabilities, and then changing your EUID.

This may sound like the kind of thing you configure using sysadmin privileges, and then have it set up on each boot; but you have to realize: this has to be done for each user, and for each process, and then you have to launch the process you want namespaced in a specific way as to move it into the namespace context. That means if you have users John, Jim, and Bob, you have to set up separate namespaces at boot for John, Jim, and Bob. The namespaces are actually owned by a particular user, so you can't set up one and say that's good enough; you set up one for John, you get Jim and Bob not able to use it.

Not really. The process starts up and does nothing (no network, no interpreting files, etc.) except set up its execution environment, so it's not vulnerable to any attack. Then it starts doing dangerous things, but it's no longer privileged.

Setting up any sandbox--chroot(), jail(), namespaces--requires root rights. You can't sandbox as an individual user because the user owning the process will have access to all the files any other process originally run as that user has access to. That defeats the purpose of a sandbox. The first thing you need is the ability to tell the system you're someone else who doesn't have the privileges to access your files; and to do that, you must be root.

You simply don't understand how the Unix operating system (or any computer operating system) work. The things you expect to be possible would be fantastic for hackers: you could change to another user without first proving you have that access, because you wouldn't need root access to change your access level.

Why do you think the openssh server runs as root and spawns a child process, which then drops privileges and changes to the user "nobody," accepts connections, and passes log-in information back to the root-owned sshd process? The child process can't read the user's $HOME/.ssh/authorized_keys or the /etc/shadow file, so needs the root-privileged sshd to drop privileges to that user and read $HOME/.ssh/authorized_keys and then accept the log-in shell or exit and leave the root-privileged sshd to read /etc/shadow and verify password (keyboard interactive log-in), after which that spawns another child which then drops privileges, becomes the user, and supplies the shell. A lot of going through a root-owned process for something like OpenSSH to work, don't you think?

Why do you think /bin/su and /usr/bin/sudo are SUID root?

Why do you think everything that changes to a non-privileged user first gains root access?

It's because a non-privileged user can't simply say, "Hey, I'm able to be another user now!" Not if you want security.

This is really basic stuff. Have you never done exploit development and found new ways to hack into systems?

 

User namespace do not require any configuration by the system administrator and can be used by any unprivileged process. Read the manual.

Also consider the fact that this is how current Chromium releases already work (the SUID method is only left for backwards compatibility with older kernels).

Trusting a binary SUID executable from Google to just drop its privileges as it claims is not an ideal situation to me.

I don't think this thread is leading anywhere, so I'll excuse myself from it with this post.