Das Kommando der Woche

current

current

BSD Fan
Nachdem ich letzte Woche ziemlich im Stress gewesen bin, musste die Rubrik leider ausfallen. Diese Woche berührt "das Kommando der Woche" mehr als nur ein Kommando, nämlich die ganze Funktionalität der "file flags". Diese sind meines Wissens nach eine BSD-Eigenart, zumindest habe ich sie unter anderen Unixen noch nicht gesehen.

Mit Hilfe von "chflags" lassen sich die "file flags" eines Files setzen. Die Syntax ist einfach "chflags flags file". Welche Flags dabei legal sind steht in der man page. Als Beispiel lässt sich der installierte Kernel mit "chflags schg /boot/kernel/kernel" gegen Veränderung (schg = system immutable Flag) schützen - das passiert tatsächlich schon bei der Installation des Kernels.

Ein anderes Beispiel sind Logfiles, die mittels "chflags sappend logfile" zu "append only" files gemacht werden können. Das ist zum "Härten" eines Systems sehr interessant, da ein Angreifer seine Spuren nicht mehr durch Manipulation des Logfiles verwischen kann. Dazu muss der "securelevel" des Systems auf einen Wert grösser Null gesetzt werden, denn der Kernel verbietet dann das Ändern der "file flags".

Der "securelevel" lässt sich über "sysctl kern.securelevel" anzeigen und entsprechend mit "sysctl -w kern.securelevel=<Wert>" auf einen anderen Wert setzen (er kann nur erhöht werden).

Die gesetzten Flags lassen sich per "ls -lo" anzeigen, der Output für den Kernel ergibt z.B.:
Code: 
-r-xr-xr-x  1 root  wheel  schg 3406912 Feb 11 14:38 kernel
 
Hi current.

Ha, sehr schön. Ich denke damit können einige Anfänger, die von securelevels noch nie etwas gehört haben, einiges anfangen und es als Einstieg betrachten ihr System "sicherer" zu machen.
 
... und es als Einstieg betrachten ihr System "sicherer" zu machen.
Zum Vergrößern anklicken....
Ja, vielleicht sollten wir mal ein komplettes "securelevel" Tutorial schreiben. Ist sicherlich in Anbetracht der aktuellen Sicherheitslöcher in anderen Systemen ganz informativ und nützlich :)
 
die flags sind ausgesprochen nützlich, gibt's aber in ähnlicher form auch unter linux als attribute für ext2/3 - das kommando chattr (1) und lsattr (1).
 
@current
Nicht nur securelevel Tutorial, ein ganzes Security Tutorial wäre evtl. angebracht, oder?
Ich hätte da auch schon so einiges...
 
Original geschrieben von asg
@current
Nicht nur securelevel Tutorial, ein ganzes Security Tutorial wäre evtl. angebracht, oder?
Ich hätte da auch schon so einiges...
Zum Vergrößern anklicken....

mmh, ich will demnächst mal wieder 'ne cd-based firewall aufsetzen. wichtig ist mir hochverfügbarkeit (hab'sch schonmal mit stp realisiert) und das "policy based routing". dafür könnt' mer mal ein tut schreiben. hat schonmal jemand carp und pfsync getestet?
 
@buebo
Interessieren im Sinne von lesen? Oder interessiere im Sinne von erstellen?
 
Im Grunde lesen, ich wäre zwar bereit zu schreiben, aber meine Kentnisse sind doch eher lückenhaft im Moment.
 
vielleicht sollte man noch erwähnen das der witz bei den file flags eben ist, das ein angreifer die file-flags eben auch nicht ändern kann, da man die file-flags nur im single-usermode wieder zurücksetzen kann und in diesem zustand ist ja kein netzwerk mehr verfügbar;
insofern sind sie sehr sinnvoll für ein sicheres system;
 
@[moR-pH-euS]
Nunja, es würde reichen die betreffende Datei /etc/rc.conf und/oder /etc/sysctl.conf zu bearbeiten. Dort den Flag auf -1 zu setzen, und neu zu starten.
Nur, dazu braucht man root rechte, und wenn dies jemand hat, so hat man andere Probleme.
Wobei man diese Dateien natürlich durch entsprechende flags auch wieder vor Veränderungen schützen kann. Man muss nur abwägen ob man das will...
 
@[moR-pH-euS]:
Danke für dein Feedback! Ich hatte geschrieben:
Dazu muss der "securelevel" des Systems auf einen Wert grösser Null gesetzt werden, denn der Kernel verbietet dann das Ändern der "file flags".
Zum Vergrößern anklicken....
Ist das zu unverständlich ausgedrückt? Was wäre Deine Idee für eine bessere Formulierung?
 
@asg: also ich habe mir ja das netbsd buch vom c&l verlag gekauft und dort wird auch das thema file flags kurz umrissen und dort stand das es eben nur im single-user-mode gehen würde die file-flags wieder zurückzusetzen, das es auch über die rc.conf geht wusste ich nicht aber ist ja logisch indem man den securelevel wieder zurücksetzt;
bei netbsd muss man sich einen neuen kernel backen indem man die option "options insecure" aus- bzw. einkommentiert (wenn die option nicht auskommentiert ist läuft dann das system die ganze zeit im permanent unsicheren modus, also -1, wenn es auskommentiert ist läuft es im securelevel 2); bei netbsd muss man sich also einen neuen kernel backen um den securelevel zu ändern, deswegen wurde der weg über den single-user-mode beschrieben im buch...

@current: das der securelevel geändert werden muss ist schon klar, ich würde vielleicht noch einen nebensatz einschieben in dem du erwähnst das die file flags eben, wenn der secure-level > 0 ist, im single-user-mode zurückgenommen werden können ohne den securelevel zu ändern bzw wie asg sagte man über die rc.conf ja wieder den securelevel zurücksetzen kann auf -1; wäre denke ich noch ganz sinnvoll zu wissen;
 
Zuletzt bearbeitet:
Kann man sich nicht auch versehentlich endg+APw-ltig aussperren? Wenn ich in die /etc/sysctl.conf stehen habe
Code: 
kern.securelevel=3
und dann diese Datei wiederum mit chflags schg /etc/sysctl.conf "versiegele", habe ich doch wohl anschlie+AN8-end ein ernsthaftes Problem, die Securelevel wieder herabzusetzen - oder? Schlie+AN8-lich wird och im Single-User-Modus immer noch die /etc/sysctl.conf mitgestartet, so da+AN8- ich auch dann den Securelevel nicht mehr herabsetzen kann.
 
Original geschrieben von [moR-pH-euS]
@asg: also ich habe mir ja das netbsd buch vom c&l verlag gekauft und dort wird auch das thema file flags kurz umrissen und dort stand das es eben nur im single-user-mode gehen würde die file-flags wieder zurückzusetzen, das es auch über die rc.conf geht wusste ich nicht aber ist ja logisch indem man den securelevel wieder zurücksetzt;
bei netbsd muss man sich einen neuen kernel backen indem man die option "options insecure" aus- bzw. einkommentiert (wenn die option nicht auskommentiert ist läuft dann das system die ganze zeit im permanent unsicheren modus, also -1, wenn es auskommentiert ist läuft es im securelevel 1); bei netbsd muss man sich also einen neuen kernel backen um den securelevel zu ändern, deswegen wurde der weg über den single-user-mode beschrieben im buch...
Zum Vergrößern anklicken....

Die insecure Geschichte ist eigentlich nur für X11 gedacht, da die SecLevel ja auch den Schreibzugriff auf /dev/{k}mem unterbinden können und X11 somit kein memory mapping mehr auf die GraKa machen kann.
BTW, für X3.3 gab es mal einen Wrapper der es erlaubt hat X mit SecLevel>0 zu betreiben.

File Flags Proposal von Lex Wennmacher für NetBSD:
http://www.free-x.ch/pub/proposal.txt
 
Zuletzt bearbeitet:
Original geschrieben von Heidegger
Kann man sich nicht auch versehentlich endg+APw-ltig aussperren? Wenn ich in die /etc/sysctl.conf stehen habe
Code: 
kern.securelevel=3
und dann diese Datei wiederum mit chflags schg /etc/sysctl.conf "versiegele", habe ich doch wohl anschlie+AN8-end ein ernsthaftes Problem, die Securelevel wieder herabzusetzen - oder? Schlie+AN8-lich wird och im Single-User-Modus immer noch die /etc/sysctl.conf mitgestartet, so da+AN8- ich auch dann den Securelevel nicht mehr herabsetzen kann.
Zum Vergrößern anklicken....

Also IMO sollte zumindest bei NetBSD der Single User Mode SecLevel ignorieren, du könntest aber doch anderenfalls bspw. die InstallCD booten, / mounten und in /etc/ rumeditieren wie du willst.
 
Original geschrieben von Heidegger
Kann man sich nicht auch versehentlich endg+APw-ltig aussperren? Wenn ich in die /etc/sysctl.conf stehen habe
Code: 
kern.securelevel=3
und dann diese Datei wiederum mit chflags schg /etc/sysctl.conf "versiegele", habe ich doch wohl anschlie+AN8-end ein ernsthaftes Problem, die Securelevel wieder herabzusetzen - oder? Schlie+AN8-lich wird och im Single-User-Modus immer noch die /etc/sysctl.conf mitgestartet, so da+AN8- ich auch dann den Securelevel nicht mehr herabsetzen kann.
Zum Vergrößern anklicken....

im single user mode wird rc aber ned ausgeführt - und somit auch die sysctl.conf ned ausgelesen - also kein secure level gesetzt.
 
@[moR-pH-euS]:
... das die file flags eben, wenn der secure-level > 0 ist, im single-user-mode zurückgenommen werden können ohne den securelevel zu ändern
Zum Vergrößern anklicken....
Das stimmt nicht. Siehe 'man securelevel':
... Since the level cannot be reduced, it will be at least 1 for subsequent operation, even on return to single-user.
Zum Vergrößern anklicken....

@Heidegger
... wird doch im Single-User-Modus immer noch die /etc/sysctl.conf mitgestartet
Zum Vergrößern anklicken....
Auch das stimmt nicht (zumindest unter 5.x). Die /etc/sysctl.conf wird nur bei normalem Boot gelesen, nicht im single user boot.
 
Original geschrieben von current
@[moR-pH-euS]:

Das stimmt nicht. Siehe 'man securelevel':


@Heidegger

Auch das stimmt nicht (zumindest unter 5.x). Die /etc/sysctl.conf wird nur bei normalem Boot gelesen, nicht im single user boot.
Zum Vergrößern anklicken....

damit wollte ich nur ausdrücken, das wenn man ein securelevel fährt (1 oder 2) indem die file-flags auch greifen, man in den single-user-mode geht (securelevel 0) um die file-flags wieder zu verändern oder zurückzunehmen;
man muss ja nicht den securelevel vom system auf 0 oder -1 setzen um die file-flags wieder zu ändern, das geht ja dann bequem über den single-user-mode;
das ist ja auch sehr sinnvoll da im single-user-mode kein netzwerk vorhanden ist und der angreifer dann schon lokal an der kiste sitzen müsste (oder er backt sich einen neuen kernel mit options insecure und ist dann wieder im unsicheren modus...)
vielleicht habe ich mich etwas komisch ausgedrückt, aber das stimmt doch ?
 
Nein, der Angreifer müsste nur, wie schon gesagt, den entsprechenden Wert in der rc.conf oder sysctl.conf verändern. Danach einfach einen reboot machen. Und schon wars das mit dem securelevel.
 
aber wenn ich schon mit flags arbeite, dann setze ich doch die sysctl.conf und rc.conf auch...
dann gehts nur noch mit physischem access ur maschine
 
Wenn man das will, wie ich schon schrieb, macht man das auch. Aber unter uns Pastorentöchtern, wenn jemand die Dateien bearbeiten könnte, dann hat man ganz andere Probleme als die flags, imho.
 
Original geschrieben von asg
Nein, der Angreifer müsste nur, wie schon gesagt, den entsprechenden Wert in der rc.conf oder sysctl.conf verändern. Danach einfach einen reboot machen. Und schon wars das mit dem securelevel.
Zum Vergrößern anklicken....

ja du hast recht, habe gerade mal in die /etc/defaults/rc.conf geschaut:

# Security setting. If $securelevel is non-empty, the system securelevel
# is set to this value early in the boot sequence. Otherwise the default
# action is taken (see init(8)).
#
securelevel="" # securelevel to set to
Zum Vergrößern anklicken....

die sysctl variable kann allerdings zur laufzeit nur erhöht werden man kann sie zur laufzeit nicht herabsetzen, aber über die rc.conf und einen neustart eben...
im netbsd buch wird auf diese sysctl-variable gar nicht hingewiesen wenn es um file flags geht, deswegen dachte ich schon man müsste erst einen kernel mit options insecure basteln um wieder auf securelevel -1 zu kommen...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben