PAM authentication support about gensio

[cminyard]

On Tue, May 04, 2021 at 02:11:41AM -0700, Konrad Gräfe wrote: I am planning to implement PAM authentication support on behalf of @AEberleMW. Our goal is to bring that into the mainline gensio project. To make that process as simple as possible I'd like to discuss a few details beforehand: - What is your preferred coding style? In the `certauth` code I saw a mixture of tabs and spaces which seems a bit uncommon to me.

It's 4 character indent, and tabs are ok for indenting in 8 characters increments.

- I would name it `pamauth`.

That sounds good.

- I am still at the start of my research but I think gensios are strictly non-blocking while PAM authentication is designed to block until a response is present. Therefore we may need to spawn a thread handling the PAM authentication.

Yeah, that's a bit of a pain. The code in tools/gtlsshd.c does PAM authentication, basically like you want. It uses the blocking version of the gensio calls to accomplish this. In general that program will be very helpful to you as an example.

- `certauth` runs its own custom protocol on top of the underlying gensio, so we are free to define our own protocol in `pamauth`, correct? I'd probably try to serialize and transfer [PAM structures](https://linux.die.net/man/3/pam_conv).

You shouldn't need any protocol for this. certauth should already provide the username and password you need as part of its working. If the first password fails, PAM then uses normal I/O for asking for the next password. Again, tools/gtlsshd.c should provide examples of what you need.

- I am not yet sure why `certauth` is split into `lib/gensio_certauth.c` and `lib/gensio_filter_certauth.c` but I will probably get behind that.

There is a ton of common code that lib/gensio_base.c provides. It has the concept of "filters" and "lower layers", as described (to a limited extent) in include/gensio/gensio_base.h. That's something that needs some more extensive documentation. Filters provide protocol processing, lower layers provide interfaces to the interface below the layer. Anyway, gensio_base.c provides the base processing, timers, etc. for a layer. gensio_filter_certauth.c provides the filter portion, it's basically called to handle processing the data. gensio_ll_gensio.c provides the lower-level interface for interfacing the base code to the top of another gensio. And gensio_certauth.c puts all the pieces together. In this case, you won't have a connector gensio, just an accepter. You will also have gensio_acc_gensio.[ch] that handling stacking an accepting gensio on top of another accepting gensio. I can see a couple of approaches for doing this. One is to implement your own protocol for for doing this. Then, unless the protocol was exaclty like the certauth protocol, you couldn't use gtlssh to connect to it. And you wouldn't get certificate-based authentication unless you did that yourself. The other approach is to require certauth as the layer below this. Then you could do certificate authentication and use certauth to do all the protocol processing and use the usernames and passwords it provides for authentication. That would be a lot simpler and easier to do. Unless you have a reason to not do this, that's probably the best approach. If you take the second approach, I don't think you can use gensio_base for this. In fact, since you won't be doing any data handling, it would just become a hindrance. You will need more direct access to the certauth gensio callbacks. Unfortunately, I don't have a good example of what to do here. There are a few gensios that don't use gensio base because they are simple (file, echo, dummy) or they do unusual things (mux, stdio, mdns). Hopefully that will get you starting putting all the pieces together. Feel free to ask more questions. And if you want to jot down things that you needed to learn, I can take that and start to put together some documentation for writing your own gensio.

…

-corey

Please if you have any thoughts or hints cc @THerbrecher -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #26

[cminyard]

Any news on this? If you are still working on it that's fine, but if not, we should probably close this.

[konradgraefe]

I am still working on this. I got one month off from work, hence the delay.

My current state is at https://github.com/konradgraefe/gensio if you're interested. It's in a very rough state, though. Currently it is independent from certauth but can be stacked with it. The biggest TODO before cleaning everything up is finding a way for hidden password entry.

[cminyard]

On Thu, Jul 15, 2021 at 10:40:07PM -0700, Konrad Gräfe wrote: I am still working on this. I got one month off from work, hence the delay. My current state is at https://github.com/konradgraefe/gensio if you're interested. It's in a very rough state, though. Currently it is independent from certauth but can be stacked with it. The biggest TODO before cleaning everything up is finding a way for hidden password entry.

I looked at it a bit, and the style looks good. I don't see a way to do this easily without certauth, though. certauth is what provides the username, certificate, and password, and it handles the certificate challenge. Otherwise, you will have to write something on both ends to do all this stuff. And trust me, you don't want to do that if you can avoid it :).

…

-corey

[konradgraefe]

The reason why I'd like to keep it separated is that PAM supports more than authenticating just with user name and password (2FA, etc.) through plugins and I'd like to support that, if possible.

[cminyard]

On Sun, Jul 18, 2021 at 10:50:14PM -0700, Konrad Gräfe wrote: The reason why I'd like to keep it separated is that PAM supports more than authenticating just with user name and password (2FA, etc.) through plugins and I'd like to support that, if possible.

Well, true, but 2FA still uses a username and password, and then adds another authentication step after that. So you still have to transfer a username and password securely. certauth also handles certificate authentication, which is arguably a lot more secure than passwords. But I'm fairly sure it would be easier to use certauth to handle the user/password/certificate and then do the second level authentication after, or to add a second authentication token to certauth that it transfers for you. That would be easy to add.

…

-corey

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #26 (comment)

[cminyard]

Any news on this? It's been a while.

[AEberleMW]

Hi @cminyard,

we had many resource problems in the last months so there was no time to schedule this issue. But we are definitely planning to implement the task within this year.

So would it be OK for you to keep this issue open? I will get in touch with you when we resume the work.

Best,
Marco

[cminyard]

On Sun, Jan 23, 2022 at 11:49:36PM -0800, Marco Wenzel wrote: Hi @cminyard, we had many resource problems in the last months so there was no time to schedule this issue. But we are definitely planning to implement the task within this year. So would it be OK for you to keep this issue open? I will get in touch with you when we resume the work.

That's fine, I was just going through the issues that hand't been touched in a while.

[konradgraefe]

Resolved via cminyard/ser2net#66