Hallo allerseits,

ich möchte in diesem Thread thematisch auf Sicherheit unter Linux eingehen und dazu das ein oder andere Posting machen. Ich würde mich natürlich freuen, wenn auch andere Linux-Fans den ein oder anderen Beitrag beisteuern würden. Malsehen, was bei der Sammlung alles zusammen kommt. *gespanntbin*

Ich würde euch übrigens bitten, die Threadstruktur einzuhalten. Sprich Kommentare a-la "Cooler Thread" oder "Das ist alles Blödsinn hier" unterhalb von allgemeine Kommentare unterzubringen oder Netzwerk-Hacks¹ halt unterhalb von Netzwerk usw. Außerdem wären halbwegs aussagekräftige Posting-Titel ganz nett.
Ich habe zwar wenig Hoffnung, dass das klappt. Aber vielleicht gibts ja diesbezüglich ne positive Überraschung. :-)

Gruß
MichaelK

Hier drunter sollten allgemeine Kommentare zum Thread gepostet werden.

In dem Subthread gibts Tipps und Tricks zur Systemabsicherung.

Postings zur Absicherung des Netzwerkes (Firewalling usw.).

In diesem Posting soll es um das Thema Posix Capabilities gehen.

Erstmal zur Erklärung vorneweg. Linux unterscheidet ja zwischen root und gewöhnlichen Benutzern. Manche Aufgaben lassen sich aber nur als root erledigen. Wie das Ändern des eigenen Passworts zum Beispiel, weil hierzu die entsprechenden Systemdateien im Verzeichnis /etc/ manipuliert werden müssen.

Üblicherweise wird das heutzutage in den meisten Distributionen so gelöst, dass das SUID-Bit gesetzt ist. Wenn man ein Programm startet, wo dieses Bit gesetzt ist, dann wird dieses Programm nicht mit den Rechten ausgeführt, die der Benutzer hat, sondern mit den Rechten, die der Besitzer der Programmdatei hat. Im Falle von ping eben root.

Eigentlich ist dieses Prinzip aber sicherheitstechnisch nicht wirklich gut. Hat ein Programm ein Bug bzw. eine Sicherheitslücke, so ist das gesamte System gefährdet. Und ein solches Programm braucht normalerweise gar nicht das gesamte Set an Root-Rechten. Es braucht meist nur Bestimmte davon. Was liegt also näher, dieses Programm auf die nötigen Rechte zu beschränken?

Und genau hier setzen die sogenannten Posix Capabilities an. Sie bieten eine Alternative zum SUID-Bit an und ermöglichen es gezielt Rechte zu vergeben.

Vorraussetzung für die Nutzung sind:

• ein Kernel mindestens Version 2.6.24¹ und der mit File-Capabilities kompiliert wurde
  nachprüfbar mit grep '\(SECURITY_FILE_CAPABILITIES\)' /boot/config-`uname -r`
• ein Dateisystem, dass erweiterte Attribute speichern kann wie beispielsweise ext3
• die libcap2-Tools
  zu erkennen, ob ls -l /lib/libcap* die dazugehörige Bibliothek findet

• cap_chown
  Dieses Recht erlaubt es, Besitzrechte von Dateien/Ordnern zu ändern
• cap_dac_override
  Ignoriert im Dateisystem gesetzte Lese-/Schreib-/Ausführungsrechte (rwx)
• cap_dac_read_search
  Entspricht cap_dac_override allerdings ohne Ausführungsrechte (bei Dateien) und Schreibrechte
  r für Dateien   rx für Verzeichnisse
• cap_kill
  Erlaubt es jeden Prozess Signale zu schicken (wie KILL zum beenden) und nicht nur Eigenen
• cap_net_admin
  Erlaubt Netzschnittstellenkonfiguration, Ändern von Routing-Tabellen und andere netzwerkspezifische Sonderaufgaben
• cap_net_bind_service
  Erlaubt dem Prozess auf Ports kleiner als 1024 (privilegierte Ports) zu lauschen
  Das ist besonders interessant, da viele Serverprozesse vorallem deshalb als Root laufen müssen, um auf privilegierte Ports lauschen zu können. Mit entsprechenden Folgen für die Sicherheit wie in der Vergangenheit schon vielfach zu bestaunen. Glücklicherweise geben viele Server-Prozesse ihre root-Rechte inzwischen ab, sobald die Netzwerkverbindung steht. Aber ein Restrisiko bleibt. Außerdem gibt es leider noch viele Server die nicht so arbeiten
• cap_net_raw
  Erlaubt den Direktzugriff auf die Netzschnittstelle² (wichtig für spezielle Netzwerktools)
• cap_sys_admin
  Erlaubt verschiedene Administrative Aufgaben wie beispielsweise mounten
  Ist ein sehr umfangreiches Recht
• cap_sys_boot
  Erlaubt einen Reboot
• cap_sys_rawio
  Erlaubt direkten Zugriff auf I/O Ports
• cap_sys_time
  Erlaubt die Systemzeit zu setzen.
  Interessant, um auch normalen Benutzern das setzen der Zeit zu ermöglichen oder den NTP-Client nicht als root laufen lassen zu müssen.

Eine Vollständige Übersicht über alle unterstützten Posix Capabilities erhält man mit:
man capabilities

Zunächst sollte man dem betreffenden Programm natürlich das SUID-Bit entziehen.
chmod u-s /usr/bin/passwd
Damit verliert es seine Allgemeinmacht³ und man kann die benötigten Posix Capabilities hinzufügen.

Die Programme getcap bzw. setcap erlauben es für ein Programm Posix Capabilities abzufragen oder welche zu setzen. Diese Programme sind üblicher⁴weise nur für den Benutzer root aufrufbar.
mit
getcap /usr/bin/passwd
Kann man die gesetzten Posix Capabilities für den Befehl passwd abfragen.

Mit
setcap cap_dac_override=ep /usr/bin/passwd
fügt man das Capabilitiy cap_dac_override für den Befehll passwd hinzu.
Man kann auch mehrere Capabilities auf einmal hinzufügen⁵:
setcap cap_dac_override,cap_sys_time=ep /usr/bin/passwd

Statt dem = gibt kann man auch ein - einsetzen, um gezielt ein Capabilitiy wegzunehmen. Es gibt dann auch noch ein + und neben e und p noch ein i. Aber darauf will ich an dieser Stelle nicht eingehen (Postinglänge!). Details dazu finden sich aber im weiterführenden Link.

Sämtliche Posix Capabilities lassen sich mit
setcap -r /usr/bin/passwd
wieder löschen.

find / -type f -perm +6000 -ls

Nachdem man dem Programm das SUID-Bit entzogen hat, besteht nun die Schwierigkeit darin, die benötigten Posix Capabilities zu ermitteln.

Glücklicherweise gibts dafür ein Kernel-Modul namens capable_probe:
http://www.friedhoff.org/posixfilecaps/capable_probe.tar.bz2
Dies braucht man nur zu kompilieren⁶ und mit insmod bzw modprobe zu laden.
(Quellcode: siehe folgendes Posting)

Prüfen, ob das Modul geladen ist:
lsmod | grep capable_probe

Angeforderte Capabilities tauchen dann in der Logdatei /var/log/messages auf.

Entladen des Moduls geht dann mit:
modprobe -r capable_probe
bzw.
rmmod capable_probe

Einsatz am Beispiel von ping

Das Programm wird ja gerne für Diagnosezwecke eingesetzt, um zu prüfen, ob sich ein anderer Rechner "anpingen" lässt sprich ob er über das Netzwerk prinzipiell erreichbar ist.
Leider benötigt ping für seine Aufgabe root-Rechte, weil die entsprechenden Kernel-Funktionen anders eben nicht ansprechbar sind. Dementsprechend ist auch das UID-Bit gesetzt.

• Zunächst löschen wir das SUID-Bit
  chmod -s /bin/ping
• Nun laden wir das Modul capable_probe
• behalten via tail -f /var/log/messages die Meldungen des Kernel-Moduls im Auge
• dann pingen wir irgendwas an. Beispielsweise: ping www.spin.de
• wir bekommen erwartungsgemäß die Meldung ping: icmp open socket: Operation not permitted
  aber in der Logdatei taucht folgende Meldung auf:
  cr_capable: asking for capability 13 for ping
• zum zu der Nummer den dazugehörige Capability-Namen schauen wir in der Datei /usr/include/linux/capability.h nach:
  grep 13 /usr/include/linux/capability.h
  und erhalten #define CAP_NET_RAW 13
• wir setzen für ping das ermittelte Capability:
  setcap cap_net_raw=ep /bin/ping
• Testen jetzt erneut ping www.spin.de
• Viola! Jetzt funktioniert es ohne, dass das Programme sämtliche Root-Rechte benötigt

Mit dieser Möglichkeit lassen von normalen Benutzern aber Rootrechte brauchenden Programme beschneiden, um im Falle einer Sicherheitslücke oder eines Bugs die Auswirkungen zu begrenzen. Das ist zwar kein Allheilmittel und man muss beim Einsatz trotzdem Umsicht walten lassen aber kann ein sinnvoller Teil des Sicherheitskonzeptes sein.

Das soll jetzt erstmal als Einführung genügen.

Weiterführende Informationen finden sich unter: http://www.friedhoff.org/posixfilecaps.html

Vielleicht hat jemand noch Tipps für andere "SUID-Befehle" und kann die entsprechend benötigten Posix Capabilities dazu nennen.

Gruß
MichaelK

Quelltext von capable_probe.c. Dem Linux-Kernel-Modul, mit denen man angeforderte Posix-Capabilities ermitteln kann.
enthalten in: http://www.friedhoff.org/posixfilecaps/capable_probe.tar.bz2

Zeilennummern

    1 /* taken from
    2  * http://www.ibm.com/developerworks/linux/library/l-posixcap.
    3  html#resources
    4  * Author: Serge E. Hallyn sergeh@us.ibm.com
    5  * 16 Oct 2007
    6  */
    7 #include <linux/kernel.h>
    8 #include <linux/module.h>
    9 #include <linux/kprobes.h>
   10 #include <linux/sched.h>
   11 
   12 static const char *probed_func = "cap_capable";
   13 
   14 int cr_capable (struct task_struct *tsk, int cap)
   15 {
   16     printk(KERN_NOTICE "%s: asking for capability %d for %s\n",
   17            __FUNCTION__, cap, tsk->comm);
   18     jprobe_return();
   19     return 0;
   20 }
   21 
   22 static struct jprobe jp =
   23 {
   24     .entry = JPROBE_ENTRY(cr_capable)
   25 };
   26 
   27 static int __init kprobe_init(void)
   28 {
   29     int ret;
   30     jp.kp.symbol_name = (char *)probed_func;
   31 
   32     if ((ret = register_jprobe(&jp)) < 0)
   33         {
   34             printk("%s: register_jprobe failed, returned %d\n",
   35                    __FUNCTION__, ret);
   36             return -1;
   37         }
   38     return 0;
   39 }
   40 
   41 static void __exit kprobe_exit(void)
   42 {
   43     unregister_jprobe(&jp);
   44     printk("capable kprobes unregistered\n");
   45 }
   46 
   47 module_init(kprobe_init);
   48 module_exit(kprobe_exit);
   49 
   50 MODULE_LICENSE("GPL");

Du lässt also ein Forum als virtuelle Maschine in einem anderen Forum laufen.. ;)

> Du lässt also ein Forum als virtuelle Maschine in einem
> anderen Forum laufen.. ;)

Na so ähnlich. :-)

Viele werden ihre Linux-Kiste in einem privaten Netz hinter einem Home-Router betreiben. Für die sind folgende Tipps also vielleicht nicht ganz so von Belang (wenn auch nicht völlig Ohne).
Wer ein Linux-Rechner aber direkt am Internet betreibt, sollte doch eine gewisse Basis-Absicherung vornehmen.

Viele dieser Einstellung werden über das /proc-Dateisystem vorgenommen und gehen beim nächsten Reboot verloren. Man sollte also die benötigten Einstellung via einer Autostart-Datei wie beispielsweise /etc/rc.local vornehmen. Alternativ dazu lassen sich auch entsprechende Optionen in der /etc/sysctl.conf setzen.

Doch kommen wir nun zu den möglichen Angriffsszenarien und wie man sie erschwert.

TCP-Verbindungen haben die angenehme Eigenschaft sich nach außen hin als Kanal-Verbindung zu präsentieren, obwohl auch dabei ja nur IP-Pakete hin- und hergeschickt werden. Um eine TCP-Verbindung einzuleiten, geschieht folgendes:

1. der Client schickt ein sogenanntes SYN-Paket zum Server
2. der Server antwortet und bestätigt, dass er den Verbindungsaufbauwunsch sozusagen empfangen hat (SYN/ACK)
3. der Client antwortet wiederum auf dieses Paket und bestätigt, dass er die Bestätigung vom Server bekommen hat (ACK)

Damit ist die TCP-Verbindung hergestellt.

Ein mögliches Angriffsszenario besteht nun darin, dem Server ganz viele dieser SYN-Pakete zu schicken. Die Beabsichtigte Wirkung besteht darin, den Server zu überfluten. Dieser behandelt ja jedes einzelne SYN und schickt daraufhin die Antwort zurück und wartet auf die Rückanwort des Clients. In der Zeit sind aber Resourcen für die Verbindung belegt (er muss sich ja merken, dass da Verbindungsanforderungen eingegangen sind und dieses merken kostet zumindest RAM). Im Überflutungsfall kann er gar keine neuen Verbindungen annehmen, so dass auch gewollte Verbindungen nicht mehr durchkommen.
Der Angreifer hat dagegen keine Resourcen-Probleme bei dieser Form des Angriffs. Er muss keine Resourcen für die Verbindungen vorhalten, denn seine Absicht ist es ja gar nicht, eine Verbindung aufzubauen. Er will nur den Server blockieren. Antwortpakete ignoriert er einfach.

Um diese Form des Angriffs zu verhindern bedient man sich sogenannter SYN-Cookies. Der Trick besteht vereinfacht gesagt darin, dass der Server sich die Verbindungsanforderung nicht selbst merkt (und somit kein RAM benötigt), sondern in sein Antwortpaket (SYN/ACK) mit eincodiert. Bei einer regulären Verbindung schickt ja der Client ein vom Serverantwort-Paket abgeleitetes Paket, so dass der Server nachprüfen kann, ob es ein legitimes ACK-Paket des Clients ist. Es lässt sich also auch nicht einfach fälschen. Ein Angreifer muss nun tatsächlich die Antwort des Servers auswerten. Simples überhäufen mit Verbindungsanfragen klappt nicht mehr.

Damit Linux SYN-Cookies verwendet, muss die Variable /proc/sys/net/ipv4/tcp_syncookies auf 1 gesetzt werden z.B. mit:
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

Einer der beliebtesten Schutzmaßnahmen ist die Antwort auf "pings" zu unterdrücken. Kommen solche Pakete, kann man sie mit einfach ignorieren.
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
Allerdings gibt es Möglichkeiten dennoch festzustellen, ob der angepingte Rechner existiert¹. Zudem beraubt man sich selbst einer Diagnosemöglichkeit. Andererseits ist es eben eine zusätzliche Hürde um Angreifer feinzuhalten. Man muss für sich selbst entscheiden, ob das sinnvoll ist oder nicht.

Eine weitere Angriffsmöglichkeit die sich mit ping-Paketen bewerkstelligen lässt, ist eine sogenannte "Smurf-Attacke".
Man trägt im IP-Paket dabei als Antwortadresse die Adresse des Opfers ein. Nun schickt man dieses ping-Paket an eine sogenannte Broadcast-Adresse².
Der Opfer-Rechner wird dadurch mit Ping-Antworten bombardiert.
Eine Schutzmöglichkeit dagegen ist pings auf Broadcast-Adressen nicht zu erlauben.
Konfigurierbar via
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Es gibt natürlich noch viele weitere Einstellungen. Ich will es zunächst bei dieser Aufzählung belassen. Evtl. schreibe ich irgendwann noch eine Ergänzung dazu. Vielleicht ja auch wer anders. :-)

Gruß
MichaelK

Also.... ich bin ja so nett, und halte mich mal an deine "Regeln"....

aber....

also ganz ehrlich?

Ich hab bisher deine Expertise geschaetzt, aber das sieht jetzt heir irgendwie aus wie auf gulli, wo irgendwelche teens moechtegern-howtos frickeln, die sie selbst nicht ganz verstehen.

Nimms mir nicht uebel, das war nur so meine erste Assoziation beim ueberfliegen.

muss man mehr sagen?

Entweder beherrscht du SELinux oder du wirst beherrscht ;-)

verstehst du, was du da postest/kopierst?

Auch wenn der Code von IBM kommt, heisst es nicht automatisch, dass dieser gut ist.
solch ein Kernel-Modul wuerde ich nicht laden ...
Als Beispiel mag es gut sein und funktionieren, aber es ist einfach unschoen programmiert.

tl;dr > Beispiele sollten Beispiele bleiben und nicht in produktiv Umgebungen zum Einsatz kommen.

kennst/kannst du es? nutze es!

super aussage ...

doch zwischen -nutze es- und -nutze es (richtig)- gibts noch immer gewisse - abstaende -

poste doch mal, was deinermeinungnach -sichere- IP-Tables sind?

von mir aus soll als standartbedingung nur surfen (mit drum und dran) zugelassen werden. Bin mal gespannt...

gxn

> Also.... ich bin ja so nett, und halte mich mal an deine
> "Regeln"....

Find ich topp!

> Ich hab bisher deine Expertise geschaetzt, aber das sieht
> jetzt heir irgendwie aus wie auf gulli, wo irgendwelche
> teens moechtegern-howtos frickeln, die sie selbst nicht
> ganz verstehen.

Jeder fängt mal klein an. :-)
Ist ja auch mehr so ne Art Versuch bei dem man einfach guckt, was bei rum kommt.
Außerdem sind Verbesserungen und Diskussion ja durchaus erlaubt. :-)

> Nimms mir nicht uebel, das war nur so meine erste
> Assoziation beim ueberfliegen.

Nö. Ich gestehe ja jedem seine Meinung zu und ist ja auch durchaus interessant, wenn jemand was dazu sagt. Insofern ist alles im grünen Bereich.

Gruß
MichaelK

> verstehst du, was du da postest/kopierst?

Im Großen und Ganzen schon.

> Auch wenn der Code von IBM kommt, heisst es nicht
> automatisch, dass dieser gut ist

Behauptet ja auch niemand. Aber Du hast die Möglichkeit in den Quelltext reinzuschauen und dann möglicherweise bewerten, obs ok ist oder nicht.

> solch ein Kernel-Modul wuerde ich nicht laden ...

Naja. Erstens ist es so kurz und knapp, dass da sich ja nur schwer etwas verstecken lässt.
Und zweitens soll es ja auch nicht dauerhaft geladen sein, sondern nur zum ermitteln der Rechte.
Selbst wenn Du im Zweifel bist, kannste das Ganze immer noch in einer VM laufen lassen. Für die Funktionalität der Posix Capabilities ansich ist das Modul ja völlig ohne Belang.

> Als Beispiel mag es gut sein und funktionieren, aber es
> ist einfach unschoen programmiert.

Ähm. Inwiefern?

> tl;dr > Beispiele sollten Beispiele bleiben und nicht in
> produktiv Umgebungen zum Einsatz kommen.

Das muss dann jeder für sich selbst entscheiden, was er aus den Informationen macht. Es soll ja auch im Wesentlichen nur ein Einstieg sein und die Beispiele in erster Linie veranschaulichen, wie man es benutzt.

Gruß
MichaelK

> muss man mehr sagen?

Wäre schon nett gewesen. :-)

> Entweder beherrscht du SELinux oder du wirst beherrscht
> ;-)

SELinux wird man selbst als Profi-Admin nur schwer implementieren können. Trotzdem kann es natürlich manchmal sinnvoll sein. Ansonsten gibts ja auch durchaus Alternativen dazu.

Konkret geht es ja darum, dass man traditionell ja nur Benutzerrechte hat. Das ist schon ein Fortschritt gegenüber keinerlei Restriktionen zu haben (also als Root bzw. Admin zu arbeiten), aber eigentlich heutzutage nicht mehr ausreichend.
Denn die Programme, die man als Benutzer so ausführt brauchen ja in den wenigsten Fällen alle Rechte die der Benutzer hat. Denn wenn jetzt durch eine Sicherheitslücke (wie beispielsweise im ganz praktischen Beispiel: Browser) Schadcode eingeschleust wird, hat die auch automatisch alle Rechte die der Benutzer hat und kann damit ja schon viel Schaden anrichten.

Und hier setzen Lösungen wie SELinux, AppAmor und Co an, die sozusagen ermöglichen ein Subset an den Benutzerrechten einem Programm zuzuordnen. Wenn dann mal Schadcode eingeschleust wird, ist die Auswirkung dann nicht mehr ganz so gravierend.
Microsoft hat teilweise auch solche Beschränkungsmechanismen. Zum Beispiel für den InternetExplorer ab Windows-Vista unter dem Namen "geschützter Modus".

Gruß
MichaelK

Da hier schon mal Netfilter bzw. dessen Konfigurationsprogramm iptables genannt wurde, möchte ich auch gleich mal ein Posting dazu machen.
Es geht mir hier aber weniger darum, eine 100% Lösung zu präsentieren, sondern eher ein weiter entwickelbaren Ansatz.
Insofern denke ich mal, es wird durch weitere Postings nach und nach ergänzt und vielleicht auch Lösungen für Spezialfälle draus gebastelt.

Ich beschränke mich aber zunächst auf den schon angesprochenen Standardfall.
Man sitzt zuhause. Hat ein Router. Möglicherweise ein internes Netz und nur eine Netzwerkschnittstelle.

Definieren uns erstmal ein paar Variablen. Das macht dann auch Anpassungen leichter:
Zeilennummern

    1 NET_IF=eth0  # Netzwerkinterface  
    2              # (bei W-LAN meist wlan0 usw.)
    3 LO_IF=lo     # Loopback-Net-Device

Alle Regeln löschen:
iptables -F

Per default alle Pakete zurückweisen, wenn keine passende iptables-Regel gefunden. Denn lieber alles verbieten und dann nach und nach freigeben als umgekehrt. Wenn man so etwas vergisst, funktionieren bestimmte Dinge nicht. Anders herum hätte man im Vergessensfall ein Loch im Paketfilter.

Zeilennummern

    1 iptables -P INPUT   REJECT
    2 iptables -P FORWARD REJECT
    3 iptables -P OUTPUT  REJECT

Regeln für eingehende Pakete:
Zeilennummern

    1 # Paket aufs Loopback-Device erlauben
    2 iptables -A INPUT -i $LO_IF -j ACCEPT
    3 
    4 
    5 # bestehende Verbindungen erlauben
    6 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    7 
    8 # Beispielregel für den Zugriff auf einen eigenen Webserver:
    9 iptables -A INPUT -i $NET_IF -p tcp --dport 80 -j ACCEPT
   10 
   11 # Pakete von allen definierten Nameservern erlauben
   12 for ipadr in $(grep "nameserver" /etc/resolv.conf | awk {'print $2'}); do 
   13   iptables -A INPUT -p tcp -s $ipadr --sport domain ! --syn -j ACCEPT
   14   iptables -A INPUT -p udp -s $ipadr --sport domain -j ACCEPT
   15 done 
   16 
   17 # Alle anderen Pakete ignorieren
   18 iptables -A INPUT -j DROP

Regeln für ausgehende Pakete:
Zeilennummern

    1 # vom Loopback-Device alles erlauben
    2 iptables -A OUTPUT -o $LO_IF -j ACCEPT
    3 
    4 # Unser Webserver
    5 iptables -A OUTPUT -p tcp --sport   80 -j ACCEPT
    6 
    7 # Programme auf unseren PC dürfen zu 
    8 # (Internet)Webservern Verbindungen aufnehmen.
    9 iptables -A OUTPUT -p tcp --sport 1024: --dport  80 -j ACCEPT
   10 iptables -A OUTPUT -p tcp --sport 1024: --dport 443 -j ACCEPT # HTTPS
   11 
   12 # ...und zu Mailsservern (POP3 und SMTP)
   13 iptables -A OUTPUT -p tcp --sport 1024: --dport 110 -j ACCEPT  # POP3
   14 iptables -A OUTPUT -p tcp --sport 1024: --dport  25 -j ACCEPT  # SMTP
   15 
   16 
   17 # Den Rest ignorieren aber bei TCP machen wir ein Verbindungs-Reset
   18 # damit unser Programm nicht aufs Timeout warten muss
   19 iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
   20 iptables -A OUTPUT -j DROP

Soviel erstmal in Kürze für heute.

Gruß
MichaelK

Die Sicherheit von sicherheitskritischen Anwendungen wie Browser¹ lässt sich erhöhen, indem man diese unter einem eigenen Benutzer(account) laufen lässt.
Das schützt zwar nicht gegen Angriffe vermindert aber deren Auswirkungen, weil die übrigen Dateien die dem Account nicht gehören nicht im Zugriffsbereich liegen. Man schützt also auch seine eigenen Dokumente gegen Spionage.

Man kann sogar noch einen Schritt weiter gehen, indem man das Verzeichnis dieses Benutzeraccounts quasi als Read-Only realisiert. Dadurch kann sich auch im Homeordner dieses Nutzers nichts auf Dauer einnisten².

Wie man das Ganze nun praktisch umsetzt, will ich an dem folgenden Beispiel demonstrieren. Dabei wird ein Benutzer namens browser angelegt. Die zu verwendene Applikation ist hier der Firefox. Im Prinzip ist aber alles austauschbar.

Zunächst einmal legt man einen neuen User an. Dafür stehen ja diverse Tools zur Verfügung. Auf der Kommandozeile gibts dafür useradd oder das etwas konfortablere addduser. Optimalerweise hat der User auch seine eigene Gruppe der jeder Benutzer in einer Gruppe sein muss, aber bestehende Gruppen nicht verwendet werden sollten, da damit meist besondere zusätzliche Rechte einhergehen.
Bei adduser wird das je nach /etc/adduser.conf automatisch mit erledigt. Sollte das nicht der Fall sein, legt man zuerst die entsprechende Gruppe an mit groupadd.

Damit wir uns komfortabel mit diesem Benutzer anmelden können, kann man sudo dahernehmen. Für den Firefox bietet sich zum Beispiel folgender Eintrag in der Datei /etc/sudoers an:
myusername ALL = (browser) NOPASSWD: /usr/bin/firefox

Das NOPASSWD: verhindert die Abfrage des Passwortes für den Benutzer browser. Dadurch kann man ein beliebig Komplexes wählen, wenn man verhindern will, dass andere sich als browser anmelden ohne es sich merken und eintippen zu müssen.

Für die grafische Oberfläche bieten sich die Programme kdesudo bzw. gksudo an. Nimmt man das normale sudo-Kommando, darf der Subprozess in der Regel kein Fenster öffnen (eine Eigenschaft von X-Window aus Sicherheitsgründen).

kdesudo -u browser /usr/bin/firefox
Startet dann den Firefox als Benutzer browser.

Soweit so gut.
Als nächstes kommen wir zur Implementierung des Read-Only. Ein echtes Read-only (via Dateirechte) wird aber in der Regel nicht möglich sein, wenn Programme (wie unser Firefox) Schreibrechte benötigen. Das Problem kann man aber umgehen, indem man via unionfs bzw. aufs³ über das Homeverzeichnis des Benutzers browser ein anderes Verzeichnis legt. Da die Daten, die beim browsen so anfallen meist überschaubar sind, bietet sich hierfür eine RAM-Disk an⁴.

RAMDisk anlegen:
mount -t tmpfs none /pfad/zum/einhängepunkt

Auf den Details, wie man nun die RAM-Disk⁵ verwaltet usw. gehe ich an dieser Stelle nicht ein. Notfalls einfach fragen.

Für das mounten des Union-FS nehme ich fürs Beispiel aufs. Die Syntax für unionfs ist aber fast identisch. Die RAMDisk soll hierbei unter /mnt/ramdisk gemountet sein:
mount -t aufs -o dirs=/mnt/ramdisk/:/home/browser/=ro none /home/browser/

Ab da landen alle Schreibzugriffe auf /home/browser in der RAMDisk und sind spätestens nach dem Neustart des PCs verschwunden. Man kann natürlich auch die Dateien auf der RAMDisk manuell löschen indem man die entsprechenden Dateien entfernt, die dem User browser gehören.

Die ganzen Mount-Anweisungen lassen sich natürlich auch in die /etc/fstab eintragen:

tmpfs   /mnt/ramdisk   tmpfs   noatime,nodiratime    0       0
aufs    /home/browser/  aufs    dirs=/mnt/ramdisk/:/home/browser/=ro   0       0

Wenn man bestimmte Sachen mal durchschreiben möchte (für Konfigurationen etc.), muss man einfach nur das Union-Dateisystem derweil "unmounten".

Mit dieser Vorgehensweise lässt sich relativ einfach für Programme eine sandboxed-Umgebung schaffen und damit die Sicherheit zu erhöhen.

Das SELinux einfach waere, hab ich nicht geschrieben. oder?

Es gibt aber Distributionen, da laeuft SELinux per default. z.B. Fedora ( mehr unter http://fedoraproject.org/wiki/SELinux )