[PATCH RFC] Expose authentication information in the environment (PAM & shell)

[Vincent Brillault]

Dear all,

I believe that my last email to the list, in November, got unfortunately
lost for most people due to the 'DMARC' configuration on the domain I
was using. I'm now using another email address, that will hopefully work
this time... Here is the content of my previous email:

On Thu 26.Nov'15 at 21:32:05 +0100, Vincent Brillault wrote:
> Following a discussion of last June and the resulting bug (2408), in
> order to improve 2 factor authentication, I've worked on a set of
> patches to expose at least basic authentication information and more
> when possible. By exposing such information to PAM, it would be possible
> to differentiate the cases when PAM is called first and when it is
> called after a valid authentication (e.g. when using
> AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam
> publickey,keyboard-interactive:pam keyboard-interactive:pam)
> 
> The design of these patches is rather simple:
> - Authentication method can "publish" detailed information about the
>   client, if the authentication was successful
> - In the main auth 2 loop, after a successful authentication, the
>   authentication method is recorded, including details if provided
> - When calling PAM or a shell, export this information via an
>   environment variable
> 
> I've tried to keep the patches as small and atomic as possible.
> The larger change is probably the introduction of 'pubkey_format' in
> order to only have one function to print a public key.
> 
> This set of patch could be extended to cover more ground, but I not sure
> how and thus I'm open to suggestions and ideas on how:
> - to expose the same kind of detailed information from the priviledged
>   thread in case of priviledge separation
> - to produce the same kind of information from other authentication
>   methods (I'm particularly interested in getting the kerbors principal
>   from gss-serv-krb5 for example)
> 
> Resolving such questions would probably make this feature complete, but
> I fear that they need complex modifications of the existing code. Do you
> think that this design and this first step could be considered and
> merged first, without closing the door for further improvement?

What is the standard procedure or what would be the preferred way of
sharing these patches? Send the aggerated patch in one email? Send all
the atomic patch in a single email? Use git send email to send atomic
patches as 9 emails plus header?
In the mean time, the patches are available:
- Via the bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=2408
- On GitHub: https://github.com/CERN-CERT/openssh-portable (last 9)

I've also published a small explanation on why we are doing it:
https://cern-cert.github.io/pam_2fa/

Thanks in advance for your comments,
Vincent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160114/2f133e42/attachment.bin>