12
Fragen zu Rechten auf Dateien und Verzeichnisse bei stunnel
Hallo,
ich habe ein Problem bzw. Frage zu dem Rechtesystem von Linux.
Soweit ich weiß soll man aus Sicherheitsgründen Dienste mit niedrigeren Rechten laufen lassen. Normalerweise laufen diese soweit ich weiß mit root-Rechten.
Installiert man z.B das Paket Stunnel4 aus dem Repo, dann legt dieses Paket auch gleich den User als auch die Gruppe stunnel4 an.
Im Config-File von stunnel setzt man die Optionen setuid und setguid entsprechend auf stunnel4.
Nun habe ich ein Verzeichnis in dem Zertifikate abgelegt sind.
Die Dateien liegen unter
/etc/openvpn/easy-rsa/pki/issued
Alle Ordner haben als Eigentümer root
etc hat als Gruppe root
openvpn hat als Gruppe vpnuser
etc und openvpn haben Zugriffsrecht x für other
easy-rsa, pki und issued haben als Gruppe ssl-cert, als Rechte drwxr-x---
die Dateien in issued sind root:ssl-cert mit Rechten -rwxr-x---
User stunnel4 ist Mitglied in Gruppe ssl-cert
Dennoch kann stunnel nicht auf die besagten Dateien zugreifen.
Wenn ich easy-rsa, pki und issued bei Other auch ein x setzte, dann findet stunnel die Dateien. Alternativ funktioniert es auch wenn ich setuid und setguid in der stunnel-Config auskommentiere
Ein x für Other sollte aber doch gar nicht nötig sein, oder?
Der User stunnel 4 wurde in die Gruppe ssl-cert aufgenommen.
Warum kann der User stunnel4 dann nicht auf die Dateien zugreifen wenn stunnel4 doch Mitglied der Gruppe ssl-cert ist und diese Gruppe rw auf die Dateien hat?
Vielen Dank.
In Syslog sieht man wenn sich ein Client verbinden will ob er das Zertfikat in besagtem Ordner gefunden hat oder nicht.
ich habe ein Problem bzw. Frage zu dem Rechtesystem von Linux.
Soweit ich weiß soll man aus Sicherheitsgründen Dienste mit niedrigeren Rechten laufen lassen. Normalerweise laufen diese soweit ich weiß mit root-Rechten.
Installiert man z.B das Paket Stunnel4 aus dem Repo, dann legt dieses Paket auch gleich den User als auch die Gruppe stunnel4 an.
Im Config-File von stunnel setzt man die Optionen setuid und setguid entsprechend auf stunnel4.
Nun habe ich ein Verzeichnis in dem Zertifikate abgelegt sind.
Die Dateien liegen unter
/etc/openvpn/easy-rsa/pki/issued
Alle Ordner haben als Eigentümer root
etc hat als Gruppe root
openvpn hat als Gruppe vpnuser
etc und openvpn haben Zugriffsrecht x für other
easy-rsa, pki und issued haben als Gruppe ssl-cert, als Rechte drwxr-x---
die Dateien in issued sind root:ssl-cert mit Rechten -rwxr-x---
User stunnel4 ist Mitglied in Gruppe ssl-cert
Dennoch kann stunnel nicht auf die besagten Dateien zugreifen.
Wenn ich easy-rsa, pki und issued bei Other auch ein x setzte, dann findet stunnel die Dateien. Alternativ funktioniert es auch wenn ich setuid und setguid in der stunnel-Config auskommentiere
Ein x für Other sollte aber doch gar nicht nötig sein, oder?
Der User stunnel 4 wurde in die Gruppe ssl-cert aufgenommen.
Warum kann der User stunnel4 dann nicht auf die Dateien zugreifen wenn stunnel4 doch Mitglied der Gruppe ssl-cert ist und diese Gruppe rw auf die Dateien hat?
Vielen Dank.
In Syslog sieht man wenn sich ein Client verbinden will ob er das Zertfikat in besagtem Ordner gefunden hat oder nicht.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 600117
Url: https://administrator.de/contentid/600117
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
12 Kommentare
Neuester Kommentar
Moin.
Der Grund hier ist das setgid den stunnel-Daemon zwar in diese eine Gruppe (stunnel4) setzt, jedoch wird dadurch nur diese eine Gruppe für den Prozess gesetzt, keine vererbten Mitgliedschaften in anderen Gruppen. Die setgid() Funktion arbeitet dabei wie folgt
Beachte das clear all other groups. Effektiv arbeitet der Daemon also nur mit der "stunnel4" Gruppe und die ist bei deinen ACLs dann mit die "other" Identität weil dem Prozess die "ssl-cert" Gruppenmitgliedschaft fehlt, eben weil diese "supplemental groups" durch "setgid" entfernt wurden.
Siehe auch auf der Konsole die man-pages
man credentials
oder
Group memberships and setuid/setgid processes
hth
k.
Der Grund hier ist das setgid den stunnel-Daemon zwar in diese eine Gruppe (stunnel4) setzt, jedoch wird dadurch nur diese eine Gruppe für den Prozess gesetzt, keine vererbten Mitgliedschaften in anderen Gruppen. Die setgid() Funktion arbeitet dabei wie folgt
setgid = GROUP (Unix only)
Unix group id
As a global option: setgid() to the specified group in daemon mode and clear all other groups.Siehe auch auf der Konsole die man-pages
man credentials
oder
Group memberships and setuid/setgid processes
hth
k.
Stimmt, Du hast vollkommen recht. Da wäre ich alleine nicht drauf gekommen. Vielen Dank.
Das ist aber auch böde gemacht dass das Verhalten nicht gleich ist bei dem Dateiberechtigungssystem und dem System in stunnel.
Darf ich noch eine richtige Anfängerfrage stellen:
Bei Dateien gibt es als Standard die Rechte lesen, schreiben und ausführen (die Sonderechte suid, guid und sticky lassen wir mal aussen vor)
In welchen Fällen muss ein Benutzer/Gruppe auf die Ordner über der Datei das Lesen-, ich welchen das Auflisten-Recht haben um das Entsprechende auf die Datei ausführen zu können?
Dann noch eine Frage mehr in Richtung der Services:
Wenn ich mir mal anschauen möchte welcher Service mit welchem Benutzer läuft, wie mache ich das am besten?
Das ist aber auch böde gemacht dass das Verhalten nicht gleich ist bei dem Dateiberechtigungssystem und dem System in stunnel.
Darf ich noch eine richtige Anfängerfrage stellen:
Bei Dateien gibt es als Standard die Rechte lesen, schreiben und ausführen (die Sonderechte suid, guid und sticky lassen wir mal aussen vor)
In welchen Fällen muss ein Benutzer/Gruppe auf die Ordner über der Datei das Lesen-, ich welchen das Auflisten-Recht haben um das Entsprechende auf die Datei ausführen zu können?
Dann noch eine Frage mehr in Richtung der Services:
Wenn ich mir mal anschauen möchte welcher Service mit welchem Benutzer läuft, wie mache ich das am besten?
Zitat von @blacksun:
In welchen Fällen muss ein Benutzer/Gruppe auf die Ordner über der Datei das Lesen-, ich welchen das Auflisten-Recht haben um das Entsprechende auf die Datei ausführen zu können?
(X) Execute-Rechte werden immer benötigt um überhaupt in den Ordner hineinzuwechseln / (R) Leserechte brauchst du wenn du die Dateien im Ordner auch auflisten willst. Du kannst ja mal selbst versuchen einem User nur mal (X) Execute Rechte auf einen Ordner zu geben und keine Leserechte. Du wirst sehen das der User den Ordner-Inhalt nicht mit ls auflisten kann, in den Pfad hineinwechseln oder die Datei direkt über den vollen Pfad ansprechen und bswp. über cat ausgeben lassen funktioniert trotzdem problemlos so lange er auf die Datei selbst in dem Ordner entsprechende Leserechte hat.In welchen Fällen muss ein Benutzer/Gruppe auf die Ordner über der Datei das Lesen-, ich welchen das Auflisten-Recht haben um das Entsprechende auf die Datei ausführen zu können?
Execute-Rechte haben also auf den Ordner angewendet eine andere Bedeutung als auf Dateien. Lese-Rechte auf Ordnern brauchst du nur wenn du auch die Dateien auflisten willst, für den Zugriff auf die Dateien darin ist es nicht nötig so lange die selbigen über entsprechende Rechte verfügen.
Dann noch eine Frage mehr in Richtung der Services:
Wenn ich mir mal anschauen möchte welcher Service mit welchem Benutzer läuft, wie mache ich das am besten?
topWenn ich mir mal anschauen möchte welcher Service mit welchem Benutzer läuft, wie mache ich das am besten?
ps aux
vielen Dank auch für diese Erläuterungen.
ich habe mir die Konfig von stunnel nochmal angeschaut und eines ist mir aber noch nicht klar.
In meiner Konfig gibt es:
Die Inhalte vom CApath haben root:ssl-cert als Eigentümer und Gruppe.
Eine Verschachtelung des Users stunnel4 in ssl-cert greift nicht.
Nun habe ich mir das bei bei cert und key im Pfad /etc/letsencrypt/... angeschaut. Die PEM-Dateien haben als Eigentümer root und Gruppe ssl-cert, die Rechte sind -rw-------, sprich nur der Eigentümer kann die Dateien lesen und ändern.
Wenn ich den Stunnel-Dienst neu starte, dann sagt mir syslog dass er die pem-Dateien lesen konnte.
Wie kommt das nun? Müsste das Verhalten nicht auch wie beim CApath sein?
ich habe mir die Konfig von stunnel nochmal angeschaut und eines ist mir aber noch nicht klar.
In meiner Konfig gibt es:
setuid = stunnel4
setgid = stunnel4
[openvpn]
...
; Schlüssel, Zertifikate, Verschlüsselung
cert=/etc/letsencrypt/xxxx/fullchain.pem
key=/etc/letsencrypt/xxx/privkey.pem
ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA
options = CIPHER_SERVER_PREFERENCE
CApath = /etc/openvpn/easy-rsa/pki/issued
CRLpath = /etc/openvpn/easy-rsa/pki/revoked/certs_by_serial
verifyPeer = yesDie Inhalte vom CApath haben root:ssl-cert als Eigentümer und Gruppe.
Eine Verschachtelung des Users stunnel4 in ssl-cert greift nicht.
Nun habe ich mir das bei bei cert und key im Pfad /etc/letsencrypt/... angeschaut. Die PEM-Dateien haben als Eigentümer root und Gruppe ssl-cert, die Rechte sind -rw-------, sprich nur der Eigentümer kann die Dateien lesen und ändern.
Wenn ich den Stunnel-Dienst neu starte, dann sagt mir syslog dass er die pem-Dateien lesen konnte.
Wie kommt das nun? Müsste das Verhalten nicht auch wie beim CApath sein?
Wenn ich den Stunnel-Dienst neu starte, dann sagt mir syslog dass er die pem-Dateien lesen konnte.
Das ist in dem Fall normal. Stunnel wird erst mal von systemd gestartet, dies läuft in dem Moment noch mit den Rechten die systemd zum Start definiert hat, damit lädt stunnel die Zertifikate in den Speicher, dann "forkt" der Prozess in den mit den in der config angegebenen Rechten, die Zertifikate sind aber weiterhin verfügbar und müssen nicht erneut mit den geringeren Rechten eingelesen werden. Forking bedeutet der Elterprozess beendet sich und ein Child-Prozess läuft weiter. Für die Dienstüberwachung wird dann meist ein sogenanntes PID-File benutzt.Du siehst nicht jeder Daemon unter Unix arbeitet gleich, es gibt wie hier und da immer ein paar Ausnahmen was das Starten betrifft, aber generell gilt weiterhin das oben genannte Verhalten.
Zitat von @145033:
Du siehst nicht jeder Daemon unter Unix arbeitet gleich, es gibt wie hier und da immer ein paar Ausnahmen was das Starten betrifft, aber generell gilt weiterhin das oben genannte Verhalten.
Du siehst nicht jeder Daemon unter Unix arbeitet gleich, es gibt wie hier und da immer ein paar Ausnahmen was das Starten betrifft, aber generell gilt weiterhin das oben genannte Verhalten.
das kannst du laut sagen.
Wenigstens ist läuft Stunnel jetzt mit allem was ich haben wollte:
mit reduzierten Rechten für den Daemon, mit chainverify und Let's Encrypt Key/Cert, und mit peerVerify mit Cert aus einer SelfSigned-PKI. Und auch da CSRfile ist mit drin.
Auf eines habe ich leider mit Googlen noch keine Antwort gefunden. Kann stunnel eigentlich auch über einen https-Proxy laufen?
Keinen transparenten, sondern einen den man angibt.
Zitat von @blacksun:
Auf eines habe ich leider mit Googlen noch keine Antwort gefunden. Kann stunnel eigentlich auch über einen https-Proxy laufen?
Keinen transparenten, sondern einen den man angibt.
Würde ich mir mal die Config Optionen protocolHost, protocolUsername, und protocolPassword anschauenAuf eines habe ich leider mit Googlen noch keine Antwort gefunden. Kann stunnel eigentlich auch über einen https-Proxy laufen?
Keinen transparenten, sondern einen den man angibt.
https://linux.die.net/man/8/stunnel
du hast schon wieder vollkommen recht.
Da kann ich in den man pages lange nach Proxy suchen (wie es bei den meisten Anwendungen auch genannt wird) wenn das bei stunnel protocol heißt.
Darf ich mal noch was grundsätzliches fragen:
stunnel wird oft als Beispiel genannt wenn es darum geht bei DPI einen VPN-Traffic oder SSH-Traffic als normalen SSL-Traffic aussehen zu lassen.
Ich gehe mal davon aus dass heute jede DPI eine SSL-Verbindung aufbricht und nach der Prüfung des Inhalts den Inhalt selbst wieder neu verschlüsselt.
Wie soll stunnel da schützen?
Da kann ich in den man pages lange nach Proxy suchen (wie es bei den meisten Anwendungen auch genannt wird) wenn das bei stunnel protocol heißt.
Darf ich mal noch was grundsätzliches fragen:
stunnel wird oft als Beispiel genannt wenn es darum geht bei DPI einen VPN-Traffic oder SSH-Traffic als normalen SSL-Traffic aussehen zu lassen.
Ich gehe mal davon aus dass heute jede DPI eine SSL-Verbindung aufbricht und nach der Prüfung des Inhalts den Inhalt selbst wieder neu verschlüsselt.
Wie soll stunnel da schützen?
Stunnel ist primär dafür geschaffen worden um unverschlüsselte Protokolle durch einen zusätzlichen Layer sicher zu machen.
DPI setzt voraus das du das Zertifikat des Man in the Middle Devices welches die Verbindung aufbrechen soll auch als vertrauenswürdig erklärst, da solche Zertifikate selbstsigniert sind wird das dem geschulten Anwender aber sowieso auffallen.
Wenn also ein Anwender so blöd ist und ein fremdes z.B. auf Google ausgestelltes Zertifikat das sein Browser als ungültig erklärt so sang und klanglos akzeptiert ist er selbst schuld wenn seine Daten abgehört werden.
DPI setzt voraus das du das Zertifikat des Man in the Middle Devices welches die Verbindung aufbrechen soll auch als vertrauenswürdig erklärst, da solche Zertifikate selbstsigniert sind wird das dem geschulten Anwender aber sowieso auffallen.
Wenn also ein Anwender so blöd ist und ein fremdes z.B. auf Google ausgestelltes Zertifikat das sein Browser als ungültig erklärt so sang und klanglos akzeptiert ist er selbst schuld wenn seine Daten abgehört werden.
Zitat von @145033:
DPI setzt voraus das du das Zertifikat des Man in the Middle Devices welches die Verbindung aufbrechen soll auch als vertrauenswürdig erklärst, da solche Zertifikate selbstsigniert sind wird das dem geschulten Anwender aber sowieso auffallen.
DPI setzt voraus das du das Zertifikat des Man in the Middle Devices welches die Verbindung aufbrechen soll auch als vertrauenswürdig erklärst, da solche Zertifikate selbstsigniert sind wird das dem geschulten Anwender aber sowieso auffallen.
Absolut richtig.
Würde nicht genau das passieren wenn man kein ChainVerify und peerVerify einsetzt?
Wenn ich das richtig heraus gelesen habe, dann akzeptiert ein stunnel-Client oder -server alles solange es verschlüsselt ist und die Vorgaben in der Konfig einhält
Klar, wenn du ihm sagst akzeptiere sämtliche CAs dann ist das natürlich ein Himmelfahrtskommando und öffnet MitM und Angreifern natürlich Tür und Tor. Sowas macht man nur für Testzwecke im LAB, im Produktivbetrieb sollte das natürlich immer gecheckt werden.
Ich habe mich weiter mit stunnel beschäftigt und nun sind genau zum Thema Zertifikate und CAs doch noch fragen aufgetaucht.
Ich habe mir - wegen meiner Nextcloud-Installation - von Let's Encrypt ein SSL-Zertifikat geholt.
In der Regel benutzt man dafür und zum Verlängern Certbot.
Die Idee von mir war nun dieses Zertifikat auch für andere Serverdienste zu nutzen wie etwa auch stunnel.
für den Parameter key habe ich privkey.pem genommen.
In einem Tutorial habe ich gelesen dass man für cert am besten die fullchain.pem aus Certbot nimmt. Würden nicht auch chain.pem und cert.pem funktionieren? Was meinst du?
Habe ich das richtig verstanden dass ich auf der Client-Seite die Parameter CAfile und und CApath habe mit denen ich mit chainVerify prüfen kann ob das übermittelte Zertifikat echt ist?
Wenn ich das weiter richtig gelesen habe, dann benötige ich, wenn ich CAfile nutze, die komplette chain. Ich habe festgestellt, dass fullchain.pem zwar das Zertifikat von Let's Encrypt und mein Zertifikat hat, aber das Zertifikat der DST Root CA X3 nicht enthält, sprich die CA die Let's Encrypt beglaubigt hat. Würde dir ein Grund einfallen warum die Root CA nicht in fullchain.pem enthalten ist?
Ich habe festgestellt dass mit CAfile es nur dann funktioniert wenn alle 3 Certs im CAfile enthalten sind.
Und das zweite Thema.
Ich habe eine funktionierende OVPN-TCP-Konfig um mich von meinen Clients zu meinem OVPN-Server zu verbinden.
Wenn ich diese OVPN-Verbindung durch einen stunnel-Tunnel leiten möchte, brauche ich dann eine zusätzliche Route um die Stunnel-Verbindung aus der OVPN-Verbindung heraus zu nehmen?
Einige Tutorials sagen dass der OVPN-Client zustäzlich diese Route benötigt:
route x.x.x.x 255.255.255.255 net_gateway
Merkwürdig für mich ist dass unter Windows und auch unter Android OVPN durch stunnel-Tunnel ohne diese zusätzliche Route funktioniert.
Ich habe mir - wegen meiner Nextcloud-Installation - von Let's Encrypt ein SSL-Zertifikat geholt.
In der Regel benutzt man dafür und zum Verlängern Certbot.
Die Idee von mir war nun dieses Zertifikat auch für andere Serverdienste zu nutzen wie etwa auch stunnel.
für den Parameter key habe ich privkey.pem genommen.
In einem Tutorial habe ich gelesen dass man für cert am besten die fullchain.pem aus Certbot nimmt. Würden nicht auch chain.pem und cert.pem funktionieren? Was meinst du?
Habe ich das richtig verstanden dass ich auf der Client-Seite die Parameter CAfile und und CApath habe mit denen ich mit chainVerify prüfen kann ob das übermittelte Zertifikat echt ist?
Wenn ich das weiter richtig gelesen habe, dann benötige ich, wenn ich CAfile nutze, die komplette chain. Ich habe festgestellt, dass fullchain.pem zwar das Zertifikat von Let's Encrypt und mein Zertifikat hat, aber das Zertifikat der DST Root CA X3 nicht enthält, sprich die CA die Let's Encrypt beglaubigt hat. Würde dir ein Grund einfallen warum die Root CA nicht in fullchain.pem enthalten ist?
Ich habe festgestellt dass mit CAfile es nur dann funktioniert wenn alle 3 Certs im CAfile enthalten sind.
Und das zweite Thema.
Ich habe eine funktionierende OVPN-TCP-Konfig um mich von meinen Clients zu meinem OVPN-Server zu verbinden.
Wenn ich diese OVPN-Verbindung durch einen stunnel-Tunnel leiten möchte, brauche ich dann eine zusätzliche Route um die Stunnel-Verbindung aus der OVPN-Verbindung heraus zu nehmen?
Einige Tutorials sagen dass der OVPN-Client zustäzlich diese Route benötigt:
route x.x.x.x 255.255.255.255 net_gateway
Merkwürdig für mich ist dass unter Windows und auch unter Android OVPN durch stunnel-Tunnel ohne diese zusätzliche Route funktioniert.
