PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ist es möglich root aus filesystem auszusperren



koma0815
26.03.10, 16:22
Hallo,
habe die Anforderung das die Daten die eine Applikation schreibt nur vom User der Applikation gelesen werden können, nicht von anderen und auch nicht von root.

Fällt hier jemanden eine Lösung ein?

Vielen Dank

muell200
26.03.10, 16:25
erstmal willkommen auf dem board



Fällt hier jemanden eine Lösung ein?


nein - bin aber nicht 100% sicher :)

ABER ein richtiger root kann sowieso alles wiederherstellen....

( ausser du hast einen hobby-root bzw. hobby-admin :) )

was soll das auch bringen?

koma0815
26.03.10, 16:27
erstmal willkommen auf dem board



kann ich dir nicht 100% beantworten...

ABER ein richtiger root kann alles wiederherstellen....

( ausser du hast einen hobby-root bzw. hobby-admin :) )

was soll das auch bringen?

bin ja bei dir (su - user und schon ist das Problem ausgehebelt)
ABER: Die Anforderung des Projekts lautet so!

muell200
26.03.10, 16:31
ABER: Die Anforderung des Projekts lautet so!

super - dann kannst du ins wochenende gehen...

das projekt ist abgeschlossen

loesung: es nicht nicht moeglich!

Rain_maker
26.03.10, 16:33
ABER: Die Anforderung des Projekts lautet so!

Das erinnert mich irgendwie an $PROJEKTVORGABE bei diversen Projekten, die $STEUERZAHLER zu finanzieren hat.

Da heisst es dann auch oft sowas wie "Die Kosten sollen XYZ Mio. Euro nicht übersteigen" (und es ist in etwa genau so realistisch). :ugly:

naraesk
26.03.10, 17:08
Ich habe damit wenig praktische Erfahrung, aber sollte dies nicht mit ACL gehen?

http://209.85.129.132/search?q=cache:p67GWY3Jsb0J:pvs.informatik.uni-heidelberg.de/Teaching/SKLU-0203/pansef.ppt+acl+root+einschr%C3%A4nken&cd=4&hl=de&ct=clnk&gl=de&client=firefox-a
http://www.netzwurm.de/publications/lm/lids_de.html

Es gab doch einmal ein Projekt, bei dem ein Linux- Rechner mit Rootzugang ins Netz gestellt wurde. Allerdings war es dennoch nicht möglich das System zu übernehmen, da root so sehr eingeschränkt wurde, dass man damit nichts "böses" anstellen konnte.

derRichard
26.03.10, 17:40
Hallo,
habe die Anforderung das die Daten die eine Applikation schreibt nur vom User der Applikation gelesen werden können, nicht von anderen und auch nicht von root.

Fällt hier jemanden eine Lösung ein?


kryptographie ist dein freund.

hth,
//richard

Rain_maker
26.03.10, 17:48
kryptographie ist dein freund.

Daran hatte ich auch schon gedacht, macht aber natürlich nur dann Sinn, wenn zumindest die Abfrage der Daten durch $APPLIKATION mit einer Interaktion des Users verbunden ist.

Salopp gesagt, Verschlüsselung mit z.B. GPG und dann ein Schlüsselpaar ohne Passphrase für $USER anlegen, damit $USER nicht ständig den Key bei Lesezugriff der Applikation auf die gespeicherte Datei entsperren muss, kann man auch gleich bleiben lassen (ja, ich weiß Richard, daß Dir das bekannt sein wird).

Ob diese Interaktion allerdings gewünscht ist, ist eine andere Frage, vor allem, wenn sie "unattended" laufen soll und nicht ständig ein Hansel vor der Kiste sitzt, der alle paar Minuten die Passphrase eintippen muss.

Wene
26.03.10, 20:04
Ich habe damit wenig praktische Erfahrung, aber sollte dies nicht mit ACL gehen?

Ein Kunde hatte mal die ACLs unter Windows zu freizügig vorkonfiguriert. So konnten die Benutzer auf ihren "eigenen" Ordner im Netzwerk die ACLs ändern. Das führte dazu dass sicherheitsbewusste User allen ausser sich selbst den Zugriff verweigerten. Dadurch konnten auch Administrator und Backup-User die Daten nicht mehr lesen... :ugly:

Ist ein Backup auch eine Anforderung an die Applikation?

Kryptographie müsste allerdings schon eine Option sein. Ich bin da zwar kein Experte, Skype schafft es aber z.B. auch seit Jahren sein Protokoll trotz aller Öffentlichkeit geheim zu halten.

marce
26.03.10, 21:00
evtl. auch mal LIDS anschauen - da kann man auch root effektiv beschränken. Jedenfalls so lange, so lange der betreffende root das PW für die "Backdoor" nicht kennt.

Ein allg. Problem: root kann und darf alles. Wenn man root nicht vertraut - hat man ein Problem.

Umsteiger
26.03.10, 23:50
evtl. auch mal LIDS anschauen - da kann man auch root effektiv beschränken. Jedenfalls so lange, so lange der betreffende root das PW für die "Backdoor" nicht kennt.

Ein allg. Problem: root kann und darf alles. Wenn man root nicht vertraut - hat man ein Problem.

/* Benenne root einfach um dann gibt es keinen root und dann kann auch kein root irgendwo zugreifen? */ :ugly: *geht in deckung*

Newbie314
27.03.10, 00:46
@Rain_Maker: so ganz verstehe ich dein Konzept nicht...

Wenn ich Dateien auf einem Rechner ver- und entschlüssele und dort auch meinen private key lagere.. auf dem ich root (aus welchen Gründen auch immer) nicht trauen darf....

Habe ich doch die A* Karte .. oder ? Root kann doch auf meinen privaten Schlüssel zugreifen und damit die Dateien entschlüsseln.. oder mir die Daten beim Verschlüsseln schon wegkopieren oder .... den Ram auslesen oder ...

Wenn Root nicht vertrauenswürdig ist müsste man die Daten doch auf einem anderen Rechner verschlüsseln und auf dem "kompromittierten" Rechner nur verschlüsselt lagern ... ?

(Wenn eine "mandatory access control" installiert ist muss ich demjenigen der die "policies" dafür festlegt trauen.. nicht nötigerweise "root" aber definitiv einem Administrator ...)

marce
27.03.10, 01:22
/* Benenne root einfach um dann gibt es keinen root und dann kann auch kein root irgendwo zugreifen? */ :ugly: *geht in deckung*
ich gehe einfach mal davon aus, daß Du das nicht rein als Spaß gemeint hast: Umbenennen würde nichts daran ändern, daß es einen User mit der UID 0 gibt, der eben im System alles darf.

Umsteiger
27.03.10, 08:07
ich gehe einfach mal davon aus, daß Du das nicht rein als Spaß gemeint hast: Umbenennen würde nichts daran ändern, daß es einen User mit der UID 0 gibt, der eben im System alles darf.

Doch, doch es sollte ein Spass sein... ganz so noob bin ich dann doch nicht :)

Wobei "Newbie314" die wohl einzig "sichere" Lösung genannt hat, die Daten auf einem anderen Rechner verschlüsseln... ansonsten wird der Besitzer des Systems immer an die Daten kommen können...

Rain_maker
27.03.10, 10:50
@Rain_Maker: so ganz verstehe ich dein Konzept nicht...

Wenn ich Dateien auf einem Rechner ver- und entschlüssele und dort auch meinen private key lagere.. auf dem ich root (aus welchen Gründen auch immer) nicht trauen darf....

Der springende Punkt ist "unattended" vs. "Userinteraktion".

Einen Key kann man durch eine Passphrase schützen, siehe z.B. GPG, nur dann ist eben Interaktion mit $ANWENDER notwendig.

Das würde falls überhaupt -mein Post ging auch eher in die Richtung "vielleicht machbar aber alles andere als praktikabel"- dann funktionieren, wenn man alles "abdichtet", was auf der Kiste selbst passiert, die Daten dürfen nirgends unverschlüsselt auf $DATENTRÄGER liegen (das ist trivial), ob/wie man auch den Arbeitsspeicher schützen kann, war dabei nicht mal in der Überlegung drin.

Und selbst, wenn die Daten auf $ANDERER_KISTE liegen würden, muss man noch dafür sorgen, daß sie auf der Kiste mit $APPLIKATION nie unverschlüsselt im Arbeitsspeicher landen.

Mein "Konzept" war eher ein Gedankenspiel, warum es eher unpraktikabel ist und nicht, wie ich mir das als "so wird das sicher gehen" vorstelle.

Marce hat vollkommen recht mit diesem Satz hier:

"Ein allg. Problem: root kann und darf alles. Wenn man root nicht vertraut - hat man ein Problem."

Sicherheit beginnt immer mit Vertrauen und baut darauf auf, alles andere ist (und ich zitiere hier einen uns allen bekannten Herrn mit den Initialen L.T.) "Masturbation".

//Edit: Quelle

http://en.wikiquote.org/wiki/Linus_Torvalds

und vollständiges Zitat:

"If you have ever done any security work – and it did not involve the concept of "network of trust" – it wasn't security work, it was masturbation."

Zwar mag "uns Linus" schon einigen Mist von sich gegeben haben, aber hier hat er 100%ig recht.

Los_Andros
27.03.10, 19:09
Um Root auszusperren musst Du auf Labelbasierte MAC Systeme zurückgreifen.

SELinux kann das, Apparmor kann das, hier reicht es nicht aus "nur" root zu sein, man muss im entsprechenden Kontext auf eine Datei zugreifen.

Beispiel:
Verzeichnis /ABC gehört user Hans, Hans hat das Label "geheim", /ABC hat das Label "geheim".

Probiert Root mit seinen Rechten "root" und dem Label "Administrator" darauf zuzugreifen, dann bekommt er ein nettes "Permission denied" und es wird ein entsprechender Logsatz in /var/log/audit/audit.log geschrieben.



Also, 1. welches System hast Du (Ubuntu und Opensuse bauen noch auf Apparmor, die anderen auf SELinux) und 2. wievieol Zeit hast Du.

Denn Zeit ist hier der kritische Faktor, Du musst SELinux / Apparmor erstmal verstehen lernen und Dich in die MAterie MAC und DAC einlesen.

Entgegen meiner Vorredner kann ich Dir aber versichern, es geht.

Umsteiger
27.03.10, 19:37
Um Root auszusperren musst Du auf Labelbasierte MAC Systeme zurückgreifen.

SELinux kann das, Apparmor kann das, hier reicht es nicht aus "nur" root zu sein, man muss im entsprechenden Kontext auf eine Datei zugreifen.

Beispiel:
Verzeichnis /ABC gehört user Hans, Hans hat das Label "geheim", /ABC hat das Label "geheim".

Probiert Root mit seinen Rechten "root" und dem Label "Administrator" darauf zuzugreifen, dann bekommt er ein nettes "Permission denied" und es wird ein entsprechender Logsatz in /var/log/audit/audit.log geschrieben.



Also, 1. welches System hast Du (Ubuntu und Opensuse bauen noch auf Apparmor, die anderen auf SELinux) und 2. wievieol Zeit hast Du.

Denn Zeit ist hier der kritische Faktor, Du musst SELinux / Apparmor erstmal verstehen lernen und Dich in die MAterie MAC und DAC einlesen.

Entgegen meiner Vorredner kann ich Dir aber versichern, es geht.

Aber hat nicht root die rechte SE-Linux mal eben zu aktivieren bzw. zu deaktivieren ? Irgendwer muss ja am ende das System Administrieren und dieser müsste doch auch darüber die letzte Gewalt haben ?

Los_Andros
27.03.10, 20:21
Aber hat nicht root die rechte SE-Linux mal eben zu aktivieren bzw. zu deaktivieren ? Irgendwer muss ja am ende das System Administrieren und dieser müsste doch auch darüber die letzte Gewalt haben ?

Ja, Root hat grundsätzlich das Recht selinux zu administrieren, aber wenn selinux mit immutable gestartet wurde, dann lässt es sich nicht deaktivieren, nur ein Neustart des Systems kann für den Administrator helfen. Das muss man entsprechend überwachen und in einer richtigen Konfiguration eines MAC Systems kann Root selbst garnichts mehr machen, die Rechte sind dann entsprechenden anderen Rollen und Gruppen zugeordnet..

SELinux erlaubt es, eine sehr strikte Trennung der Verantwortlichkeiten zu gewährleisten, was auch dazu führt, dass der Root User kaum Möglichkeiten hat. Denn selbst den Reboot könnte man mittels SELinux dem Root User entziehen und dafür anderen Benutzern das Reboot Recht gewähren.

Aber wie gesagt, die Zeit ist der entscheidende Faktor, SELinux ist sehr komplex, Apparmor ist etwas einfacher, aber dennoch in voller Konfiguration ebenfalls komplex.

Hier findest Du mehr Infos, das Projekt wurde damals aufgrund militärischer Vorgaben vom DoD initiiert und wird zusätzlich von Red Hat maßgeblich unterstützt. Bei jedem neuen Kernel ist SELinux mit an Bord, Apparmor ist bei Ubuntu und Opensuse mit dabei.:
http://www.nsa.gov/research/selinux/index.shtml
http://www.os-t.de/buecher_new.php
http://wiki.ubuntuusers.de/AppArmor
http://de.opensuse.org/AppArmor
http://linuxwiki.de/SELinux
http://fedoraproject.org/wiki/SELinux

Newbie314
27.03.10, 20:50
Auf dem Heim- oder Uni Rechner bootet man dann halt ein Knoppix ;-)

Bei physikalischem Zugang kommt man an unverschlüsselte Daten schon ran... nur fällt der Einbruch bei einem gut aufgesetzten System auf...