[linux-l] Re: refactoring

[Peter Ross]

On Sun, 9 Nov 2003, Steffen Dettmer wrote:

> systemspezifischen Configfiles/Properties in /usr/java/lib oder
> sowas rum, und nicht in /etc/sonstwas/
> ..
> "Wie ist eigentlich egal, hauptsache einheitlich".

Da ist allerdings Linux eher die Ausnahme. Alle anderen mir bekannten
"Unixe" unterscheiden zwischen Basissystem und zusaetzlichen Packages.

Sun und andere SysV packen eben alle zusaetzlichen Packages unter /opt,
BSD-basierte Systeme lieber unter /usr/local.

Und dann gibt es eben noch den religioesen Unterschied, ob man in der Art
$PREFIX/$PACKAGE/[etc|lib..] (System V)
oder
$PREFIX/[etc/lib..]/$PACKAGE (BSD)
strukturiert.

Da aber jedes etwas komplexere System aus ein Paar Tools aus "jeder
Richtung" benutzt, und die Systeme, entstanden mal auf einem System "Marke
SysV", mal "Marke BSD", nicht immer angepasst werden, hat man in der Regel
Mischmasch.

Ganz schlecht ist es aber, wenn man Konfigs, welche das Verhalten des
Systems bestimmen, und Dateien, die beim Starten des Systems generiert
werden, in ein Verzeichnis packt (wie bei Tomcat). Das macht es schwierig,
ein System zu haerten, weil das Verzeichnis Schreibrechte fuer das Package
braucht.

Das heisst, dass, wenn der Dienst unsicher ist, kann ich ihn gleich ohne
Probleme benutzen, um ihn umzukonfigurieren. Wunderbar einfach fuer einen
Angreifer.

BTW: Ich mag den BSD-Style $PREFIX/[etc/lib..]/$PACKAGE nicht, weil ich
BSD-Fan bin, sondern weil es es einfach macht, systemweit zwischen
Programmen, Bibliotheken, Daten und Konfigs zu unterscheiden.

Gut fuer ReadOnly-Mounts, rekursives chflags, und Backup.

Alle Daten sind unter /var, /usr/local/var (meist ein Link auf /var) und
/home, alle Konfigs unter /etc (welche, die ich nach der Installation
veraendere, bekommen einen Hardink in /etc/changed verpasst sowie das
Original dorthin backupt) und /usr/local/etc.

Mehr braucht nicht gesichert werden. Der Rest laesst sich durch die
Installation wiederherstellen.

Wenn man allerdings Dienste in chrooted bzw. jailed Environments laufen
lassen will, lohnt sich SystemV-Style, weil so alles, was der Dienst
braucht, unterhalb seines $PREFIX/$PACKAGE-Verzeichnisses liegt. Das
bedeutet aber auch mehr Arbeit bei Backup und Hardening, um nichts zu
vergessen.

BSD-Style geht ausserdem ein bisschen auf Kosten der Durchschaubarkeit.
Wer es gewohnt ist, alles zu Samba unter /usr/local/samba zu finden, muss
nun unter /usr/local/[etc|lib..]/samba nachgucken.

(Der geuebte Windows-Entwickler stoehnt: Unter Windows ist das alles ganz
einfach, wenn mir etwas nicht passt, tausche ich halt aus und es ist ja
fast alles unter C:\WINDOWS und das darf ich auch, weil ich ja mit
Admin-Rechten arbeite. Sonst funktioniert das System sowieso nicht. Kein
Witz, sondern Realitaet 2003 in einer Bude, die HighEnd-Graphik-Software
unter Windows 2000 entwickelt)

Der typische Sicherheit/Nutzbarkeit-Konflikt.

Ich bin Admin und fuer die Sicherheit zustaendig. Was schert es mich, ob
man das System auch benutzen kann;-)

Es gruesst
Peter (BOFH)