mjhjmtu

Imagine that locally on my system sudo is configured with a timeout, so that once I authenticate after running sudo once in some terminal, I don't need to re-authenticate for another 10 minutes.

Does this effectively give processes running as children of the process that invoked sudo, but not with sudo themselves (hence as siblings, not children of the process that was run with sudo) the ability to escalate their privileges to root?

As a concrete example, imagine I run, in the terminal:

sudo echo "hi"
other_process

The echo process is run with sudo, but other_process is not. Can other_process use the 10-minute-expiry sudo ticket associated with the earlier sudo call, e.g., by itself launching a sub-process via sudo?

I guess if the answer is yes, it means you need to be very careful with any processes that you run within the timeout period of sudo. One might imagine that running an untrusted process like other_process would keep it within the sandbox of the current user, but if it can use the existing sudo ticket it could escalate to root.

Does the answer change if the sudo invocation comes not directly in the terminal but in a script launched from the terminal?

E.g., I run:

script.sh
other_process2

If inside script.sh, there is a line like sudo echo "inside script", will other processes subsequently launched by the script be able to use the sudo ticket to escalate their privileges to root? How about after the script finishes: will other processes in the terminal that ran script.sh still be able to use the sudo ticket¹?

¹ These are no longer like sibling but somehow 'aunt' or 'uncle' processes (siblings of the parent).

Yes, the sudo ticket is good for any process running in that terminal (at least running as your user). This is easy enough to test. Just make a test.sh (or whatever) with:

#!/bin/sh

sudo apt-get check

Then:

$ sudo apt-get check
[sudo] password for anthony: 
Reading package lists... Done
Building dependency tree 
Reading state information... Done

$ ./test.sh 
Reading package lists... Done
Building dependency tree 
Reading state information... Done

Generally, it's not advisable to run non-trusted programs, especially as your user. And you certainly shouldn't do it on a terminal you've got a sudo ticket for. If you must run non-trusted programs, you ought to set up security barriers (at minimum a different user, but even better would be a VM, or at least a container — setting up a secure sandbox for running untrusted programs is non-trivial).

Yes. Because sudo authorization is tied to a combination of your username and tty and a timestamp, any commands run from that shell could conceivably pass along the ability to themselves elevate privileges via sudo without typing your password (assuming you don't have timestamp_timeout=0 in your /etc/sudoers file).

As long as those scripts are executed within whatever timeout you do have set (default = 15 minutes).

file test.sh:

#!/bin/bash

echo "test: $SHLVL is: $SHLVL"
echo "test: I am $(id) on $(tty)"
echo "test: with sudo I am $(sudo id) on $(tty)"
/bin/bash -l ./sudotest.sh

file sudotest.sh:

#!/bin/bash

echo "sudotest: $SHLVL is: $SHLVL"
echo "sudotest: I am $(id) on $(tty)"
echo "sudotest: with sudo I am $(sudo id) on $(tty)"

results in:

test: $SHLVL is: 2
test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
[sudo] password for tim:
test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7
sudotest: $SHLVL is: 3
sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7

In that case, the first call to sudo was in test.sh, but sudotest.sh was not called with sudo itself, however because my username and tty are still the same, sudo recognized that process as being eligible for elevated privileges and didn't prompt me for a password during the execution of sudotest.sh.

And if I run it again after a couple of minutes, but before the timeout:

test: $SHLVL is: 2
test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7
sudotest: $SHLVL is: 3
sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7

I don't get prompted at all. And I wouldn't until the timestamp_timeout time limit passes.

You can see that the tty is staying the same throughout executions, and that SHLVL is incrementing because each shell process that's executed by the script is a level deeper from the calling shell. My interactive shell, SHLVL = 1, calls test.sh which gets SHLVL = 2, which calls sudotest.sh which gets SHLVL = 3.

One possible caveat to this is if you have an older version of sudo, where the tty_tickets option is not set, which removes the username+tty granularity for sudo sessions, and limits granularity only to username and timestamp.

Other sudoers options could potentially have an impact, too, like requiretty.

As long as subsequent calls to sudo from scripts called by the original shell are issued within the time limit on sudo credential retention, they will be able to elevate as the same user. Once the time limit is up, they'll need to have a way to re-enter the password if you want them to be able to continue elevating privileges. (or you could change the timeout, or disable password requirements for a user, or a command... but those are out of scope for this answer).

The answer is no. Try sudo id followed by id to verify.