allow_user_owned_authorized_keys_file permits privilege escalation

[AlD]

This was already perfectly explained in https://sourceforge.net/p/pamsshagentauth/bugs/21/, so I'll just quote it here:

The option "allow_user_owned_authorized_keys_file" is very dangerous, and should be removed from the code as it has no reasonable use case. This is because the test for privilege escalation (the authorized keys file) can be modified without first passing the test, which permits an unauthenticated escalation.

Consider sudo. If an attacker was able to gain code execution ability as a user, and that user owned his authorized keys file, the attacker could simply replace the authorized keys file with one of his choosing and then sudo at will. This reduces sudo security to the equivalent of "NOPASSWD".

For the same reason, not only should the authorized keys file be owned by root, but neither it nor any containing directory (up to the root) should be writable by anybody other than root.

For any operation on the remote server that normally requires local authentication (e.g. passwd, chfn, ...), enabling allow_user_owned_authorized_keys_file is security-equivalent to not requiring authentication, by the same argument. The only use case where escalation is not a danger is remote login, but sshd implements this natively, and no other remote login method has ssh-agent available to it at authentication time.

[AlD]

He, curious. The way this was implemented actually makes sense. PAM_RUSER or SUDO_USER is supposed to be the "from" user. PAM_USER is supposed to be the destination user. Having the destination user be the owner of authorized_keys_file can make sense. In reality however, when I invoke pam_ssh_agent_auth from sudo on my Debian machine, ruser and user end up being the same, leading to the gaping security issue described above.

[jbeverly]

While I understand and appreciate the risk the option exposes, I also know that the organization that requested its addition had a valid usecases for it that composes with other Pam modules such as pam_listfile, and others. So while I would never encourage its use, and would certainly never enable it by default, I also wouldn't presume that it "has no reasonable use case" because I lack the omnipotence necessary to make that claim.

[jbeverly]

Is also note, just for anybody else reading this thread, the security hole, in the case of sudo, for example, is a reduction in security posture to an equivalent of using NOPASSWD in sudoers.

I'm not a fan of doing that either. But many seem to consider it a valid configuration.

[AlD]

Just to clarify: ruser and user both being set to the originating user is a bug, right? Maybe a sanity check should be added to pam_ssh_agent_auth to prevent this.