Ausführbare Dateien über acls verhindern

[wow]

Hallo,

aus Sicherheitsgründen möchte ich in Homeverzeichnissen und anderen Verzeichnissen, in die User schreiben dürfen, das Anlegen von ausführbaren Dateien verhindern.

Dazu gibt es die Möglichkeit durch die Mountoption noexec (s. auch diesen Thread:

http://www.debianforum.de/forum/viewtop ... 908#529908 ).

Eine andere Möglichkeit wären, wenn ich es richtig verstanden habe, die acls.

Hier verstehe ich nicht so ganz, wie ich für zukünftige Dateien die Rechte so setzen kann, daß neu angelegte Dateien nie ausführbar sein können. Geht das überhaupt mit den acls oder unterliege ich einem Irrtum?

Beispiele, die ich mir angeschaut habe (u.a. die Manpage) gehen immer von vorhandenen Dateien aus. Und das nützt ja für zukünftige Dateien nichts. Oder werden zukünftige Dateien mit erfaßt, wenn ich anstatt des Dateienamen einen Asterisk angebe?

MfG

Wolfram

[Methusalix]

Hallo,
die Rechte neu angelegter Dateien werden ja über die umask-Maske eingestellt.
Da würde ich erst mal ansetzen.

Code: Alles auswählen

man umask

Gruß
Matthias

[herrchen]

die Rechte neu angelegter Dateien werden ja über die umask-Maske eingestellt.

richtig, allerdings kann man die rechte als "besitzer" nachträglich ändern.

herrchen

[KBDCALLS]

die Rechte neu angelegter Dateien werden ja über die umask-Maske eingestellt.

richtig, allerdings kann man die rechte als "besitzer" nachträglich ändern.

herrchen

Das müßte sich mit sudo verhindern lassen.

[meandtheshell]

aus Sicherheitsgründen möchte ich in Homeverzeichnissen und anderen Verzeichnissen, in die User schreiben dürfen, das Anlegen von ausführbaren Dateien verhindern.

Warum?

Das ist aus meiner Sicht nicht notwendig denn ein "normaler" User ist ohnehin nicht in der Lage über sein /home hinaus Schaden anzurichten. Auch ein ausführbares Skript das er dort ablegt läuft ja mit seiner UID und kann genausowenig "mehr" machen als der User wenn der z.B. per ssh in die Maschine geht.

Warum möchtest du das machen bzw. warum denkst du das ein out-of-the-box Debian zu wenig ist?
Das ist es nicht zumindest was exekutierbaren User Code angeht.

Ich denke du bist evtl. eher daran interessiert Usern ein /home zu geben in dem Sie arbeiten können, wo diese aber nicht die vorhandene default Struktur verändern können:
- Verzeichnislayout
- gewisse files
- etc.
wo sie aber sehrwohl in der Lage sind eigene Dinge (files etc.) anzulegen, diese zu editieren und evtl. wieder zu löschen aber eben nicht mehr als diese d.h. das Layout das du Ihnen gibst ist immer der Punkt an dem Sie nicht weiterkommen.
Das kannst du mit

Code: Alles auswählen

chattr

erreichen indem du
- das Layout der homdirs für die User anlegst
- dann rekursiv chattr anwendest z.B. chattr -Ridu /home/<user>
dann lässt du die User darauf los und bist sicher das Sie den "harten Kern" ihres /home nicht verändern können.


Markus

[wow]

@meandtheshell

Warum will ich das Ausführen von Dateien im Homeverzeichnis und anderen Verzeichnissen verhindern?

Vielleicht bin ich paranoid. Aber angeregt durch Meldungen über den Bundestrojaner halte ich es auch unter Linux nicht für abwegig, daß einem User bspw. über den Browser ein Schnüffelprogramm untergejubelt wird. Dieses Programm könnte ja dann Informationen über den Inhalt der Platte, soweit für ihn lesbar, übermitteln. Wenn dieses Programm jedoch nicht ausgeführt werden dürfte, dann ginge dieses Programm ins Leere. Entsprechendes gilt eben auch für Verzeichnisse, in die der User schreiben darf (bspw. /tmp oder /var/tmp). Das ist mein Gedanke.

Chattr kommt wohl für mich nicht in Betracht, da ich jfs nutze.

Mit freundlichen Grüßej

Wolfram

[meandtheshell]

Gut dann

Code: Alles auswählen

mount -o noexec -rbind /home /home_noexec

Ob das auch für jfs funktioniert kann ich nicht prüfen.

btw - ich denke nicht das wir die einzigen sind die dem Bundestrojaner die Möglichkeit nehmen wollen seine Nase in die Privatangelegenheiten der Bürger zu stecken. Ich bin mir sicher dazu ist schon mehr im Netz - hat dazu jemand schon was gefunden?

Markus

[wow]

Hallo Marcus,

die Idee mit dem noexec hatte ich auch. Aber dann habe ich aber vor ein Paar im Web gelesen -den Link habe ich leider verloren-, daß dieses umgangen werden kann. Man ruft die passende Library in Kombination mit dem Programm auf und schon ist es im noexec Directory ausführbar.

[meandtheshell]

Der Link muss her bzw. andere Lösungsansätze für das Problem.
Happy googling



Beste aber sicher aufwändigste Lösung:
Schlußendlich kann man sich einen grsecurity [0] Kernel installieren und secure path execution verwenden.
Im Grunde funktioniert das so, dass jedes exekutierbare Programm einer Bestätigung des Users Bedarf bevor es das erstemal ausgeführt (bzw. vor jeder ausführung = einstellbar) wird. So hat man Kontrolle über was passiert und das auf Kernelebene. Alles ist mittel Paketmanagementsystem zu bekommen - kompilieren muss man den Kernel aber (es gibt kein fertiges binary).

Code: Alles auswählen

markusgattol@pc1:~$ acs 'grsecurity|gradm2'
chpax - user-space utility to control PaX flags
gradm - Administration program for the GrSecurity ACL system
gradm2 - Administration program for the grsecurity2 RBAC based ACL system
kernel-patch-grsecurity2 - grsecurity kernel patch - new major upstream version
paxctl - user-space utility to control PaX flags - new major upstream version
paxtest - Test suite for the PaX kernel patch
markusgattol@pc1:~$ 

Nachteil:
- das ist im Grunde whitelising und am Anfang auf einem Desktopsystem wird man sicher 2-3 Tage nichts anderes machen als jeden kleinen Spass zu bestätigen - an ernsthaftes arbeiten ist während dieser Phase wohl nicht zu denken.
-Desweiteren, einmal eingerichtet, ist der Zeitaufwand um ein solches System zu betreuen und zu administrieren sicher um den Faktor 3-5 höher als bei normalen Systemen.
- nicht sorgfältig gemacht ist alles nichts wert - dazu muss man sich die ganze docu durchlesen und alles verstehen
- imho ist das sogar für den fortgeschrittenen User zu anspruchsvoll (nicht das Einrichten aber das wissen was eigenlich im System passiert wenn man das Zeug verwendet fehlt)

Ich habe das bei Servern im Einsatz - kostet mindestens einen Tag bis man die Programme und Dienste die da laufen (und das sind ~ 10% von dem was auf Desktops an ausführbaren Programmen läuft) gewhitelistet hat.

Vorteil:
das ist eine grundsolide, allesumfassende Lösung die, wenn sorgfältig gemacht eigentlich keine Risiken offen lassen sollte

Am Desktop habe ich das noch nicht, da ich aber paranoid++ bin wird das wohl bald gemacht werden. Muss ich eben einmal ein paar Tage zum Enter drücken, nachforschen und lesen einplanen

[0]
http://en.wikipedia.org/wiki/GrSecurity
http://debian.linux-systeme.com/
http://www.grsecurity.net/confighelp.php
http://silentwire.net/~lobo/files/grsec.txt <--- davon (gradm) redete ich oben - das benötigt Zeit, viel Zeit und Sorgfalt
http://www.c3a.de/wiki/index.php/Grsecurity
http://forums.grsecurity.net/viewtopic. ... c61856dc0a
http://forums.grsecurity.net/viewtopic. ... f4433226ef
http://forums.grsecurity.net/viewtopic. ... 47867dc205
http://forums.grsecurity.net/viewtopic.php?p=5566&
http://forums.grsecurity.net/viewtopic. ... 13636a40dc
Teils sind die Links nicht mehr so aktuell aber das Prinzip bleibt ja das gleiche - die neuen Softwareversionen muss man eben nehmen.

Und weil so oft von Anfänger zu grsec bzw. pax gefragt: Nein, es gibt keine fertig kompilierten Kernelpakete weil man sein System eben "trainieren" muss (siehe oben).


Markus

[Savar]

Vielleicht bin ich paranoid. Aber angeregt durch Meldungen über den Bundestrojaner halte ich es auch unter Linux nicht für abwegig, daß einem User bspw. über den Browser ein Schnüffelprogramm untergejubelt wird. Dieses Programm könnte ja dann Informationen über den Inhalt der Platte, soweit für ihn lesbar, übermitteln.

vielleicht interessiert dich ja https://www.debianforum.de/forum/viewtopic.php?t=85150
wenn du dann die Kritischen Sachen wie Online-Banking und Einkaufen nur über fest definierte Seiten machst und das dann als dein normaler User, dann bist du ziemlich sicher (behaupte ich einfach mal)..

[wow]

@savar

Dein Lösungsvorschlag ist auch ein gangbarer Weg, wenn man diesen User für Standardsurfen oder nur sicheres Surfen benutzt; je nach dem wie man an die Sache herangeht. Allerdings ist ein Nachteil damit noch nicht aus dem Wege geräumt:

Programme können immer noch immer überall ausgeführt werden. Obwohl natürlich bei restriktiver Bestimmung der Leserechte die wirklich privaten Daten des anderen Users nicht gelesen werden können. Aber kann ich mir sicher sein, daß dieses wie auch immer installierte Programm den Netzwerkverkehr nicht ausschnüffelt?

@meandtheshell

Das grsecurity habe ich zwischenzeitlich installiert. Eine zugegebenermaßen quick and dirty Installation -insbes. mit dem Trusted Path- hat schon erste Verbesserungen gebracht. Nunmehr kann der einfache User nicht mehr in Verzeichnissen wie /tmp usw. Programme, die dort liegen, ausführen. Das Problem mit seinem Homeverzeichnis bleibt bislang noch bestehen. Hier kann er nach wie vor Anwendungen ausführen, die in seinem Verzeichnis liegen. Aber vielleicht liegt das im Moment an meiner quick und dirty Konfiguration, die in den nächsten Tagen selbstverständlich verfeinert werden muß.

MfG

Wolfram

[KBDCALLS]

Da hilft dann /home /tmp usw. jeweils auf eine extra Partition . Und die mit noexec mounten.

[wow]

@kbdcalls

Leider hilft das nicht.

Wenn in ein noexec gemountetes Verzeichnis eine Anwendung kopiert und diese direkt in diesem Verzeichnis aufgerufen wird, funktioniert das noexec.

Aber rufe mal die Anwendung in dem "eingeschrängten" Verzeichnis wie folgt auf:

Code: Alles auswählen

 bash ./<Anwendung> 

Die Anwendung wird gnadenlos ausgeführt. Und schon sind wichtige Sicherheitsbemühungen außer Kraft gesetzt.

Das Problem mit der bereits erwähnten Library ist zum Glück mittlerweile beseitigt.

MfG

Wolfram

[meandtheshell]

- das ganze noexec mounten ist ohnehin imho nicht gut - so unterbindet man Dinge die man evtl. doch ausführen lassen möchte
- @wow: nein, richtig konfiguriert kann auch root nicht mehr alles machen; es gibt einer neuen User (lesen!) welcher mächtiger ist als root; deine Leute in ihren /home dirs kannst du zu 100% kontrollieren (lesen!)

Markus

[wow]

@meandtheshell

Mittlerweile ist es mir über grsecurity auch gelungen, den User meinen Anforderungen entsprechend einzuschränken. Er kann in seinem eigenen Verzeichnis und in den anderen, in denen er schreiben darf, keine Anwendung mehr ausführen.

Ohne selbstherrlich zu sein zu wollen, ist das schon aus Sicht des Bundestrojaners ein großer Schritt, um Stasi2 das Leben schwerer zu machen. Denn jetzt kann ich -aus Nachlässigkeit oder warum auch immer- versehentlich ein Programm abspeichern lassen; und der Browser soll meinetwegen versuchen, das Programm auszuführen. Es wird nicht gehen.

Die anderen Dinge bzgl. von grsecurity werden natürlich jetzt auch in Angriff genommen.

MfG

Wolfram

[Saxman]

@kbdcalls

Leider hilft das nicht.

Wenn in ein noexec gemountetes Verzeichnis eine Anwendung kopiert und diese direkt in diesem Verzeichnis aufgerufen wird, funktioniert das noexec.

Aber rufe mal die Anwendung in dem "eingeschrängten" Verzeichnis wie folgt auf:

Code: Alles auswählen

 bash ./<Anwendung> 

Die Anwendung wird gnadenlos ausgeführt. Und schon sind wichtige Sicherheitsbemühungen außer Kraft gesetzt.

Das Problem mit der bereits erwähnten Library ist zum Glück mittlerweile beseitigt.

MfG

Wolfram

Was du schreibst kann Ich bei mir nicht nachvollziehen.
Hab mein /home ,noexec gemountet.

Rufe ich eine Anwendung direkt auf

Code: Alles auswählen

 $ ./google-earth/googleearth-bin 
bash: ./google-earth/googleearth-bin: Keine Berechtigung

und auch mit deinem Befehl:

Code: Alles auswählen

 bash ./google-earth/googleearth-bin 
./google-earth/googleearth-bin: ./google-earth/googleearth-bin: cannot execute binary file

???