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.
Related
So I got some child processes that need to be able to adjust System time on a windows 10 system. The way it has been done in the past iterations of Windows was simply forking children as Administrator so they would have permission to edit the system time.
Things I have tried:
Opening up the permissions for changing system time through the Local Security Policy so that Admin privileges were no longer required.
Making a custom task in tasksched.msc to run the child process as administrator.
Passing ruunas /user:Administrator app.exe as the executing command to run the child process, the problem here is that prompting for the password is not an option every-time this process needs to run.
Elevating the parent process is not an option sadly, though it does work.
I'm not sure what to try next.
So I found a work around. I used the 2003 windows resource kit utility 'ntrights.exe' to open up the permissions on windows 10.
I ran ntrights.exe from the terminal and then the command:
ntrights -U "UserAccountName" +R SeSystemtimePrivilege
This allowed the process to set the time as necessary without needing administrator privilege.
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 am trying to write a shell script to mount loop device, and I am assigning this script with a sticky bit to execute as uid(root).(this is for other users on server) The problem is I can't seem to run 'mount' command without using sudo in front of it. When I am in root account, I can run 'mount' command without any issue, so I thought by setting script with rws-r_x-r_x would do it.
Am I misunderstanding the concept of using sticky bit? or is there any other way?
The server is running under Ubuntu 10.04
You mean the setuid bit, not the sticky one. The kernel doesn't honor the setuid bit on scripts. See this post for a thorough description, here's a summary: the gist is that suid on a script is insecure.* The kernel starts reading the script to execute it, but it sees the #!/path/to/interpreter and figures out that it needs to be interpreted. It then cancels "executing" the script directly and calls the specified interpreter, passing the script name as the first argument (and all subsequent arguments in order after that). The reason setting UID is insecure in this instance is that an attacker could potentially change the script to be executed between the kernel setting the new UID and the interpreter reading the file.
*: The other post mentioned that perl handles its scripts in such a way that they can be suid.
As for the actual mounting problem at hand, add a line to /etc/fstab/ and include the user option.
I have a question closely related to this thread:
Best practice to run Linux service as a different user
but I need the solution to work in "every" Linux distribution.
I would like to run a program as a non root user from a script. This way, when init.d starts up the services at boot time as root, the script launches the process as the non-root user I specify. Of course the solution shouldn't prompt for a password.
I think this is the normal/correct procedure when deploying applications.
How could I do that?
Thanks a lot
A good way would be to drop privileges from your actual program. Then just pass that user as a parameter. Inside you can handle it in a very standard way (setuid())
Otherwise su -c 'your command' different_user will work just fine on any linux. (as long as different_user exists)
There are two ways:
sudo command - you need to add the original user to /etc/sudoers with such entry that the program can be run without (NOPASSWD)
seteuid() system call (if you can modify the program)
If you are root, you can also use su (see #cnicutar's answer for details)
I want to build a web based admin tools that allow the system admin to run pre-configured commands and scripts through a web page (simple and limited webmin), what is the best approach?
I already started with Ubuntu installing LAMP and give the user www-data root's privileges !!!
as I learned (please check the link) this is a really bad move !!!, so how to build such web-based system without the security risk?
cheers
I did something like this a couple of years ago. It was (I like think) fairly secure and only accessible to a limited number of pre-vetted, authenticated users, but it still left me with an uneasy feeling! If you can avoid doing it, I'd recommend you do :)
I had a database sitting between the frontend web-tier and the script which was actually executing actions. The relevant table contained a symbolic command name and an optional numeric argument, which was sufficient for my needs. This allows you to audit what's been executed, provides a quick and dirty way to have a non-www user do things, and means if the website is compromised they're constrained by the DB structure (somewhat) and the script which pulls data from it.
The data from the DB can be read by a daemon running in a separate, unprivileged account. The daemon pulls and sanitises data from the DB and maps the 'command' to an actual executable (with a hard-coded map, so commandA executes A, commandB executes foo, and anything else would get flagged as an error). The account can be locked down using AppArmor (or SELinux, I imagine) to prevent it from executing, reading or writing anything you don't expect it to. Have a system in place to alert you of any errors from either the daemon or AppArmor/SELinux.
The executables which the daemon runs can be setuid'd if appropriate, or you can use the sudoers mechanism to allow the unprivileged account to execute them without a password.
I already started with Ubuntu installing LAMP and give the user www-data root's privileges
Don't do this.
If you really want to execute some very specific scripts under root privileged. Create such predefined very limited scripts, allow their password-less execution with sudo for specific user and then run them via script and don't forget authentication.
Generally this is bad idea.
SSH is your best friend.