Passwordless root execution in scripts

siva · 2019-07-06 18:44:02

I know what you're thinking, but bear with me. I'm not sure the best way to phrase the question. So, please consider the following situation.

I want to run a script with the following conditions:

- The script has to execute a task that only root can perform
- The script can only be executed as a user
- The user cannot be prompted to enter a password
- The user cannot execute the script by logging in as root or using sudo
- The user can log in as root or use sudo to modify permissions
- The commands su or sudo can be used in the script
- visudo cannot be accessed or modified

An example script could look like the following:

#!/bin/sh

tcpdump -h

But, please don't link me to the guides on running tcpdump as non-root. If it's easier to follow, replace the command with any other app that, by default, requires root.

Alright, here's the section where I explain why I'm asking this.

Simply put, if I've ever had a script that needs to do this, I just do something like sudo tcpdump -h (using the previous example as a reference) and add a line to visudo. On the other hand, apps like wicd seem to only need group access in order to perform wpasupplicant tasks (wireshark to perform tcpdump, etc). I'm wondering how these are configured to do so.

I skimmed the wicd source and, maybe I'm looking in the wrong places, but I'm not really finding anything.

Last edited by siva (2019-07-06 18:45:03)

chris2be8 · 2019-07-06 19:58:54

You can set up entries in /etc/sudoers to let members of a given group (or specific individuals) run specific commands via sudo without asking for a password. See the man page for sudoers for examples (and caveats).

Note that it's often safer to let them run a script you've written as root since the script can do any necessary checks before doing anything dangerous.

Chris

Head_on_a_Stick · 2019-07-06 20:45:19

siva wrote:

apps like wicd seem to only need group access in order to perform wpasupplicant tasks (wireshark to perform tcpdump, etc). I'm wondering how these are configured to do so.

The devices are under the ownership of the relevant groups, for example:

E485:~$ find /dev -group netdev
/dev/rfkill
E485:~$ ls -l /dev/rfkill
crw-rw-r-- 1 root netdev 10, 58 Jul  6 20:45 /dev/rfkill
E485:~$

So users in the netdev group can use rfkill(8).

siva · 2019-12-10 01:06:20

I think what I'm looking for might be setuid: something like root:netdev ownership and 4750 permissions. It looks like this is a contentious solution for scripts, as opposed to binaries.

I read that if someone were to compromise the setuid binary, it would widen the attack surface. Then again, to do something like that, I imagine they'd need root access -- so, I'm not sure I understand or appreciate the difference.

HevyDevy · 2019-12-10 13:57:30

siva wrote:

I think what I'm looking for might be setuid: something like root:netdev ownership and 4750 permissions. It looks like this is a contentious solution for scripts, as opposed to binaries.
I read that if someone were to compromise the setuid binary, it would widen the attack surface. Then again, to do something like that, I imagine they'd need root access -- so, I'm not sure I understand or appreciate the difference.

You might get some hints from https://manpages.debian.org/stretch/xse … .5.en.html

Last edited by HevyDevy (2019-12-10 13:58:12)

siva · 2019-12-10 20:18:31

Thanks, I will give this a read. This is all uncharted territory for me.

HevyDevy · 2019-12-11 11:16:04

siva wrote:

Thanks, I will give this a read. This is all uncharted territory for me.

Me too, ive no experience with any of this but i found it interesting when i came across how Xorg.wrap works with suid.

Head_on_a_Stick · 2019-12-11 13:41:11

Isn't SUID X a bad idea?

I know Devuan doesn't need a wrapper for rootless X any more.

jaromil · 2019-12-12 10:23:27

This software may be useful for your use-case: https://sup.dyne.org/

There is also a more minimalist (suckless) version that parazyd maintains here http://parazyd.org/git/sup/log.html

HevyDevy · 2019-12-12 14:28:21

jaromil wrote:

This software may be useful for your use-case: https://sup.dyne.org/
There is also a more minimalist (suckless) version that parazyd maintains here http://parazyd.org/git/sup/log.html

Im considering using sup, looks to be a more simple way of privilege escalation in a higher order programming language. Im already using many of the suckless tools for my setup so i should probably add this and test it.

siva · 2019-12-13 03:57:21

jaromil wrote:

This software may be useful for your use-case: https://sup.dyne.org/
There is also a more minimalist (suckless) version that parazyd maintains here http://parazyd.org/git/sup/log.html

This looks great. Can't wait to try it out. Thanks, jaromil.

UPDATE: Weird, parazyd's version won't run the command as root (setgid failed) unless "sudo" is prepended. But, it looks liket the permissions are set correctly.

-rws--x--x 1 omega staff 763024 Dec 13 05:22 /usr/local/bin/sup*

Last edited by siva (2019-12-13 05:24:28)

ralph.ronnquist · 2019-12-13 12:02:00

The SUID bit makes the executable run as the owner of the executable.

GNUser · 2019-12-13 14:45:43

Even if user makes a shell script SUID, the linux kernel will ignore it because it's a major security risk. https://unix.stackexchange.com/a/2910

Here is a simple demonstration of how SUID is set, but kernel ignores it:

$ echo '#!/bin/sh
apt update' >testing
$ chmod a+x ./testing
$ sudo chown root:root ./testing
$ sudo chmod u+s ./testing
$ ls -l ./testing
-rwsr-xr-x 1 root root 21 Dec 13 09:43 ./testing # the 's' shows that SUID bit is set
$ ./testing
Reading package lists... Done
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (1: Operation not permitted)
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)

Permission is denied because the script is running as regular user, not root (i.e., SUID was ignored).

Last edited by GNUser (2019-12-13 14:46:52)

GNUser · 2019-12-13 15:19:26

jaromil - thank you for pointing out sup, I wasn't aware of it. I love it already. Small is beautiful!

HevyDevy · 2019-12-14 09:18:50

siva wrote:

jaromil wrote:
This software may be useful for your use-case: https://sup.dyne.org/
There is also a more minimalist (suckless) version that parazyd maintains here http://parazyd.org/git/sup/log.html
This looks great. Can't wait to try it out. Thanks, jaromil.
UPDATE: Weird, parazyd's version won't run the command as root (setgid failed) unless "sudo" is prepended. But, it looks liket the permissions are set correctly.
-rws--x--x 1 omega staff 763024 Dec 13 05:22 /usr/local/bin/sup*

Tried this out today, parazyd version. Would be even better if it were hooked into bash-completion somehow.
Bit tedious getting all the programs you want run as root via the user.

jaromil · 2019-12-15 12:50:58

HevyDevy wrote:

Tried this out today, parazyd version. Would be even better if it were hooked into bash-completion somehow.
Bit tedious getting all the programs you want run as root via the user.

do you mean having "sup [tab]" and complete with a list of commands configured?

interesting feature indeed, shell code could be generated by sup.

HevyDevy · 2019-12-15 13:21:56

jaromil wrote:

HevyDevy wrote:
Tried this out today, parazyd version. Would be even better if it were hooked into bash-completion somehow.
Bit tedious getting all the programs you want run as root via the user.
do you mean having "sup [tab]" and complete with a list of commands configured?
interesting feature indeed, shell code could be generated by sup.

yes that would be a nice patch.

The officially official Devuan Forum!

#1 2019-07-06 18:44:02

Passwordless root execution in scripts

#2 2019-07-06 19:58:54

Re: Passwordless root execution in scripts

#3 2019-07-06 20:45:19

Re: Passwordless root execution in scripts

#4 2019-12-10 01:06:20

Re: Passwordless root execution in scripts

#5 2019-12-10 13:57:30

Re: Passwordless root execution in scripts

#6 2019-12-10 20:18:31

Re: Passwordless root execution in scripts

#7 2019-12-11 11:16:04

Re: Passwordless root execution in scripts

#8 2019-12-11 13:41:11

Re: Passwordless root execution in scripts

#9 2019-12-12 10:23:27

Re: Passwordless root execution in scripts

#10 2019-12-12 14:28:21

Re: Passwordless root execution in scripts

#11 2019-12-13 03:57:21

Re: Passwordless root execution in scripts

#12 2019-12-13 12:02:00

Re: Passwordless root execution in scripts

#13 2019-12-13 14:45:43

Re: Passwordless root execution in scripts

#14 2019-12-13 15:19:26

Re: Passwordless root execution in scripts

#15 2019-12-14 09:18:50

Re: Passwordless root execution in scripts

#16 2019-12-15 12:50:58

Re: Passwordless root execution in scripts

#17 2019-12-15 13:21:56

Re: Passwordless root execution in scripts

Board footer