Using fpSystem() to launch new instance of program with elevated privileges

[SuperSathanas]

Typically, if the program I'm writing will need elevated privileges, I'll just do a quick check of the EUID, and if it's not root, I'll display a message saying the program needs elevated privileges and halt.

However, just a few minutes ago, I decided to instead just use fpSystem() to launch a new instance with sudo, passing the parameters along.

Code: Pascal  [Select][+][-]

1. procedure RunRoot();
2. var
3. args: String;
4. I: Integer;
5.   begin
6.     Initialize(args);
7.     if ParamCount <> 0 then begin
8.       for I := 1 to ParamCount - 1 do begin
9.         args := args + ' ' + ParamStr(I);
10.       end;
11.     end;
12.     fpSystem('sudo ' + ParamStr(0) + args);
13.     Halt();
14.   end;  
15.  

This seems to work out perfectly well.

The question though: Is there anything dangerous about using fpSystem() this way? Any weird behaviors I should be aware of? I'm not concerned with the user or process having root privileges so much as I am with any possible gotchas of fpSystem() itself, or other methods of launching/interacting with external programs.

Edit: While working on the project I implemented this in last night, I did experience some weird behavior. I was launching the executable from the terminal, not in Lazarus' console window, not having Lazarus launch the terminal. At some point, after having launched it at least a couple dozen times over a couple hours, my root password just stopped working for only my own program. It would prompt me to enter it, I would, and then it would give me the try again message and let me do 3 attempts before failing.

I could still use sudo with any other program I tried, and su itself still worked, but sudo wouldn't accept my password until I rebooted my machine.

So, that's worrying.

[Thaddy]

Start with man sudo and scroll to:

Code: Text  [Select][+][-]

1. SECURITY NOTES
2.      sudo tries to be safe when executing external commands.
3.  
4.      To prevent command spoofing, sudo checks "." and "" (both denoting current directory) last when searching for a
5.      command in the user's PATH (if one or both are in the PATH).  Depending on the security policy, the user's PATH
6.      environment variable may be modified, replaced, or passed unchanged to the program that sudo executes.
7.  
8.      Users should never be granted sudo privileges to execute files that are writable by the user or that reside in a
9.      directory that is writable by the user.  If the user can modify or replace the command there is no way to limit
10.      what additional commands they can run.
11.  
12.      By default, sudo will only log the command it explicitly runs.  If a user runs a command such as ‘sudo su’ or
13.      ‘sudo sh’, subsequent commands run from that shell are not subject to sudo's security policy.  The same is true
14.      for commands that offer shell escapes (including most editors).  If I/O logging is enabled, subsequent commands
15.      will have their input and/or output logged, but there will not be traditional logs for those commands. Because
16.      of this, care must be taken when giving users access to commands via sudo to verify that the command does not
17.      inadvertently give the user an effective root shell.  For information on ways to address this, see the
18.      Preventing shell escapes section in sudoers(5).
19.  
20.      To prevent the disclosure of potentially sensitive information, sudo disables core dumps by default while it is
21.      executing (they are re-enabled for the command that is run).  This historical practice dates from a time when
22.      most operating systems allowed set-user-ID processes to dump core by default.  To aid in debugging sudo crashes,
23.      you may wish to re-enable core dumps by setting “disable_coredump” to false in the sudo.conf(5) file as follows:
24.  
25.          Set disable_coredump false
26.  
27.      See the sudo.conf(5) manual for more information.

I would limit the program to a user  and a dedicated group and directory.
If you happen to run an Selinux kernel you can/must provide further configuration, depending on your system.

[SuperSathanas]

I guess I'm confused as to how all of that is relevant. I'm not saying it's not relevant, just that I don't really get it. I've only been on Linux for about 2 years, and I've only relatively recently been writing programs that might require root privileges. I mean, I understand what the man pages are saying there, I'm just not really understanding the difference between the user using running the program with sudo themselves, or having the program see a non-root EUID and then launching a new instance of itself with sudo. In my head, the effect is the same, in that a user that is able to gain root privileges is gaining root privileges and can now do whatever root can do. The only difference is being prompted for the root password when launched without privileges versus launching it, being told you need root, and then launching again with sudo.

I guess what I'm asking is, if a user is already capable of using sudo and running applications with elevated privileges, what's the difference?

The project I'm working on just streamlines timeshift system snapshots and pacman updates, both of which require root. Without the program, I'd just doing

Code: Pascal  [Select][+][-]

1. sudo timeshift --create
2. sudo pacman -Syu

and a few other commands, anyway. If the point is to require root privileges so that the program can execute other programs that require root, then what's the difference?

[Thaddy]

In general you won't want absolute root from a program executed and installed in user space, so you limit it to the program and/ or the directory that the user needs and/or a group.
That's basically all.
You do not need to give a user/application full sudo rights to work and basically professionals never do that.
If needed, read up on chroot, which is an isolation level that can run programs in its own completely isolated space, a.k.a. Hotel California. (In French probably Huis clos, because the Eagles stole the theme from that play/novelle.. In English it is translated as No Exit.) "You can enter any time you like, but you can never leave"


I consider this quite common for someone that has been using Linux for over two years 

[SuperSathanas]

I guess I'm either still confused or we're talking about this from two different perspectives.

I'll try to make things more clear, assuming that the confusion is my fault.

I have programs I wan to use that require root, timeshift and pacman. They are common programs that either an admin/root user or the user of a single user computer would use regularly. It would odd for someone to not execute them on their own machines. They would need to either enter a root shell with su or launch them with sudo to use them.

I wanted to streamline the process of querying for pacman updates, updating and ranking my mirror list, creating a timeshift snapshot, running pacman updates, and then cleaning up excessive snapshots. I could just manually enter all those commands through the terminal, using sudo, or I could write a program that does all that and responds to the prompts for me (we'll just ignore the dangers of "yessing" through pacman prompts for the moment). I guess alternatively, I could SETUID 0 for both timeshift and pacman, but then that means that any process could execute them regardless of current priveleges. I could also just SETUID 0 on my own program, effectively achieving the same result as what I'm doing now.

So, if it's acceptable to run "sudo pacman -Syu", then why is it not acceptable to have the program check if the user who owns the process is root, and if not, launch a new instance with "fpSystem('sudo pacman -Syu')"? As far as I can tell, it is effectively the same the concept.

In general, I wouldn't have the user/myself run something with elevated privileges where it isn't needed. I wouldn't require elevated privileges without tightly controlling what the program is able to do, and I would drop privileges as soon as they're no longer needed. I'm definitely not allowing the user to have arbitrary code or scripts run while they or the process have elevated privileges. It's controlled (to the best of my current knowledge), concise, and does no more than it needs to do before dropping privileges and halting.

So, why would it be acceptable for a user to "sudo pacman -Syu", but it would not be acceptable for my program to to execute that command given that the same user would still need to provide that root password or already possess root privileges? Why would it be acceptable for pacman and timshift to require root, but not my program?

Aside from that, though, I guess I also wasn't very clear in how I asked my question, because I wasn't specifically concerned with the dangers of running under root privileges. I was more concerned with there being any dangerous or wonky behavior associated with having the program launch a new instance of itself with fpSystem(), or using fpSystem() with root. It's a given that anything with root privileges can do whatever it wants on the machine, and that it's dangerous and unnecessary to allow it all willy nilly. I just didn't know if there were any gotchas regarding fpSystem() or any other method of executing/interacting with external processes, like TProcess, RunCommand, etc...

[Thaddy]

Well, if it is not for commercial purposes and "it works" as you stated, please use it as you did. I merely pointed out that one would not do that easily, professionally.
Running an install or update - in your case pacman - needs to be root for just the directories that it touches and that can change between updates.
It is often quite a job if you do not control the updates yourself.
If the user is not a sysop, usually the sysop installs the updates remotely. This is also the case with Windows, btw: you need admin rights and noon of us on my network, except me and that in itself is a liability -, has admin rights, but I prepared a magic USB stick.
Prevents your sixteen year old from installing strange stuff in system space.