3

I've run across a dilemma with PAM RADIUS authentication for the database layer. In our environment, the OS login authenticates via PAM to a RADIUS server which accepts a token code and authenticates based on the time-based token and PIN. Because the RADIUS shared secret is available in plain text in the /etc/raddb/server file, we believe it's not appropriate to grant access to this file to any account other than root.

However, when a database or other application which does not run as root (in this particular case, the program in question is MySQL and runs as the "mysql" user) is required to authenticate to RADIUS, it needs to be able to read the /etc/raddb/server file so the PAM library (which runs with the privileges of the caller) knows how to access the RADIUS server. Because of the need to protect the shared secret, this means that processes not running as root cannot authenticate via PAM RADIUS.

We've considered several options and found all of them lacking:

  • Setting the setuid bit on the chk-passwd helper binary does not seem to cover all of the cases where MySQL must authenticate to RADIUS.
  • Setting the setuid bit on the mysqld binary defeats the purpose of running this process as mysql in the first place.
  • Setting the SELinux capabilities on either binary seems to be equivalent to setting the setuid bit.
  • Setting group permission on the /etc/raddb/server file to mysql and allowing group read seems like it would be opening yet another can of worms.

Is there really no hope of allowing a process running as a lesser-privileged user to authenticate to PAM RADIUS?

  • You might want to look into SASL, which is traditionally a glue mechanism between servers which don't have the privs (like SMTP and IMAP servers) and the authentication services which they need to work with. – gowenfawr Jan 12 '18 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.