I understand that setUID bit works with the EUID and RUID in Linux to give non-provisioned users temporary root access to executables that require it. However, my main concern is that let's say a process is malicious on a computer. Even if the process has a low-privileged User-ID (like "nobody" on Macs), if all they can do to execute code is work with files that have the setUID bit to get a temporary root EUID, wouldn't that defeat the whole purpose of having privileged processes, as that process now technically has root access to the computer? Or am I missing something? Thanks!
Just because an executable has privileged access doesn't mean the person who executes it can cause it to do arbitrary actions.
Programs that are intended to be run under setuid must be written very carefully to avoid being used in unintended privilege-escalating ways. If they have security flaws, yes, it will create exactly the problem you describe, and you must be very careful before applying the setuid flag to executables.
Related
Is there a way for one process (such as an executable or bash script) to elevate the privileges of another, running, process? e.g. If I have a program running as normal user user, is it possible for another process, running as root to elevate the privileges of the first as if it had been run as root originally?
I have seen exploits modify the credential struct of a process to perform this, but I'm not sure if there's a way to do this more legitimately.
Looking further into this, it appears that there is no way to do this without installing a kernel module; essentially a rootkit. The kind of thing I want is demonstrated here.
No, these properties of a process cannot be altered after it starts.
No. The only way to elevate a process’s privileges is by execing a setuid binary (such as /usr/bin/sudo); you can’t do it to an already running process.
You can, however, ask sudo to copy a file to a temporary path, launch your editor with your own privileges on the temporary path, and then copy the result back in place as root:
sudo -e filename
This is possible, but only at Ring 0, using the commit_creds(prepare_creds(0)), which will update the task struct associated with the userland process, setting UID/GUID to 0. This is only possible with code already running in Ring 0, such as a Kernel module/rootkit or kernel exploit. An example of how this may be done is here.
You could start a new process using sudo, but starting a new instance with higher permissions will always result in a new process being created.
It's not possible to grant additional permissions to an already running process.
I am writing a program, and want it to run with reduced privileges. I know as root I can do this, but what about as a normal user. Can I set the user to nobody, without first setting it to root?
No, you cannot change the user of a process to nobody without root permission.
The relevant syscalls are setuid(2), seteuid(2), setresuid(2) ...
(There might be perhaps a Linux-specific way of restricting new file operations on a process, but I can't recall the details)
See also SE-Linux, Setuid, credentials(7), capabilities(7) and read Advanced Linux Programming ...
You do not need to set root permission, but you must start the program as either a root user or another admin user.
This is an imaginary example of what I like to do. Don't take it too literally.
Let say my process is being ran as www-data and I have a lua script called thedevil.lua. It will try to delete, corrupt and cause as much problems as possible. I'd like to fire up a process (or load a shared object) that has a lua interpreter and it will try to ruin all my websites as the user is www-data.
Is there a way I can say lets create this process (or load a library) with LIMITED permissions. Say the script is in /var/www/devilscript/thedevil.lua. I'd like to give it permissions for /tmp/www/devilscript and /var/www/devilscript/. Is that possible? I don't want to create a new user called devilscript and give it limited permissions than run the process as that user. I just want to say I am www-data but I only want to give this process/lib a subset of what I can do.
-edit- Could you give me the name of the functions to execute the said so or binary with lower permissions?
-edit2- Can windows do something like I asked?
Yes, depending on the operating system you are running on, there are various sorts of sandboxing methods available in modern Unix systems. It depends a bit on which one you are running. Under Linux there are almost too many -- SELinux, Apparmor, Tomoyo, and others. FreeBSD has a Mandatory Access Control System as well as the Capsicum capabilities system. Mac OS X has a sandboxing system as well.
Most such systems allow you to reduce the privilege that a particular process gets in a fairly granular manner. In general, capability systems are easier to work with than Mandatory Access Control (MAC) systems, but they are less frequently available.
A primitive way of doing this sort of privilege restriction in older Unix systems was "chrooting" a process, that is, running it in a restricted part of the file hierarchy using the chroot system call. Unfortunately, that remains the only truly portable form of privilege reduction available in Unix systems -- you thus encounter it in the configuration systems of many system daemons.
SELinux will allow you to create a domain that has restricted access to various file contexts and resources, regardless of the user the process is running as (even root).
I read from some books that the seteuid together with euid and saved UID can be used to drop root privilege temporarily. The case is:
set euid to a non-root one.
do something which does not require root privilege.
set euid to root again (this works because root is still the saved UID).
I think this is flawed. During step 2, some malicious code could also invoke seteuid to root so this method of dropping root privilege doesn't prevent hijacking code from gain root privilege. Is my analysis correct? If so, what could seteuid-on-saved-UID be used for?
Your concern that the malicious code might also restore the effective UID to the saved UID is legitimate. If you are concerned about this, maybe you should not be using a setuid root program in the first place. (LD_PRELOAD and other such things are worrisome in general; they are also restricted when a program is running with setuid privileges.)
Often, though, the mechanism is used in a forked child, where the child will execute some other process without the elevated privileges because the saved UID won't be retained by the executed process. If the malicious code manages to take over before the exec(), then you still have problems. After the exec(), the malicious code only has the privileges of the real UID, and the user could have done whatever it is that the malicious code did.
Setuid is flawed in general, because of the possibility of privilege escalation without authentication. Even the notion of root privilege is getting a bit antiquated. Most platforms have updated methods for gaining additional privileges, whether it be from shell with "sudo" on unix and "pfexec" on Solaris, for example.
Additionally they generally have more fine grained controls on which privileges they need escalated. With setuid, its all or none, but with RBAC on Solaris for example, the framework provides methods for specifying which exact privilege(s) you need, generally lower level stuff like opening files, reading directories, etc..
In general, I think now days you should avoid setuid for anything and use newer APIs instead.
I want to write a server that receives and executes code on behalf of non-trusted parties.
In order to make this more secure I want the code to be run as a user that is created exclusively for running this code and then deleted.
How can I grant a non-root user the permission to create, impersonate and remove other users?
The only way you could conceivably do this is with a proxy program that's setuid root (i.e., chown root my-proxy-process; chmod 47nn my-proxy-process. And that setuid proxy program takes care of handling security considerations, setuid'ing to the named user, etc.
However the security problems with this should be fairly clear. One way it could be limited is to ensure your non-priveliged process runs with a user in a name group. Then chown thet proxy command with root:myprivategroup and chown it as 4710 so only users that are members of myprivategroup can execute it.
This is probably as secure as it can be. The main thing is making sure the proxy process is good and secure and locked down so only pertinent users can run it through group membership.
If there's any other restrictions you know can be applied to user-supplied processes, then the proxy program could validate that the process confers to those rules. Note that whilst this may be a stop gap, it wouldn't be beyond the realms of technology for someone to craft a "bad" program that passes the tests.
For added security (recommended), use a sandbox or chroot jail as mentioned by mark4o.
Maybe you can grant permissions to non-root user with sudo and /etc/sudoers, but this way seems not secure and not linear.
I don't know what you need, but maybe you can pre-create some users and then use they.
You will want to use some kind of sandboxing or virtualization; at least a chroot environment at minimum. See also Sandboxing in Linux.
This is a problem as you can not use su vie script without the terminal (probably a security feature). I'm sure you can hack your way through this, but it was probably done for a good reason.