Ho incontrato un dilemma con l'autenticazione PAM RADIUS per il livello del database. Nel nostro ambiente, l'accesso al sistema operativo viene autenticato tramite PAM su un server RADIUS che accetta un codice token e autentica in base al token e al PIN basati sul tempo. Poiché il segreto condiviso RADIUS è disponibile in formato testo nel file / etc / raddb / server, riteniamo che non sia appropriato concedere l'accesso a questo file a qualsiasi account diverso da root.
Tuttavia, quando un database o un'altra applicazione che non viene eseguita come root (in questo caso particolare, il programma in questione è MySQL e viene eseguito come utente "mysql") è necessario per l'autenticazione su RADIUS, deve essere in grado leggere il file / etc / raddb / server in modo che la libreria PAM (che viene eseguita con i privilegi del chiamante) sappia come accedere al server RADIUS. A causa della necessità di proteggere il segreto condiviso, ciò significa che i processi non in esecuzione come root non possono essere autenticati tramite PAM RADIUS.
Abbiamo preso in considerazione diverse opzioni e le abbiamo trovate tutte carenti:
- L'impostazione del bit setuid sul file binario helper chk-passwd non sembra coprire tutti i casi in cui MySQL deve autenticarsi su RADIUS.
- L'impostazione del bit setuid sul binario mysqld vanifica lo scopo di eseguire questo processo come mysql in primo luogo.
- L'impostazione delle capacità di SELinux su entrambi i binari sembra essere equivalente all'impostazione del bit setuid.
- Impostare l'autorizzazione di gruppo sul file / etc / raddb / server su mysql e consentire la lettura di gruppo sembra come se stesse aprendo un altro barattolo di worm.
Non c'è davvero alcuna speranza di consentire a un processo in esecuzione come utente con privilegi minori di autenticarsi su PAM RADIUS?