Re: nächtliche mails an root?

Polytropon <freebsd(at)edvax.de> wrote:
> Ich weiß, daß der therapeutische Inhalt von OpenBSD eine
> solche Verfahrensweise strikt ablehnt, daß sie in manchen
> Linux-Distributionen sogar mangels eines namentlich bekannten
> root-Accounts nicht möglich ist,

Was übrigens durchaus seine Vorteile hat.

Es gibt die »Philosophie«, dass es sich bei root nicht um
einen User handelt, nicht einmal um einen Pseudo-User,
sondern um eine »role« (Rolle), mit deren Hilfe normalen
Usern, die speziell ausgezeichnet sind (Admins), zusätz-
liche Privilegien verliehen werden können.

Konsequenterweise kann man sich dann nicht mehr als User
root einloggen, weil es den als solchen ja gar nicht gibt.

Wenn man das Prinzip weiterführt, teilen sich diese zu-
sätzlichen Privilegien auf viele verschiedene Dinge auf.
Es gibt z.B. das Privileg »darf einen Reboot durchführen«,
»darf Paketfilter-Regeln ändern«, »darf Binaries instal-
lieren« und so weiter. Das hat gegenüber dem klassischen
monolithischen UNIX-Konzept (»root darf alles«) deutliche
Vorteile.

In vereinfachter Form bietet BSD so eine Aufteilung in
Rollen bereits seit Langem, nämlich per Umweg über Gruppen-
rechte: Wer in die Gruppe »operator« eingetragen wird,
bekommt die Rechte »darf shutdown(8) ausführen« und
»darf Backups mit dump(8) anfertigen« (Die operator-Gruppe
hat per Default Leserecht auf die Raw-Disk-Devices).
Dazu sind keine root-Rechte erforderlich.

Das ist natürlich nur ein erster Schritt. Dass man die
Privilegien noch weiter auffächern kann, zeigt z.B. das
MAC-Framework von FreeBSD. Auch mit Jails kann man da
einiges anstellen.

Im Grunde genommen kann man auf den root-Account tatsäch-
lich inzwischen ganz verzichten. Allerdings wird man ihn
aus Kompatibilitätsgründen trotzdem noch behalten müssen,
da etliche Programme und Skripte (leider) erwarten, dass
es ihn gibt, und dass bestimmte Dinge (z.B. install(1))
nur gehen, wenn »id -nu« root ausgibt. Das im Einzelfall
immer zu fixen bzw. zu umgehen, ist mit Aufwand verbunden,
aber sicherlich möglich, wenn man's drauf anlegt.

> aber wenn man in den SUM
> wechselt, insbesondere, wenn die Konsole obendrein als
> "secure" markiert ist, dann macht man doch sinngemäß auch
> ein root-Login.

Nein. Die Single-User-Shell unterscheidet sich in etlichen
Punkten von einem normalen Login. Diese Shell wird direkt
von init(8) gestartet, unter Umgehung der normalen Login-
Mechanismen wie login(1), getty(8) o.ä. Das hat beispiels-
weise zur Folge, dass keine Registrierung im wtmp, utmp
bzw. utmpx erfolgt. Auch die PAM-Regeln werden komplett
umgangen, ebenso login.conf und tausend andere Sachen.
Dass $TERM u.U. nicht korrekt gesetzt wird, gehört da noch
zu den geringeren Problemen.

Davon abgesehen handelt es sich bei der Single-User-Shell
um eine Ausnahme, die nur im absoluten Notfall benötigt
wird. Der Single-User-Modus sollte keinesfalls für
reguläre Wartungsarbeiten o.ä. missbraucht werden.

> Außerdem fehlen bei "Hoecker" die zwei Punkte auf dem e,
> so ist es jetzt nur ein Höcker. :-)

Wo doch das »ë« sogar im herkömmlichen Latin-1 enthalten
ist. :-)

> Gut, daß man als root nicht sein Tagesgeschäft verrichten
> soll, ist ja normal. Aber wenn man am heimischen Rechner
> nun schonmal doof rumsitzt und einen im Bedarfsfall sogar
> die Textmoduskonsole anglotzt, warum loggt man sich dann
> nicht als root ein und macht "pkg_add -r irgendwas"?

Sich zunächst als user einzuloggen und dann "su -m" zu
verwenden (oder meinetwegen sudo, aber ich bin kein Freund
davon; stattdessen ziehe ich ggf. »super« vor, siehe
ports/security/super), hat eine ganze Reihe von Vorteilen.
Bei mir ist »su« sogar ein Alias auf »su -m«, weil ich es
nie anders verwende.

Erstens hast Du dann Deine ganz normale, gewohnte Umgebung
als User: Deine Lieblingsshell, das normale Environment
und so weiter. Das bedeutet, dass die Login-Shell von root
(csh) nicht ändern musst, was ohnehin eine schlechte Idee
wäre (das wurde hier auch schon öfters diskutiert). Du
musst auch unter /root keine Shell-Profiles anlegen oder
sonstwas. Das ist besonders für Systeme mit mehreren
Admins nützlich: Jeder Admin hat auch als root automatisch
seine eigene Shell (bash, zsh, was auch immer).

Zweitens kannst Du dann root-Logins ganz sperren, was der
Systemsicherheit dienlich ist.

Drittens kannst Du dann mit den Kommandos »suspend« (dafür
habe ich einen Alias namens »sp«) und »fg« jederzeit
beliebig zwischen user-Shell und root-Shell wechseln,
ohne erneut Passwörter eingeben zu müssen. Ich habe
meinen Shell-Prompt so konfiguriert, dass ich auf den
ersten Blick sehe, wenn ich gerade root-Rechte habe,
damit ich nicht durcheinanderkomme (»root« erscheint
in rot+bold im Prompt).

Viertens wird bei Log-Einträgen, die man als root
verursacht, i.allg. der »echte« User geloggt. Auch
dies ist insbesondere auf Systemen mit mehreren Admins
interessant, da man im Fall von Problemen nachvollziehen
kann, wer etwas gemacht hat. Dazu gehört auch, dass
der echte User im wtmp/utmp/utmpx steht. Wenn also zu
einem bestimmten Zeitpunkt etwas in die Brüche geht,
weiß man, wer eingeloggt war und evtl. irgendwas gemacht
hat. Würde man sich als root einloggen, stünde im wtmp
nur »root«, was nicht hilfreich ist.

Das sind die Sachen, die mir so aus dem Stegreif ein-
fallen; es gibt sicherlich noch mehr Vorteile.

> Tut mir leid, natürlich meinte ich das Einloggen als root
> per telnet-Sitzung, direkt über's Internet, selbstverständlich
> mit lokalem Echo des Paßwortes! :-)

Eine Bemerkung am Rande: Häufig wird telnet als »böse«
hingestellt, dabei kann das unter BSD schon seit Urzeiten
Verschlüsselung (seit einiger Zeit ist das sogar Default),
mit und ohne Kerberos. Natürlich kann es SSH nicht ganz
ersetzen, solange man keine vollwertige Kerberos-Umgebung
aufsetzen will.

Aber das Klischee »telnet ist böse, weil unverschlüsselt«
ist einfach unwahr.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"Above all, they contribute to the genetic diversity in the
operating system pool.  Which is a good thing."
  -- Ruben van Staveren, on the question which BSD OS is the best one.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message