[3-in-1 bug] pam-u2f silently fails if /etc/security/pam_u2f.conf is not correctly formatted or have bad permissions

[ConradGyllenhaal]

What version of pam-u2f are you using?

1.4.0 from Fedora 43 repository

What operating system are you using?

Fedora 43

What authenticator are you using?

Yubikey 5

Problem description

If the syntax of the file /etc/security/pam_u2f.conf is not correct, like missing a new line at the end of the file, pam-u2f silently fails, even in debug mode (set in /etc/authselect/system-auth, at the line for pam_u2f.so).

In the same way, if the /etc/security/pam_u2f.conf file has too broad permissions (664), pam-u2f silently fails, even in debug mode. It has to be 644 at best.

By the way, if this /etc/security/pam_u2f.conf file exists, and if arguments are also passed in the pam configuration file (under /etc/pam.d/ or /etc/authselect/), the arguments are ignored.

Here is the output of such a run (valid /etc/security/pam_u2f.conf, but with too broad permissions 664, and arguments passed through /etc/authselect/system-auth):

su user
debug(pam_u2f): cfg.c:272 (cfg_init): called.
debug(pam_u2f): cfg.c:273 (cfg_init): flags 0 argc 4
debug(pam_u2f): cfg.c:275 (cfg_init): argv[0]=authfile=/etc/u2f_mappings
debug(pam_u2f): cfg.c:275 (cfg_init): argv[1]=origin=pam://errorprone
debug(pam_u2f): cfg.c:275 (cfg_init): argv[2]=cue
debug(pam_u2f): cfg.c:275 (cfg_init): argv[3]=debug
debug(pam_u2f): cfg.c:277 (cfg_init): max_devices=0
debug(pam_u2f): cfg.c:278 (cfg_init): debug=1
debug(pam_u2f): cfg.c:279 (cfg_init): interactive=0
debug(pam_u2f): cfg.c:280 (cfg_init): cue=0
debug(pam_u2f): cfg.c:281 (cfg_init): nodetect=0
debug(pam_u2f): cfg.c:282 (cfg_init): userpresence=-1
debug(pam_u2f): cfg.c:283 (cfg_init): userverification=-1
debug(pam_u2f): cfg.c:284 (cfg_init): pinverification=-1
debug(pam_u2f): cfg.c:285 (cfg_init): manual=0
debug(pam_u2f): cfg.c:286 (cfg_init): nouserok=0
debug(pam_u2f): cfg.c:287 (cfg_init): openasuser=0
debug(pam_u2f): cfg.c:288 (cfg_init): alwaysok=0
debug(pam_u2f): cfg.c:289 (cfg_init): sshformat=0
debug(pam_u2f): cfg.c:290 (cfg_init): expand=0
debug(pam_u2f): cfg.c:291 (cfg_init): authfile=(null)
debug(pam_u2f): cfg.c:292 (cfg_init): authpending_file=(null)
debug(pam_u2f): cfg.c:294 (cfg_init): origin=(null)
debug(pam_u2f): cfg.c:295 (cfg_init): appid=(null)
debug(pam_u2f): cfg.c:296 (cfg_init): prompt=(null)
su: Authentication failure

[dacav]

Hi, @ConradGyllenhaal

I did a quick set-up in a Fedora 43 container, so we are on the same page:

[root@aef459787398 /]# cat /etc/fedora-release
Fedora release 43 (Forty Three)
[root@aef459787398 /]# grep pam_u2f /etc/authselect/system-auth
auth        sufficient                                   pam_u2f.so debug debug_file=stderr

Here's my /etc/security/pam_u2f.conf file: garbage + new line + valid configuration, missing new line at the end of file:

[root@5230ddeaff38 /]# xxd /etc/security/pam_u2f.conf
00000000: 666b 646a 6b64 666a 6173 6b6c 6673 6461  fkdjkdfjasklfsda
00000010: 2121 210a 7072 6f6d 7074 3d68 656c 6f    !!!.prompt=helo

And here's an authentication for a user dude.

[root@5230ddeaff38 /]# sudo -u dude sudo echo
debug(pam_u2f): cfg.c:272 (cfg_init): called.
debug(pam_u2f): cfg.c:273 (cfg_init): flags 32768 argc 2
debug(pam_u2f): cfg.c:275 (cfg_init): argv[0]=debug
debug(pam_u2f): cfg.c:275 (cfg_init): argv[1]=debug_file=stderr
debug(pam_u2f): cfg.c:277 (cfg_init): max_devices=0
debug(pam_u2f): cfg.c:278 (cfg_init): debug=1
debug(pam_u2f): cfg.c:279 (cfg_init): interactive=0
debug(pam_u2f): cfg.c:280 (cfg_init): cue=0
debug(pam_u2f): cfg.c:281 (cfg_init): nodetect=0
debug(pam_u2f): cfg.c:282 (cfg_init): userpresence=-1
debug(pam_u2f): cfg.c:283 (cfg_init): userverification=-1
debug(pam_u2f): cfg.c:284 (cfg_init): pinverification=-1
debug(pam_u2f): cfg.c:285 (cfg_init): manual=0
debug(pam_u2f): cfg.c:286 (cfg_init): nouserok=0
debug(pam_u2f): cfg.c:287 (cfg_init): openasuser=0
debug(pam_u2f): cfg.c:288 (cfg_init): alwaysok=0
debug(pam_u2f): cfg.c:289 (cfg_init): sshformat=0
debug(pam_u2f): cfg.c:290 (cfg_init): expand=0
debug(pam_u2f): cfg.c:291 (cfg_init): authfile=(null)
debug(pam_u2f): cfg.c:292 (cfg_init): authpending_file=(null)
debug(pam_u2f): cfg.c:294 (cfg_init): origin=(null)
debug(pam_u2f): cfg.c:295 (cfg_init): appid=(null)
debug(pam_u2f): cfg.c:296 (cfg_init): prompt=helo

If the syntax of the file /etc/security/pam_u2f.conf is not correct, like missing a new line at the end of the file, pam-u2f silently fails, even in debug mode (set in /etc/authselect/system-auth, at the line for pam_u2f.so).

The configuration file is accepted, so I believe that by "silently fails" you mean that the garbage line is ignored.
I agree that pam_u2f.so is a bit stingy with details: at least for now, the detection of a wrong setting needs to rely on the debug output not reporting the expected configuration.

On a minor note, a missing new line at the end of the file does not seem to be a problem.

if the /etc/security/pam_u2f.conf file has too broad permissions (664), pam-u2f silently fails, even in debug mode. It has to be 644 at best.

The rejection of a config file with too broad permissions is on purpose. Again, I agree that pam_u2f.so is stingy with details.

By the way, if this /etc/security/pam_u2f.conf file exists, and if arguments are also passed in the pam configuration file (under /etc/pam.d/ or /etc/authselect/), the arguments are ignored.

The config file settings take lower priority, and the settings specified via arguments override them. This is intended and documented in the pam_u2f(8) manpage (under the CONFIGURATION FILE section)

[ConradGyllenhaal]

Hi @dacav,

Instead of providing "debug_file" parameter in the /etc/authselect/system-auth file, could you try to specify authfile, which is a reported parameter in the debug output?

I think you should then see that the parameter will be (null).

[dacav]

Hi @dacav,

Instead of providing "debug_file" parameter in the /etc/authselect/system-auth file, could you try to specify authfile, which is a reported parameter in the debug output?

I think you should then see that the parameter will be (null).

Here it follows, but the parameter is not (null):

[root@cc055df8899b /]# cat /etc/security/pam_u2f.conf 
debug
debug_file=stderr
[root@cc055df8899b /]# grep pam_u2f /etc/authselect/system-auth 
auth        sufficient                                   pam_u2f.so authfile=foobar
[root@cc055df8899b /]# sudo -u dude sudo echo
debug(pam_u2f): cfg.c:272 (cfg_init): called.
debug(pam_u2f): cfg.c:273 (cfg_init): flags 32768 argc 1
debug(pam_u2f): cfg.c:275 (cfg_init): argv[0]=authfile=foobar
debug(pam_u2f): cfg.c:277 (cfg_init): max_devices=0
debug(pam_u2f): cfg.c:278 (cfg_init): debug=1
debug(pam_u2f): cfg.c:279 (cfg_init): interactive=0
debug(pam_u2f): cfg.c:280 (cfg_init): cue=0
debug(pam_u2f): cfg.c:281 (cfg_init): nodetect=0
debug(pam_u2f): cfg.c:282 (cfg_init): userpresence=-1
debug(pam_u2f): cfg.c:283 (cfg_init): userverification=-1
debug(pam_u2f): cfg.c:284 (cfg_init): pinverification=-1
debug(pam_u2f): cfg.c:285 (cfg_init): manual=0
debug(pam_u2f): cfg.c:286 (cfg_init): nouserok=0
debug(pam_u2f): cfg.c:287 (cfg_init): openasuser=0
debug(pam_u2f): cfg.c:288 (cfg_init): alwaysok=0
debug(pam_u2f): cfg.c:289 (cfg_init): sshformat=0
debug(pam_u2f): cfg.c:290 (cfg_init): expand=0
debug(pam_u2f): cfg.c:291 (cfg_init): authfile=foobar
debug(pam_u2f): cfg.c:292 (cfg_init): authpending_file=(null)
debug(pam_u2f): cfg.c:294 (cfg_init): origin=(null)
debug(pam_u2f): cfg.c:295 (cfg_init): appid=(null)
debug(pam_u2f): cfg.c:296 (cfg_init): prompt=(null)

[ConradGyllenhaal]

Ok, so could you please try this setup to narrow it down further:

Valid /etc/security/pam_u2f.conf file with a parameter authfile=/dev/a, but with too broad permissions (664).
Valid /etc/authselect/system-auth with the same parameter, but targeting another file (authfile=/dev/b).

In the debug output, you shouldn't have this parameter kept (neither /dev/a nor /dev/b).

[dacav]

Hi, @ConradGyllenhaal

[root@13b153b51efc /]# grep pam_u2f /etc/authselect/system-auth 
auth        sufficient                                   pam_u2f.so debug authfile=/dev/b
[root@13b153b51efc /]# cat /etc/security/pam_u2f.conf 
authfile=/dev/a
[root@13b153b51efc /]# sudo -u dude sudo echo
debug(pam_u2f): cfg.c:272 (cfg_init): called.
debug(pam_u2f): cfg.c:273 (cfg_init): flags 32768 argc 2
debug(pam_u2f): cfg.c:275 (cfg_init): argv[0]=debug
debug(pam_u2f): cfg.c:275 (cfg_init): argv[1]=authfile=/dev/b
debug(pam_u2f): cfg.c:277 (cfg_init): max_devices=0
debug(pam_u2f): cfg.c:278 (cfg_init): debug=1
debug(pam_u2f): cfg.c:279 (cfg_init): interactive=0
debug(pam_u2f): cfg.c:280 (cfg_init): cue=0
debug(pam_u2f): cfg.c:281 (cfg_init): nodetect=0
debug(pam_u2f): cfg.c:282 (cfg_init): userpresence=-1
debug(pam_u2f): cfg.c:283 (cfg_init): userverification=-1
debug(pam_u2f): cfg.c:284 (cfg_init): pinverification=-1
debug(pam_u2f): cfg.c:285 (cfg_init): manual=0
debug(pam_u2f): cfg.c:286 (cfg_init): nouserok=0
debug(pam_u2f): cfg.c:287 (cfg_init): openasuser=0
debug(pam_u2f): cfg.c:288 (cfg_init): alwaysok=0
debug(pam_u2f): cfg.c:289 (cfg_init): sshformat=0
debug(pam_u2f): cfg.c:290 (cfg_init): expand=0
debug(pam_u2f): cfg.c:291 (cfg_init): authfile=(null)
debug(pam_u2f): cfg.c:292 (cfg_init): authpending_file=(null)
debug(pam_u2f): cfg.c:294 (cfg_init): origin=(null)
debug(pam_u2f): cfg.c:295 (cfg_init): appid=(null)
debug(pam_u2f): cfg.c:296 (cfg_init): prompt=(null)

This is the output.

The /etc/security/pam_u2f.conf is (unfortunately silently, yes) discarded. The parsing returns EINVAL ( https://github.com/Yubico/pam-u2f/blob/main/cfg.c#L111) and the whole procedure fails with PAM_SERVICE_ERR (https://github.com/Yubico/pam-u2f/blob/main/cfg.c#L223).

Reason: with security in mind, it is sensible to deny authentication, if the config file permission is too broad.

But I agree that the debug output is not very helpful here.