Re: i3lock PAM Problem?

On Sun, Aug 04, 2013 at 04:24:48PM +0200, Oliver Fromme wrote:
>
> Dein Ansatz, stattdessen »auth include system« zu nehmen,
> war eigentlich schon ganz richtig. Aber der Haken an der
> Sache ist, dass nur root die verschlüsselten Passwörter
> (master.passwd) lesen und verifizieren kann. Wenn Du
> i3lock als normaler Benutzer startest, geht das nicht,
> daher wird kein Passwort als richtig akzeptiert.
>
> Du müsstest daher i3lock ein setuid-Bit spendieren:

Danke für die ausführliche Erklärung, war mir Anlaß, mich doch etwas
mit PAM zu beschäftigen. Zumindest das "Grobe" und speziell OpenPAM.

setuid hatte ich auch getestet (slock, ein anderer Screenlocker, hat
das per default schon gesetzt). Allerdings hatte ich beim setuid für
i3lock noch "auth include login" als Mechanismus aktiv - bin somit
wieder an pam_self.so gestoßen.
Für PAM system statt login einzubinden funktioniert, setuid
vorrausgesetzt. Genaugenommen reicht pam_unix als required für den
Screensaver aus (wenn man kein Opie/Kerberos/etc verwendet).

pam_self ist ja scheinbar eine Spezialität von OpenPAM. Mit meinem
bisher nur rudimentären Wissen von PAM stellt sich mir eigentlich
die Frage nach dem Nutzen von pam_self, zumindest oder speziell in
/etc/pam.d/login.
Ist das so richtig: Einem Programm, welches libpam-Funktionen
verwendet, wird durch pam_self im Modus sufficent ohne weiter
Prüfung die Authentifizierung ermöglicht wenn das aufrufende
Programm unter der (effektiven) UID des zu authentifizierenden Users
läuft? Das klingt für mich erstmal nicht so "sicher"...
Kennst Du andere nützliche/notwendige Vorteile für dieses Modul
abseits der (Shell)-Login-Spielerei, also warum dies in
/e/pam.d/login überhaupt drin ist? So aus der Hüfte geschossen würde
ich es lieber abstellen ;-) Aber ich lese und informiere mich schon
noch weiter...

> Der i3lock-Port ist in dieser Form jedenfalls nicht unter
> FreeBSD zu gebrauchen. Ich fürchte fast, der Maintainer
> des Ports hat ihn nie selbst ausprobiert. In der PAM-
> Konfiguration sollte jedenfalls system statt login stehen,
> und der Port sollte zumindest eine Option anbieten, um
> das Binary setuid-root zu machen.

i3lock kommt aus der gleichen "Ecke"(Author?) wie der i3
Windowmanager. Er soll weitgehend ein slock-Fork sein, während slock
aber wohl ohne PAM agiert(libcrypt gelinkt) nutzt i3lock halt PAM.
Aus der Linux-Ecke kommend ist der Default für PAM dann halt
passend. i3 WM (und Tools) sind eigentlich meine Wahl wenn ich einen
Tilling-Windowmanager nutzen will, gerade wegen dessen - für mich -
gelungenen Umsetzung bei Mehr-Monitor-Betrieb.
Ich werde i3lock also wohl vertrauen und es setuid setzen.

Für den Port werde ich mich an einem "Patch" versuchen ;-) und einen
Bugreport schreiben, oder zumindest den Maintainer kontaktieren.

Zu setuid nochmal (ich werde auch selbst suchen, aber evtl. kannst
du das schnell (er)klären):
Unter Linux gibt es durch die Kernel-CAPabilities die Möglichkeit,
Programme wie z.B. ping nicht mehr setuid setzen zu müssen, sondern
ihnen stattdessen benötigte (Root-)Rechte eben speziell anhand der
Funktionalität (hier dann net_raw für TCP-Stack/Netzdevice)
zuzuteilen. Gibt es unter FreeBSD vergleichbares, evtl. über MAC?
Ich habe das Handbuch zu MAC zur mal grob überflogen. Könnte man bei
ping unter BSD auf setuid verzichtet?

>
> Gruß
> Olli

Danke, und ein schönes Rest-WE.
Gruß
        Gerhard

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 04 Aug 2013 - 20:19:45 CEST