Ich verwende ein Ubuntu 12.04-Desktopsystem. Bisher habe ich nur einige Programme installiert (ich habe Sudo-Rechte).

1. Wenn ich die Liste der Benutzer auf dem System überprüfe, sehe ich eine lange Liste mit mehr als 20 Benutzern. Wann wurden diese Benutzer erstellt (z. B. Daemon, Sys, Sync, Spiele, Puls usw.)? Wie hängen diese mit der Installation neuer Programme zusammen?

2. Wenn ich ein Programm auf meinem System ausführe, sollte es mit meiner UID ausgeführt werden. Aber wenn ich einen ps mache , sehe ich viele andere Programme mit unterschiedlichen UIDs (wie root, daemon, avahi, syslog, colord usw.) - wie wurden diese Programme mit unterschiedlichen UIDs gestartet?

Benutzerkonten werden nicht nur für tatsächliche, menschliche Benutzer verwendet, sondern auch zum Ausführen von Systemdiensten und manchmal als Eigentümer von Systemdateien. Dies geschieht, weil die Trennung zwischen den Ressourcen des Benutzers (Prozesse, Dateien usw.) und der Trennung zwischen den Ressourcen der Systemdienste dieselben Mechanismen erfordert.

Die Programme, die Sie ausführen, werden normalerweise mit Ihrer Benutzer-ID ausgeführt. Es sind nur System- Daemons , die unter ihrem eigenen Konto ausgeführt werden. Entweder gibt die Konfigurationsdatei, die angibt, wann der Dämon ausgeführt werden soll, auch an, welcher Benutzer ihn ausführen soll, oder der Dämon wechselt nach dem Start zu einem nicht privilegierten Konto. Einige Daemons erfordern vollständige Administratorrechte, sodass sie unter dem Root- Konto ausgeführt werden. Viele Daemons benötigen nur Zugriff auf ein bestimmtes Hardwaregerät oder auf bestimmte Dateien, sodass sie unter einem dedizierten Benutzerkonto ausgeführt werden. Dies geschieht aus Sicherheitsgründen: Auf diese Weise kann ein Fehler oder eine Fehlkonfiguration in einem dieser Dienste nicht zu einem vollständigen Systemangriff führen, da der Angreifer darauf beschränkt ist, was dieser Dienst tun kann und was nicht in der Lage, Dateien zu überschreiben, Prozesse auszuspionieren usw.

Unter Ubuntu werden Benutzer-IDs im Bereich von 0 bis 99 bei der Systeminstallation erstellt. 0 ist root; Viele der Einträge im Bereich 1–99 existieren nur aus historischen Gründen und werden nur aus Gründen der Abwärtskompatibilität mit einigen lokalen Installationen, die sie verwenden, aufbewahrt (einige zusätzliche Einträge schaden nicht). Benutzer-IDs im Bereich von 100 bis 999 werden dynamisch erstellt und entfernt, wenn Dienste installiert oder entfernt werden, die eine dedizierte Benutzer-ID benötigen. Der Bereich ab 1000 richtet sich an Benutzer oder andere vom Systemadministrator erstellte Konten. Gleiches gilt für Gruppen.

Ich nehme an, Sie finden diese Liste von Benutzern, indem Sie überprüfen /etc/passwd? Dies ist völlig normal - Benutzer dienen dazu, eine Reihe von Berechtigungen zu übertragen, die nicht nur zum Sperren von "tatsächlichen Benutzern", sondern auch zum Nachverfolgen von Änderungen in bestimmten Systembereichen (dasselbe Konzept mit Gruppen) nützlich sind.

Ich habe eine meiner Himbeer-Pi- /etc/passwdDateien unten als Referenz eingefügt . Sie werden den Benutzer ntopam Ende dieser Datei bemerken , die vom Programm erstellt wurde ntop(Netzwerküberwachung). Ebenso sshd, gnatsBug - Reporting usw.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

Wann wurden diese Benutzer erstellt?

In den von Ihnen erwähnten Fällen wurden sie bei der Systeminstallation erstellt. Diese Benutzerkonten sind konventionell und stammen teilweise aus Jahrzehnten. Sie sind auch standardisiert. Die Linux Standard Base unterteilt sie in:

• die erforderlichen Standard - Benutzerkonten, root, bin, und daemon; und
• die optionalen Standard - Benutzerkonten adm, lp, sync, shutdown, halt, mail, news, uucp, operator, man, undnobody

Andere Benutzerkonten , die hier genannt werden - pulse, avahi, colordund Debian-exim(holen ein von py4on-Passwort - Datei) - uns auf die nächste Frage bringen.

Wie hängen diese mit der Installation neuer Programme zusammen?

Die nicht standardmäßigen Benutzerkonten werden von den "Betreuerskripten" für verschiedene Pakete erstellt und gelöscht, wenn diese Pakete installiert und gelöscht werden. Ein Benutzerkonto wird durch das sogenannte postinstBetreuerskript des Pakets erstellt. Es wird ausgeführt getent, um festzustellen, ob das Benutzerkonto bereits vorhanden ist und useraddob dies nicht der Fall ist. Theoretisch würde es durch das sogenannte postrmBetreuerskript des Pakets gelöscht , das ausgeführt wird userdel.

In der Praxis werden Benutzerkonten für Pakete nicht gelöscht. Das Fedora-Wiki (siehe dort) erklärt, dass dies mit Schwierigkeiten verbunden wäre. Siehe Debian Bug # 646175 ein Beispiel für dieses Grundprinzip in Aktion, wo entschieden wird , einfach nicht das löschen rabbitmqBenutzerkonto , wenn das Paket gelöscht wird, ein Problem mit einem Dæmon zu lösen , die unter der Schirmherrschaft des Kontos laufen weiter.

Wie wurden diese Programme mit unterschiedlichen UIDs gestartet?

Unter Unix und Linux kann ein Prozess, der unter der Ägide des Superuser ausgeführt wird, sein Benutzerkonto in etwas anderes ändern und dasselbe Programm weiter ausführen, aber das Gegenteil ist nicht zulässig. (Man muss den Set-UID-Mechanismus verwenden.)

Das Daemon-Management-System wird als Superuser ausgeführt. Die Konfigurationsdaten geben an, dass bestimmte Dæmons unter der Ägide bestimmter Benutzerkonten ausgeführt werden:

• Bei System 5 verwendet rcdas Skript /etc/init.dein Hilfswerkzeug wie start-stop-daemonund dessen --chuidOption.
• Mit einem daemontools Familie Service - Managern, die runSkript Anrufe setuidgid, s6-setuidgid, chpst, oder runuidmit dem Benutzerkontonamen. Beispiele hierfür finden Sie unter /unix//a/179798/5132 , mit denen das nagiosBenutzerkonto festgelegt wird.
• Mit upstart gibt es eine setuidZeilengruppe in einer Jobdatei, die das Benutzerkonto angibt. Dies ist nicht besonders feinkörnig, und manchmal möchte man das, was unter /superuser//a/723333/38062 beschrieben ist .
• Bei systemd gibt es eine User=Einstellung in der Service Unit-Datei, die das Benutzerkonto angibt.

Wenn das Dæmon-Verwaltungssystem einen Prozess als Dæmon hervorruft, werden durch diese Mechanismen Superuser-Berechtigungen gelöscht, sodass der Dæmon-Prozess weiterhin unter der Ägide des nicht privilegierten Benutzerkontos ausgeführt wird.

Es gibt eine ziemlich lange Erklärung, warum ein gutes Dæmon-Management auf diese Weise erfolgt. Aber du hast nicht gefragt warum; nur wann, wie und woher. ☺ Eine sehr kurze Zusammenfassung, deshalb:

Unix- und Linux-Betriebssysteme isolieren Prozesse, die unter verschiedenen Benutzerkonten ausgeführt werden, voneinander. In der Vergangenheit konnte man alles tun, was man wollte, wenn man ein Dæmon übernehmen konnte, das als Superuser lief. Ein Dæmon, das unter der Ägide eines nicht privilegierten Kontos ausgeführt wird, kann hingegen nur auf Dateien, Verzeichnisse, Geräte und Prozesse zugreifen, die mit diesem nicht privilegierten Konto möglich sind. Ein System, in dem sich dæmon-Programme gegenseitig nicht vertrauen, die alle unter der Ägide verschiedener Benutzerkonten ausgeführt werden und nicht auf die (internen, vertrauenswürdigen) Dateien / Verzeichnisse / Prozesse / Geräte des anderen zugreifen / diese steuern können, ist daher umso schwieriger zu knacken.

Weitere Lektüre

• Jonathan de Boyne Pollard (2014). Nebeneinander ausgeführte Skripte und Serviceeinheiten. . Häufig gestellte Fragen.
• Kontoführung in Maintainer-Skripten . Debian-Wiki.
• Verpackung: UsersAndGroups . Fedora-Projekt-Wiki.
• "Kapitel 15. Benutzer & Gruppen" . Linux Standard Base Spezifikation 2.1 . 2004. Free Standards Group.
• "9.2 Benutzer und Gruppen" . Debian-Richtlinienhandbuch . 2014-11-22. Die Debian-Richtlinien-Mailingliste.
• "37.3. Standardbenutzer" . RHEL-Bereitstellungshandbuch . 11. Ausgabe. 2013. Red Hat.
• Benutzer und Gruppen . Arch Wiki.
• Carol Hurwitz und Scott McPeak (12.02.2001). Wurzeldämonen abschaffen! . DOI 10.1.1.120.3567 .

Unter Linux wird bei der Installation eines Dienstes ein Benutzer mit seinem Dienstnamen oder ähnlichem erstellt, damit er nicht auf andere Dateien zugreifen kann.