debianforum.de

Hallo
ich habe ein ziemlich schwieriges Problem. Daten sollen vor dem Zugriff von root geschützt werden,
so das ich als root diese nicht einsehen kann. Gleichzeitig sollen sie aber über eine Samba Freigabe von aussen für mehrere Personen erreichbar sein.

Meine erste Idee basierte auf Truecrypt, so das ich eine Containerdatie auf der Freigabe abgelegt habe, die dann von den Windows Clients eingebunden wurde. Idee war ganz brauchbar,
aber es kann immer nur einer auf die Datei zugreifen.

Gibt es vieleicht über ACL's ne Lösung, so das ich als root den Inhalt nicht sehe, aber mehrere Nutzer den Ordner nutzen können?

Naja, im ersten Moment klingt die Anforderung ja recht sinnvoll, aber je mehr man drüber nach denkt, umso sinnloser kommt es einen vor.

Wenn man dem Systemadmin nicht trauen, dann ist es völlig abwegig ihn weiter als Systemadmin zu haben. So einfach ist das.

Mit selinux lässt sich selbst root einschränken. Google mal nach RBAC. Zum Sinn oder Unsinn sage ich mal nix, und zu den Anforderungen um das vernünftig zu implementieren schon 5 mal nix...

Saxman hat geschrieben:Mit selinux lässt sich selbst root einschränken.

Das war auch mein erster Gedanke, aber wer setzt die Regeln auf? Und wer hat das Recht die wieder zu ändern? Richtig root.

bmario hat geschrieben:

Saxman hat geschrieben:Mit selinux lässt sich selbst root einschränken.

Das war auch mein erster Gedanke, aber wer setzt die Regeln auf? Und wer hat das Recht die wieder zu ändern? Richtig root.

Eben nicht, root ist hierbei nur der user, bei selinux geht es dann noch eine Ecke weiter. Jedem Benutzer läßt sich ein Kontext zuweisen, der nur bedingt von dem user geändert werden kann. Ich war schon per ssh root auf einem System da konnte ich buchstäblich nichts machen, und das trotz uid 0. Das war schon interessant.

http://fedoraproject.org/wiki/SELinux/SecurityContext

Ja, ich kenne das auch. Aber was nutzt es einem? Wenn man dem Admin nicht vertrauen kann, dann kann man den Server nur in die Ecke stellen und verstauben lassen. Schränkt man root ein, kann der Admin seinen Job nicht tun, was die Sicherheit der Maschine gefährdet. Schränkt man root nicht ein, dann kann man der Machine nicht trauen, da der Admin "böse" Dinge tun könnte.

Und ganz davon abgesehen muss ja der Admin SELinux einrichten. Wenn man ihm also Böswilligkeit unterstellt, dann muss man auch davon ausgehen, das er die SELinux Regeln so anpasst, das er trotzdem Zugriff hat. Es führt einfach kein Weg dran vorbei einen Admin zu haben, der vertrauenswürdig ist.

Das streite ich ja auch gar nicht ab. Derjenige der selinux hierbei administriert kann die Rechte anpassen. Es ging ja hier nur darum den user root einzuschränken. Das kann durchaus interessant sein in manchen Umgebungen. Gerade wenn du z.B verhindern willst, dass zu viel kaputt geht wenn root kompromittiert wird.

OT
SELINUX unter Debian. Gut gebrüllt ihr Löwen. Das geht eigendlich nur mit RHEL ganz sauber. Habe es mehrmals unter Debian probiert. Und bin dann mehrmals zu RHEL übergegangen.
Wie das mit Tomoyo unter Debian ausschaut muss ich mal ausprobieren

Vielleicht solltet ihr es aus einer anderen Richtung betrachten, wenn ROOT nicht in die Buchhaltungs- oder Geschäftsführungsgruppe (Gruppen mit sensiblen Geschäftsbereichen beliebig erweiterbar) schauen darf, kann er oder sie auch nicht für Fehler oder Unregelmässigkeiten verantwortlich gemacht werden.
Ich würde diese Regel eher Selbstschutzmassnahme nennen...
Ich kenne solche Regelungen, aus größeren Firmenkonstrukten, diese sind im Mittelstand eher unüblich, aber nicht undenkbar...

Wenns um einzelne, nicht zu große Dateien und überschaubare Datenmengen geht,
bietet es sich doch an, diese in einer Datenbank (postgresql oder so) verschlüsselt
abzulegen. Hier kann man dann sehr genau Zugriffsrechte lesen, schreiben usw)
einstellen. Außerdem können dann auch viele gleichzeitig zumindest lesend auf
die Daten zugreifen. Dafür sind ja auch Datenbanken da.

So etwas ähnliches hatte ich bei meinem Arbeitgeber vor Jahren auch schon einmal. Es wurde schnell wieder fallen gelassen.
Denn es macht einfach keinen Sinn.
Wie sollen denn die Daten gesichert werden, wenn der Admin keinen Zugriff hat?

Gruß Jörg

das hier:

bmario hat geschrieben:Naja, im ersten Moment klingt die Anforderung ja recht sinnvoll, aber je mehr man drüber nach denkt, umso sinnloser kommt es einen vor.

kann man eigentlich nur unterstreichen.

Hi

jmittendorf hat geschrieben:Wie sollen denn die Daten gesichert werden, wenn der Admin keinen Zugriff hat?

Spätestens das muss ein K.O.-Kriterium für die Aktion sein.
Wenn man dem Admin nicht traut, spätestens auf den Datensicherungen wird er -rein von der Theorie- wieder zugreifen können.
Ich sehe das Aussperren des Root-Users als Unfug an, man holt sich mehr Stress als Nutzen.

unter Novell ging das schon Mitte der 90er und trotzdem lief eine Datensicherung und viel wichtiger: der Restore...