Grant dwm permission to shutdown but not other programs

Miy · 2022-12-24 16:17:04

Hello, Arch community!

I want to use a dwm shortcut to shut down my PC. I used this suggestion to add the shutdown command and the shortcut to the config.h file. (thread)

This is my config.h file:

...
/* commands */
static char dmenumon[2] = "0"; /* component of dmenucmd, manipulated in spawn() */
static const char *dmenucmd[] = { "dmenu_run", "-m", dmenumon, "-fn", dmenufont, "-nb", col_gray1, "-nf", col_gray3, "-sb", col_cyan, "-sf", col_gray4, NULL };
static const char *termcmd[]  = { "st", NULL };
static const char *shutdowncmd[] = { "sudo", "shutdown","-h", "now", NULL };

static const Key keys[] = {
        /* modifier                     key        function        argument */
        { MODKEY,                       XK_p,      spawn,          {.v = dmenucmd } },
        { MODKEY|ShiftMask,             XK_Return, spawn,          {.v = termcmd } },
        { MODKEY|ControlMask|ShiftMask, XK_q,      spawn,          {.v = shutdowncmd } },
        { MODKEY,                       XK_b,      togglebar,      {0} },
        { MODKEY,                       XK_b,      togglebar,      {0} },
...

I faced the issue that this approach requires user to have permissions to use shutdown without password, since sudo demands it via interactive mode otherwise. But my concern is that having this user permission any app would be able to run shutdown at its whim. It seems to me as overkill to give user permission to run shutdown without password only for the purpose of using a shortcut in a single program (dwm).

My question is: is there a way to grant dwm permission to shut down the PC without password at the same time not granting this permission to other programs? If so can I also not grant this permission to the user that ran dwm?

Thank you!

seth · 2022-12-24 21:30:36

my concern is that having this user permission any app would be able to run shutdown at its whim

If you have a properly activated session using logind (I guess: see the last link below) you can shutdown the system anyway.

Otherwise you could elevate some special group in your sudoers and own the dwm binary to that group and set the GUID bit.

Ftr:

since sudo demands it via interactive mode

"somewhat", you could utilize pkexec instead or for sudo, feed it a password from stdin, eg.

dmenu -p Password < /dev/null | sudo -S shutdown

Trilby · 2022-12-24 22:05:35

dwm doesn't run any shutdown command. Your configuration has a keybinding to run the "shutdown" command in a shell. If dwm, which runs as your user, can run a shell that runs the shutdown command, so can any other process that runs as your user.

seth's group suggestion wouldn't help much either as all dwm child processes would be effectively the same as the shell opened to run the shutdown command. So the regular terminal windows, or the dmenu menu, and any program launched from within either of those, or any other program started by a keybinding (e.g., a browser) or pretty much anything running in your graphical session would all have the same ability to run the shutdown command as dwm. This group approach would prevent some processes from being able to run `shutdown' (e.g., system services) but that's rather a moot point as those services run as root anyways, so they already could have run `shutdown'.

The only way I can think of to even approach your goal is to first set aside the idea of running any shell command from the key binding, but instead write your own function in config.h that wil fork and exec a program itself. This exec call could be given a different argv[0] than the basename of the path; you'd then create another program (likely setuid) that checks argv[0] and only continues if it matches what you set in config.h as the argv[0] name in the exec call - and then this program triggers a shutdown.

However, even this would be only security through obscurity. No other process could call the setuid binary by name as it would exit without doing anything - but anyone who knew what it was could call it with the substituted argv[0] to get it to shutdown the system.

Some semi-pseudo-code for this:

// in config.h
int myshutdownfunc() {
   if (fork() != 0) return 0;
   // TODO: close some fds and adjust signals as needed here
   if (fork() != 0) _exit(0);
   execl("/path/to/your/special/binary", "fakenamehere", NULL);
   _exit(1);
}
// TODO bind key to call myshutdownfunc

// meat of your special binary (which will get the sticky bit set):
int main(int argc, const char *argv[]) {
   if (strncmp(argv[0], "fakenamehere", 12) != 0) return 1;
   execl("/bin/shutdown", "shutdown", NULL);
   _exit(2);
}

Last edited by Trilby (2022-12-24 22:17:18)

seth · 2022-12-25 00:20:50

Does dwm disown shortcut-started processes? (If yes you'll have to bind a function, if that's possible)
If not (or you can bind a function) you could have it call script, have that script NOPASSWD in sudoers and discriminate the shutdown call by its $PPID's $PPID (testing exe or cmdline)

Miy · 2022-12-25 00:46:35

Thank you for response!

Trilby wrote:

So the regular terminal windows, or the dmenu menu, and any program launched from within either of those, or any other program started by a keybinding (e.g., a browser) or pretty much anything running in your graphical session would all have the same ability to run the shutdown command as dwm.

I came to the same conclusion that any program launched by dwm will have the same permissions as respective dwm session that are actually the permissions of the user who launched dwm in the first place.

I find it logical for programs to have their own permissions specifically for such situations. Say, I run dwm as root and I want to run a program P from it. P has an MIT license which means there is no guarantee of any kind, which in turn means that it can potentially be harmful or even malicious. So, isn't it natural that I don't want the permissions to propagate from the dwm to P? Suppose I thoroughly inspected dwm's source code for an extent enough for me to treat it as safe but I don't want to inspect the source code of every single program I install. Doesn't it make sense to be able to limit P's permissions?

Thank you!

jasonwryan · 2022-12-25 00:50:37

Miy wrote:

Say, I run dwm as root...

Whatever the reason is that you think you need to run dwm with elevated privileges is, it is a terrible idea.

Trilby · 2022-12-25 03:03:17

Miy wrote:

P has an MIT license which means there is no guarantee of any kind, which in turn means that it can potentially be harmful or even malicious.

That is a syntactically valid sentence, but in every other way that is completely nonsensical gibberish. A license guarantees nothing and malicious code could be shared under any license.

As for the rest of your post, a process can drop privileges quite easily, but that has no bearing on the rest of this thread. You want to grant access to run 'shutdown' with sudo with NOPASSWD in one context but not in any other context - the problem is that there is no criteria with which to differentiate those contexts. "P"s permissions are irrelevant - except to the extent that they are identical to the shell that is launched by dwm in order to call 'shutdown'. If the shell started by dwm to run 'shutdown' can do so with NOPASSWD then any other shell started by dwm ("P" or not) can also run 'shutdown' with NOPASSWD - the permssions of the shells or of "P" do not factor into it.

Last edited by Trilby (2022-12-25 03:06:17)

seth · 2022-12-25 08:16:25

On top of that and while reminding of the possibility to elevante rights w/o an interactive text shell (and even if such limitation would exist, you could still start a TE w/ the sudo command):

If you, right now, require root permissions to shut down the system and you did not explicitly alter the polkit rules to that effect:
Your session is most likely degenerated, which has repercussions beyond the topic of this thread.

Arch Linux

#1 2022-12-24 16:17:04

Grant dwm permission to shutdown but not other programs

#2 2022-12-24 21:30:36

Re: Grant dwm permission to shutdown but not other programs

#3 2022-12-24 22:05:35

Re: Grant dwm permission to shutdown but not other programs

#4 2022-12-25 00:20:50

Re: Grant dwm permission to shutdown but not other programs

#5 2022-12-25 00:46:35

Re: Grant dwm permission to shutdown but not other programs

#6 2022-12-25 00:50:37

Re: Grant dwm permission to shutdown but not other programs

#7 2022-12-25 03:03:17

Re: Grant dwm permission to shutdown but not other programs

#8 2022-12-25 08:16:25

Re: Grant dwm permission to shutdown but not other programs

Board footer