3 ms·

PAM? Really? I think a better goal would be to create an entirely new design, with a decent scripting language for expressing which authentication/authorizati

by amluto 3y ago

PAM? Really? I think a better goal would be to create an entirely new design, with a decent scripting language for expressing which authentication/authorization queries to do and when to succeed (which PAM config files, ahem, are not), and get distros to use it. And maybe allow loading legacy PAM modules as an optional feature. (Aside from all the obvious suckage, I have my personal pet peeve: it’s been how many years, and we still can’t grant ambient capabilities using PAM?)

deleted 3y ago
[deleted]
kaba0 3y ago
I agree with you - the linux ecosystem is very impressive, up until the user-space (with many exceptions of course). I usually never recommend starting from scratch, and we should definitely strive for proper backwards compatibility, but I don’t feel much would be lost by leaving behind the whole, unsecure C programs of contemporary linux distros. Like, why does it still have to be C, didn’t we learn a bit from all those vulnerabilities?!
- amluto 3y ago
  The problem with PAM isn’t (IMO) that it’s written in C. The problems are that the entire design is horrible, the configuration abilities are horrible, the maintenance seems pretty bad (not much changes these days), and the ability to actually interact with PAM during authentication is quite weak. The latter is a functionality weakness (e.g. doing anything useful using PAM when accessing a system over SSH or HTTPS or really anything else is a mess and not terribly useful, but it also makes the fact that PAM is written in C be less of a problem: there is so little untrusted input available to PAM that it’s not a very easy target. What PAM needs is a redesign. A different language would just be icing on the cake.
  - infogulch 3y ago
    I bet you could map a Linux user space authorization environment to an authzed schema and define permissions that way. https://authzed.com/docs https://authzed.com/docs
yencabulator 3y ago
Authentication should just be another service you talk to over UNIX domain sockets. The dynamic library design is a huge problem, and changing the configuration language won't fix that.

by amluto 3y ago

deleted 3y ago

[deleted]

kaba0 3y ago

I agree with you - the linux ecosystem is very impressive, up until the user-space (with many exceptions of course). I usually never recommend starting from scratch, and we should definitely strive for proper backwards compatibility, but I don’t feel much would be lost by leaving behind the whole, unsecure C programs of contemporary linux distros. Like, why does it still have to be C, didn’t we learn a bit from all those vulnerabilities?!

amluto 3y ago
The problem with PAM isn’t (IMO) that it’s written in C. The problems are that the entire design is horrible, the configuration abilities are horrible, the maintenance seems pretty bad (not much changes these days), and the ability to actually interact with PAM during authentication is quite weak. The latter is a functionality weakness (e.g. doing anything useful using PAM when accessing a system over SSH or HTTPS or really anything else is a mess and not terribly useful, but it also makes the fact that PAM is written in C be less of a problem: there is so little untrusted input available to PAM that it’s not a very easy target. What PAM needs is a redesign. A different language would just be icing on the cake.
- infogulch 3y ago
  I bet you could map a Linux user space authorization environment to an authzed schema and define permissions that way. https://authzed.com/docs https://authzed.com/docs

yencabulator 3y ago

Authentication should just be another service you talk to over UNIX domain sockets. The dynamic library design is a huge problem, and changing the configuration language won't fix that.