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.

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.

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.

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).

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*

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.

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

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

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.

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

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.

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).