Wie erinnern sich Anwendungen für einige Zeit an die Authentifizierung?


4

Unter Linux können sich einige Anwendungen für einige Zeit an die Authentifizierung erinnern. Zum Beispiel,

  • Dateimanager erinnern sich eine Weile an die Authentifizierung, wenn wir ein Kennwort zum Mounten einer Partition angeben. Wenn wir eine andere Partition kurz nach dem Mounten der ersten mounten, werden wir nicht nach einem Passwort gefragt.

  • Terminalanwendungen, bei denen eine Aufgabe ausgeführt sudound ein Kennwort angegeben wird, werden nicht nach der nächsten sudoAktion gefragt, wenn sie innerhalb eines bestimmten Zeitraums ausgeführt werden.

Wie wird diese Funktionalität implementiert? Wie kann ich meine Anwendung veranlassen, sich für einige Zeit an die Root-Authentifizierung zu erinnern?


Authentifizierungen werden meist nicht im Cache gespeichert, da dies eine Sicherheitsbedrohung sein kann. bis, es sei denn, Sie geben an, erinnern Sie sich an mich, dass auch Webanwendungen das Kennwort nicht speichern. Wenn es Windows-Betrieb dann OS verwendet, um in ihm verschlüsseltes temporäres Format zu speichern und das wird auch nach dem Neustart der Maschine nicht gültig sein
vembutech

Als Randnotiz sollten Sie nur interne Partitionen auflisten /etc/fstab, damit sie automatisch gemountet werden.
Grawity

@vembutech Richtig gestaltete Webanwendungen speichern das Passwort niemals!
Scott

Antworten:


6

Ein Programm zu haben, das sich an etwas "erinnert", ist einfach: Schreiben Sie es irgendwo in eine Datei und lesen Sie es später zurück. So funktionieren alle Einstellungen. (Im Übrigen ist es so, wie normale Dateien funktionieren.)

(Sie können als Datei ~/.config/auf der Festplatte gespeichert werden; eine Datei im RAM /run; ein abstrakter Einstellungsspeicher wie GConf oder die Windows-Registrierung; dies variiert.)

In beiden Beispielen berücksichtigen die relevanten Programme / Dienste nicht die Authentifizierungsdetails, sondern nur die Tatsache, dass die Authentifizierung kürzlich erfolgreich war (und dass die Aktion letztendlich zulässig war) - mit anderen Worten, eine Autorisierung.

  • Wenn Sie eine Festplatte über die grafische Benutzeroberfläche bereitstellen , wird die Bereitstellungsanforderung an UDisks gesendet , die dann polkit zur Bestätigung auffordert . ("Hey, Benutzer X versucht, Datenträger Y bereitzustellen, ist das zulässig?")

    Da polkit ein permanent laufender Dienst ist, werden die letzten Authentifizierungen vollständig im eigenen Speicher des Prozesses in einer verknüpften Liste (einer GList) protokolliert. Sie können nach src/polkitbackendWörtern suchen temporary_authorization.

    Wenn Sie dasselbe Feature implementieren würden, wäre ein vereinfachtes Beispiel:

    authorizations = list()
    ...
    authorizations.append({user: "niyasc",
                           action: "mount drive",
                           expires: time.now() + 3600})
    

    Ihr Programm kann auch ein Polkit verwenden .

  • sudo hingegen ist ein One-Shot-Tool, in dem dieselben Informationen extern gespeichert werden - als Dateien unter (/var)/run/sudo/ts. Der "zuletzt geänderte" Zeitstempel der Datei wird verglichen, um festzustellen, ob er aktuell genug ist, und nach jeder Verwendung aktualisiert.

    # ls -l /run/sudo/ts
    total 4
    -rw------- 1 root grawity 80 Jul 29 12:15 /run/sudo/ts/grawity
    

    Der Algorithmus ist in beiden Fällen ungefähr:

    def check_authorization(user) {
        if has_old_authorization(user) {
            expires = read_authorization(user);
            if expires > time.now() {
                return true;
            }
        }
        success = ask_for_authentication(user);
        if success {
            store_authorization(user, expires=time.now()+3600);
        }
        return success;
    }
    

Es gibt andere Methoden zum "Erinnern an die Authentifizierung", aber alle beschränken sich darauf, eine Reihe von Bytes in einer Datei zu speichern:

  • Viele netzwerkbasierte Apps (z. B. Mail-Clients wie Thunderbird oder Outlook) speichern den Benutzernamen und das Kennwort direkt auf der Festplatte. Ein vereinfachtes Beispiel wäre die Datei ~ / .netrc:

    machine imap.example.com
        login niyasc@example.com
        password foobar
    

    Oft wird es vor dem Speichern verschlüsselt (die App verwendet möglicherweise Betriebssystemfunktionen wie GNOME-Keyring oder unterstützt ein "Hauptkennwort"), aber letztendlich handelt es sich nur um Daten, die in einer Datei gespeichert werden können .

  • Viele webbasierte Apps verwenden Cookies, um sich daran zu erinnern, dass Sie angemeldet sind. Beim Anmelden fordert der Server Ihren Browser auf, sich an etwas wie "session_id = SGVsbG8gd29ybGQh" zu erinnern und es bei jedem nächsten Besuch zurückzusenden. Browser verfügen normalerweise über eine textbasierte oder SQLite-basierte Datenbank aller Cookies, die von allen Websites ausgegeben werden (das "Cookie-Glas").

    Der Server verfügt auch über eine Sitzungsdatenbank, die Informationen zu jedem ausgegebenen Cookie enthält. Wenn also dieselbe "session_id = SGVsbG8gd29ybGQh" empfangen wird, weiß der Server, dass Sie niyasc sind:

    SESSION_ID         USERNAME   ISSUED          EXPIRES
    SGVsbG8gd29ybGQh   niyasc     Jul 29, 11:47   Aug 29, 11:47
    6kJnRcg4KBAPrMJ4   fred       Jun 14, 22:13   Sep 14, 22:13
    ...
    
  • Einige Netzwerkprotokolle wie Kerberos oder SAML, verwenden Sie eine Form von Cookies genannt „Tickets“ oder „Token“, die sich die Informationen über, wenn sie ausgestellt wurden und für wen. (Sie werden auch vom Authentifizierungsdienst als Beweis digital signiert.) Dadurch können der Authentifizierungsserver und der Anwendungsserver zur Erhöhung der Sicherheit auch getrennt werden.

  • Bei anderen Protokollen wie SSH oder SSL / TLS werden digitale Signaturen verwendet. Statt eines Kennworts verfügt der Client über ein privates Schlüsselpaar (normalerweise RSA oder [EC] DSA), das auch als Datei auf der Festplatte gespeichert wird. zB die ~/.ssh/id_rsaDatei.

    Für jede Verbindung sendet der Server eine "Abfrage" (eine Reihe von zufälligen Bytes). der Client signiert es mit seinem privaten Schlüssel; Der Server überprüft dann die Signatur und überprüft, ob sie mit einem der "erlaubten" Schlüssel signiert ist.


2

Das liegt am Cache . Das Konzept des Cache ist sehr einfach. Es ist ein viel schnellerer Speicher als die normalen Festplatten. Wenn Sie etwas suchen oder einen Befehl ausführen möchten, der sich zuerst im CPU-Kontaktcache befindet, geschieht das Abrufen sehr schnell. Aber wenn nicht, dann geht es in den normalen Speicher und findet dann holt und der ganze Vorgang dauert einige Zeit.

Linux versteht und nutzt das Konzept des Caching. Nachdem zum ersten Mal auf eine Datei zugegriffen wurde, wird der Inhalt für die spätere Verwendung im Speicher aufbewahrt (falls frei). Wenn Sie das nächste Mal denselben Befehl ausführen, ruft die CPU den Inhalt nur aus dem Speicher ab, ohne etwas zu lesen. Dies erhöht die Gesamtgeschwindigkeit der Ausführung.

Nehmen wir an, Sie haben das Terminal geöffnet und geben dann den Befehl pwd ein . Zum ersten Mal dauert es eine Weile, bis das aktuelle Arbeitsverzeichnis angezeigt wird. Führen Sie nun den Befehl pwd erneut aus. Diesmal werden Sie feststellen, dass die Ausführung sehr schnell ist. Denn beim zweiten Start wurde das aktuelle Arbeitsverzeichnis bereits gespeichert. Die CPU hat gerade die Informationen abgerufen.

Ich hoffe, Sie haben inzwischen eine Idee.

Danke.


3
Während das Konzept größtenteils identisch ist, hat der Authentifizierungsstatus für die Zwischenspeicherung von Diensten für die Leistung absolut nichts mit den Zwischenspeicherungsdateien des Betriebssystems zu tun. Es gibt nicht eine einzige Gemeinsamkeit zwischen den Implementierungen von beiden.
Grawity
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.