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.
Related
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.
I am making a Linux application using Python3 and Qt5. When user will install this application, It will create some files in /usr/share folder. To create the files the application needs to have root access.
I plan on having the application show a prompt box to user and user will enter the root password to give root access to the application. But I don't know that how can I give root access to the application by using that password?
This is a world of pain. It's certainly possible to have an application that runs as a normal user carry out certain actions as a privileged user, but I always feel that the need to do this suggests that installation and maintenance hasn't been thought through properly.
To elevate privileges, and assuming the "sudo" isn't appropriate (it probably won't be in this case), you will either need to use an operating system tool that does the job (prompting for credentials and then running something), or implement a helper for your program that has suid attributes on its executable.
I expect all Linux systems have access to "su", but the standard su doesn't have a graphical interface, which is a drag for GUI programs. You can collect the user credentials in your application, and then pass them to su (which is fiddly), or you can use one of the various graphical su-type utilities such as gksu. Of course, that only works if those utilities are available on your platform.
If you go the route of providing your program with a suid part that handles the work that needs elevated privileges, you need to be inordinately careful about security -- how you collect the credentials, how you verify that intruders can't do things they shouldn't, etc.
Frankly, it's a can of worms. I would think that it's nearly always better to provide your application with an installation or maintenance module that has to be run as root. That way all the hard work gets done by the platform.
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.
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.
Given the dangers of SUID shell scripts, is there a more secure way of giving passwordless access to scripts (bash, PHP) with root permissions in Linux?
(Ubuntu 8.10)
You could consider sudo.
Although not 'passwordless', it doesn't require the user to be given the root password. It can also provide an audit trail of use of the script.
edit: as per comment from Chris, there is an option not to require a password at all for certain commands, see here for details. It can also be set up not to prompt excessively for the password, i.e. one entry of the password can be good for multiple commands over a period of use.
By the way, sudo is built in to Ubuntu and nicely integrated with Gnome. When ubuntu prompts you for your password to do privileged operations, that's sudo under the hood.
Be sure to review the "PREVENTING SHELL ESCAPES" section of the sudoers man page if you go the sudo route.
I would recommend sudo. Be sure to tighten your sudoers file appropriately; and yes, you can allow some commands to be executed with no password being requested.
Configuring sudo to let normal users run shell scripts with elevated privileges isn't any better from a security standpoint than making the script suid root. All the pitfalls still exist.
Instead you should write a proper program that does extensive security checks. Some points to consider:
Don't write it in C, you'll shoot yourself in both feet.
Check all inputs.
Drop privileges as soon as possible.
Keep it short.
Since sudo has already been mentioned, you might want to consider various sandboxed environments, depending on your needs — e.g., jail or similar.
For a really heavy-weight solution, consider a MAC (Mandatory Access Control) system, like SELinux, AppArmor, TrustedBSD etc.
To improve security consider whether it is possible to do the operation as a special user or group, which has exactly the access rights needed for it. Then you can make the script setuid/setgid for that user or group.
If the use case is a machine running under VirtualBox and security isn't really an issue, you just want a light barrier to prevent yourself shooting yourself in the foot, what then? (Then the security arguments don't really make sense, since it doesn't matter if the machine gets compromised by an outsider who can't see it anyway due to the way VirtualBox insulates it via NAT.)