zurück vorwärts Inhalt Stichwörter

Booten bei lokaler Sicherheit


Booten bei lokaler Sicherheit

Da gilt folgendes: Alle Prozesse oberhalb SECRESH.EXE sind 'ROOT'-Prozesse, alle unterhalb laufen auf USER-Level mit Ausnahme der Prog's die mit 'priv Befehl' vom Admin gestartet werden.

Falls niemand eingelogged ( angemeldet ) ist gilt:


Vorsicht bei Win/OS2:
Ich betreibe eine Gruppe winuser, die die INI's schreibend aber nicht löschend beglücken darf. Ein ganz simples 'net access drive:\os2\mdos /add local: users: winuser:rx' verhindert das die DOS und Windows Emulation von Usern, die nicht 'win-user' zugehoeren ausgefuehrt wird. Local wird also keine DOS Spiele betreiben und das System unnötig blockieren.
( Ätsch !! ). Auch Netscape und Konsorten kann man so recht gut stoppen.

Ein hypothetischer Befehl auf eine Ressource:
'net access ressource /add local:rx users: data:rx'
macht folgenden Sinn: An der Konsole können alle User ('lokal') zugreifen, im Netz keiner ('users:', 'local' hat im Netz keine Rechte,) es sei denn er gehoert der Gruppe 'data' an, ich benutze diese Kombination bei meinem WEB Server mit Erfolg.

Es gilt folgende Hierarchie:


Eigene Gruppen und User:
Selbstdefiniert, Rechte Lokal und im Netz.
Ein übles Thema ist: Rechte im FS können nur geändert werden, wenn der Requester läuft ( bis dato keine andere Erkenntnis ), also muss MPTS oder Thinlaps laufen, zu gross fuer eine BOOTFLOPPY. Toll IBM.

Abhilfe: Service-Partition, somit können auch User basteln oder einfach vom Wechselmedium booten ( Removable Media FAQ, Kapitel 2 oder 3) User können den BOOT-Manager nicht modifizieren.

vorwärts Inhalt Stichwörter