Should login_duo still exec a shell when auth doesn't occur?

[z-tb]

Summary

I noticed login_duo starts a shell whenever it is executed without arguments. Is this the desired behavior? I was expecting the shell spawn to fail if login_duo never makes it to a 2FA session. Looking at line 165 in login_duo.c, it seems that cfg.failmode is not initialized to site preferences since login_duo.conf cannot be read. A shell is still started anyway. It doesn't seem to matter that login_duo is SUID root.

Steps to reproduce

1. run login_duo with no parameters

$ echo $SHLVL
1
$ ./login_duo 
Couldn't open /etc/duo/login_duo.conf: Permission denied

2. Notice $SHLVL has increased

$ echo $SHLVL
2

Specs

• OS version Ubuntu 16.04
• OS arch x86_64
• Using login_duo

[vbscott]

Hello,
Thank you for your concern. This is actually the defaulted behavior. Because this is a configuration error we set the failmode to safe. In login_duo we open the shell by calling execl(const char *path, const char *arg, ...) with the parameters path = "bin/bash" and arg = "-bash" in the function do_exec. In this instance the last call to execl in the code will be the one that executes.

[z-tb]

Hrm.. I can see the conundrum on how to handle configuration errors. blocking logins because of a config error seems less than ideal but not so sure I want a shell started when there is an error with the config or perms are set incorrectly. I'm thinking about adding a cli flag to login_duo to control the default behavior so it would be consistent with my configuration. Would you be interested in a pull request if I do?

[vbscott]

Have you tried using /usr/local/sbin/login_duo instead? It should not have the same issue with permissions. The Makefile in login_duo sets the permissions of /usr/local/sbin/login_duo for the user and group to root. Because root owns the login_duo executable instead of your user, login_duo is able to access the login_duo.conf file and will not have the same issue opening the configure file. Alternatively if you want to use the login_duo executable in the login_duo/ directory you can change the executable's permissions to 4755 and for root to own it.

[z-tb]

Hi. My ./login_duo command above is actually being executed from /usr/local/duo/sbin so it does execute the SUID binary. Here are the perms on my login_duo

-rwsr-xr-x 1 root root 302856 Mar 22 13:46 login_duo

When login_duo is run by a "user", it fails straight away with permission denied and a shell is started. I was not expecting this error since the binary is already 4755. Shouldn't the read on the file essentially be performed as root? I haven't fully looked through the code but maybe this read is occurring with the user context instead when do_auth() is called with ctx?

Running the command through strace seems to show a failing read of /etc/duo/login_duo.conf which really seems opposite of what 4755 on the binary should be doing.

close(3)                                = 0
open("/etc/duo/login_duo.conf", O_RDONLY) = -1 EACCES (Permission denied)
write(2, "Couldn't open /etc/duo/login_duo"..., 57Couldn't open /etc/duo/login_duo.conf: Permission denied
) = 57
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3

The permissions on my /etc/duo/login_duo.conf are set like this since my OpenLDAP server needs to read this file as well (it is in the sasl group):

# dir /etc/duo/login_duo.conf 
-rw-r----- 1 root sasl 576 May 30 14:17 /etc/duo/login_duo.conf

Am I totally missing something? Perhaps I've borked something during the install..

[vbscott]

If you do not run the binary as root then the login_duo.conf read is done with the DUO_PRIVSEP_USER, which is sshd by default but can be changed by using the --with-privsep-user= flag when configuring duo_unix. DUO_PRIVSEP_USER is the privilege separation user which is why we set the owner to the file to DUO_PRIVSEP_USER by default in login_duo/Makefile.am. The privileges are changed to the sshd user in drop privileges. You're permissions error is from having the owner of /etc/duo/login_duo.conf be root because the sshd user does not have access to read the file.
You are going to have another issue with the permissions on your /etc/duo/login_duo.conf file. /etc/duo/login_duo.conf should only be readable by the owner and not the group of the file. This is to keep your secret key safe by making it only readable by the owner.

[z-tb]

Thanks for clarifying. It makes a little more sense now.

[vbscott]

Thanks for the issue. I am going to close this out but feel free to reopen it if you have anymore questions.