# touch /etc/before-update

# lvcreate -L 2G -s -n snap1 vg_fedora13/lv_root 

następnie wykonujemy ww. update, który dla uproszczenia zilustrowałem jako skasowanie pliku /etc/before-update ;)

# rm /etc/before-update

po restarcie systemu okazuje się, że musimy szybko cofnąc zmiany:

# lvconvert --merge vg_fedora13/snap1

Can't merge over open origin volume

Merging of snapshot snap1 will start next activation.

komunikat informuje, że operacji na podmontowanym systemie plików jest niemożliwia w związku z tym restartujemy system i sprawdzamy:

# ls /etc/before-update 

/etc/before-update 

operacja się udała mamy stan systemu sprzed zmian. Jednak kolejny snapshot kończy się komunikatem:

Snapshots of an origin that has a merging snapshot is not supported. 

wówczas wystarczy aktywować ponownie dany wolumen:

lvchange -ay vg_fedora13/lv_root 

Tym prostym sposobem otrzymujemy szybkie narzędzie do cofania zmian, należy jednak pamiętać o tym, że dla LVM wykonywanie snapshot’ów i ich utrzymywanie może odbijać się negatywnie na szybkości działania w przeciwieństwie do systemu ZFS i Btrfs opartych o rozwiązanie COW i pewnie ta idea przyświecała twórcom wspomianego narzędzia dla Fedory.

[1] http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Kontynuując serię wpisów o SELinux warto wspomnieć o prezentacji, która opisuje nowości w tym zakresie dla RHEL 6:

http://www.redhat.com/promo/summit/2010/presentations/summit/whats-next/thurs/dwalsh-2-gpa/GrandfathersSELinux.pdf

Kolejna prezentacja to podstawy  SELinux’a ujęte w ciekawej formie:

http://www.redhat.com/promo/summit/2010/presentations/summit/decoding-the-code/wed/tcameron-1020-selinux/SELinuxMereMortals.pdf

Na sam koniec porcja dla tych, którzy chcą przećwiczyć sobie obsługę SELinux’a:

http://www.redhat.com/promo/summit/2010/presentations/taste_of_training/Summit_2010_SELinux.pdf

Autorem ww. prezentacji jest Dan Walsh, jego adres bloga znajdziecie w boksie ,,Czytane”

Począwszy od Fedory 9 mamy do czynienia z pojęciem confined users, są to użytkownicy, którzy przypisani mają konkretne role, a one z kolei są ściśle kontrolowane przez SELinux. Wyróżniamy w systemie Fedora 13 następujących ..confined users”:

• guest_u
• xguest_u
• user_u
• staff_u
• sysadm_u
• git_shell_u

Użytkownik, który mam przypisaną rolę guest_r, może się zalogować do systemu, natomiast nie może wykonywać programów w swoim katalogu domowym, nie może wykonywać programów typu suid (nie przełączy się np. poprzez su), nie może nawiązywać połączeń sieciowych. Rozszerzeniem roli guest_r jest rola xguest_r, jak nie trudno zgadnąć może zalogować się do serwera X-ów oraz może łączyć się ze światem za pomocą tylko i wyłączenie przeglądarki firefox. Reszta ról omówiona jest pod adresem [1]. Zostaje tylko rola git_shell_u i ją też zapewne łatwo zaklasyfikować, jasności nabierze po wykonaniu polecenia:

sesearch --allow -s git_shell_t 

zaprezentuje ono wszystkie reguły allow dla danego typu.

Przypisanie konkretnej roli do istniejącego konta wykonać można następująco:

usermod -Z guest_u nazwa_uzytkownika

sprawdzenie czy przypisanie się powiodło:

semanage login -l

Rola guest_r jest dobrym punktem wyjścia do tworzenia nowych ról np. poprzez dodawania kolejnych uprawnień. Załóżmy, że nasz nieszczęśnik z rolą guest_r ma mieć możliwość nawiązywania połączeń na portach http (m.in. 80, 443).  Do tego celu podobnie jak w przykładzie aplikacji w poprzednim wpisie wykorzystamy tryb permissive oraz audit.log. Po próbie połączenie wygenerowany został wpis audytu na bazie którego stworzymy nowy moduł rozszerzający uprawnienia guest_r:

cat /var/log/audit/audit.log | audit2allow -m guestenh > guestenh.te

po skompilowaniu i dodaniu modułu, użytkownik z guest_r będzie mógł ustawiać połączenia do portów zdefiniowanych jako http_port_t. Należy pamiętać, że tym sposobem rozszerzyliśmy sobie niebezpiecznie std. rolę guest_r, korzystniej jest stworzyć nową rolę na bazie roli guest_r. Uczynić tą można najprościej graficzną nakładką na SELinux’a system-config-selinux.

Opisywana rola guest_u znacząco ogranicza poczynania nieuprawnionych użytkowników, można ją dowolnie rozbudowywać. Stanowi ona dobry punkt wyjściowy do stworzenia użytkownika typu kiosk ( patrz. komputery ogólnie dostępne dla wszystkich )  lub też służyć może do bezpiecznego surfowania po internecie (patrz. xguest_u) np. złośliwy kod pobrany z internetu nie będzie miał szansy się wykonać, podobnie jak kilka wydawać by się mogło std. poleceń:

[guest@fedora13 ~]$ id -Z

guest_u:guest_r:guest_t:s0

[guest@fedora13 ~]$ w

Segmentation fault (core dumped)

[guest@fedora13 ~]$ top

Segmentation fault (core dumped)

[guest@fedora13 ~]$ dmesg

klogctl: Permission denied

[guest@fedora13 ~]$ less /var/log/messages

/var/log/messages: Permission denied

[guest@fedora13 ~]$ su - 

Command not found.

 

[1]  http://fedoraproject.org/wiki/Test_Day:2009-10-20

SELinux najlepiej się ma w dystrybucjach ,,redhatopodobnych” Fedora, RedHat, CentOS. Na bazie tych dystrybucji i oferowanych przez nie narzędzi zbuduję politykę, która ograniczy ,,szkodliwe” działanie pewnego skryptu. Za nim jednak przejdę do tworzenia polityki opiszę krótki scenariusz jak może dość do nadużycia z owym tajemniczym skryptem w tle.

Załóżmy sytuację, w której nasz skrypt generuje poufny raport, który dostępny ma być tylko dla wybranych osób. Raport zapisywany jest tylko w wybranych katalogach domowych użytkowników. Co więcej autor skryptu poszedł po najmniejszej linii oporu określając root’a jako użytkownika z poziomu, którego można tylko uruchamiać skrypt. Załóżmy, że wychodzi nowa wersja skryptu do pobrania z internetu, w tej chwili do gry wchodzi napastnik, który kieruje administratora na spreparowaną stronę zawierającą dziurawą wersję skryptu. W efekcie napastnik, który jest autorem dziurawej wersji skryptu uzyskuje dostęp do poufnego raportu, który zapisuje się też w jego domowym katalogu oraz  zdobywa hasła np. z pliku /etc/shadow. W tradycyjnym podejściu bez uciekania się do SELinux’a taka sztuka się powiedzie, co jednak się stanie, gdy opiszemy działanie skryptu przy pomocy konkretnej polityki…

Przystępując do napisania polityki możemy skorzystać z narzędzia sepolgen:

# sepolgen -t 3 getresults

getresults to nazwa skryptu/programu.

Wynikiem polecenia sepolgen bedą cztery pliki, główny plik zawierający polityki i który to będziemy edytować to getresults.te.

Skrypt getresult będzie działał w domenie (typ) getresults_t a plik wykonywalny będzie oznaczony label’em getresults_exec_t:

type getresults_t;

type getresults_exec_t;

application_domain(getresults_t, getresults_exec_t);

 

standardowo użytkownik root jak i zresztą każdy inny użytkownik działa w domenie unconfined_t, zatem po uruchomieniu powinien taki proces powinien przejść do domeny skryptu getresults_t:

role unconfined_r types getresults_t;

type_transition unconfined_t getresults_exec_t:process getresults_t;

allow unconfined_t getresults_t:process transition;

 

skrypt getresults wyniki powinien zapisywać w katalogu ( i plikach) oznaczonych label’em getresults_t:

allow getresults_t getresults_t:file { write getattr open create };
allow getresults_t getresults_t:dir { write add_name };

 

użytkownik root niestety nie jest w stanie zmienić katalogu na nowy label getresults_t w tym celu należy:

allow getresults_t getresults_t:file { write getattr open create };
allow getresults_t getresults_t:dir { write add_name };
 

wspomniane w pliku inne domeny (np. unconfined_t) muszą być uwzględnione w:

require {
type unconfined_t;
type proc_t;
type user_devpts_t;
type fs_t;
}

tak przygotowane politykę możemy przekompilować i dodać do zestawu:

# make -f /usr/share/selinux/devel/Makefile && semodule -i getresults.pp

 

następnie przełączamy SELinux’a w tryb Permissive (tj. raportuje i nie blokuje):

# setenforce 0

 

analizujemy plik audytu /var/log/audit/audit.log po uruchomieniu skryptu getresults, jeżeli zauważymy jakieś informacje o blokadach wówczas:

# audit2allow -i /var/log/audit/audit.log
  

wygeneruje nam potrzebne wpisy do poprawnego zadziałania, dopisujemy je do pliku getresults.te oraz podnosimy wersję:

policy_module(getresults,1.0.1)

oraz przekompilowujemy i upgrade’ujemy politykę:

# make -f /usr/share/selinux/devel/Makefile && semodule -u getresults.pp

 

ponownie uruchamiamy skrypt i analizujemy audit.log. Jeżeli nie ma już żadnych zastrzeżeń przełączamy się na tryb Enforcing:

# setenforce 1
 
 

Zobaczymy czy teraz skrypt getresults zapisze nam zawartość raportu i pliku shadow do nowej nieoznaczonej lokalizacji:

# ./getresults
./getresults: line 4: /tmp/results: Permission denied

./getresults: line 5: /tmp/results: Permission denied

okazuje się, że sztuka ta nawet z poziomu konta root’a się nie udaje. Skrypt zapisuje tylko dane do katalogu oznaczonego label’em getresults_t:

ls -lZR
.:
drwxr-xr-x. root root unconfined_u:object_r:getresults_t:s0 results
./results:
-rw-r–r–. root root unconfined_u:object_r:getresults_t:s0 results
 

Tym sposobem możemy się ustrzec przed błędami w programach, koszt jaki musimy ponieść to z pewnością czas na dostosowanie polityki do potrzeb konkretnej aplikacji. Na całe szczęście najpopularniejsze usługi dostępne w systemie Linux w szczególności w dystrybucjach redhatopodobnych mają już gotowy zestaw polityk. Nie mniej jednak zachęcam do zapoznania się z nimi tak, gdyż mogą nam posłużyć jako wzorce do napisania własnych polityk, które uchwycić mogą nietypowe programy w bezpiecznych domenach bez uciekania się do wyłączanie SELinux’ach lub przełączania go w tryb Permissive.

Zbiór informacji o SELinux:  http://selinuxproject.org/

Plik: getresults.te

Skrypt: getresults

- pierwszy problem to jak przy pomocy ,,jednolinijkowca” a w zasadzie jednego polecenia porównać dwa katalogi:

diff -q -r /dir1 /dir2

owszem to samo zadanie można wykonać przy pomocy chociażby rsync’a lub skorzystać z systemów IDS chociażby tripwire,samhain.

- drugi problem to jak przysłać np. plik z hostA do hostB nie wysycając całego dostępnego pasma oraz nie zużywając dużej ilości zasobów:

hostA# gzip -c file.1 | pv -L <limit_bajt/s> > /dev/tcp/<hostb_ip>/<hostb_port>

hostB# nc -l <hostb_port | gunzip > file.1

- trzeci problem jak w bash’u napisać skrypt, do którego argumenty podajemy w następujący sposób: <nazwa_skryptu> -a -b <parm1>:

#!/bin/bash

args=`getopt ab: $*`

set -- $args

for i do

 case "$i" in

 -a) PARM1=1; shift ;;

 -b) PARM2=$2; shift; shift ;;

 --) shift; break ;;

 esac

done

echo "-a $PARM1"

echo "-b $PARM2"

Chroot’owanie popularnych usług nie jest zadaniem łatwym, wymagane jest poznanie specyfiki działania konkretnego daemon’a, aby dostarczyć minimalne warunki do jego pracy. Czynności sprowadzają się do utworzenia nadrzędnego katalogu, który stanowić będzie przestrzeń root dla wybranej usługi, przegranie do utworzonego drzewa katalogów potrzebnych plików binarnych, wybranych bibliotek oraz podstawowych plików systemowych. Zrealizowanie takiej instalacji nastręcza często wielu kłopotów. Z pomocą przychodzi moduł mod_security, którego mało kto podejrzewa, że umożliwia on zrealizowanie szybkiego i łatwego chroot’a, do podstawowej instalacji wystarcza wpis:

SecChrootDir /chroot

Minimalna konfiguracja mod_security jest możliwa dzięki odpowiedniemu podejściu, otóż  tuż po załadowaniu wszystkich wymaganych bibliotek i otwarciu deskryptorów plików m.in. log’u  dopiero wtedy apache przełącza się na zdefiniowane środowisko chroot. Oczywiście wymagane jest dodatkowo stworzenie lokacji m.in. dla pliku z numerem pid w gałęzi /chroot, takiej jak podana jest w pliku konfiguracyjnym i ew. wykonanie symlinka do lokalizacji pierwotnej, tj. do tej zawartej w pliku uruchomieniowym (np. /etc/initd./httpd) do poprawnego zastopowania usługi.

Tak zdefiniowana konfiguracja pozwalana na dostarczenia treści statycznej w przypadku zastosowania PHP w najpopularniejszym wydaniu dla Apache czyli mod_php, możemy natknąć się na kilka problemów:

- problem z resolve’owaniem nazw DNS’owych

problem ten da się łatwo okiełznać wystarczy dograć odpowiednie dynamiczne biblioteki, jakie biblioteki ? to łatwo dojedziemy korzystając z poleceń ldd lub/i strace. Dodatkowo do etc w /chroot dograć należy pliki hosts oraz resolv.conf  [1]

- problem z wysyłką mail’i

wystarczy skorzystać z mini-sendmail’a [2] specjalnie dostosowanego do środowiska chroot, umieścić go std. w lokalizacji /chroot/usr/sbin/sendmail. Sam  mini-sendmail nie wystarczy należy dograć do etc w /chroot pliki passwd (wystarczy wpis dot. samego apache’a), dodatkowo należy do bin  w /chroot dograć domyślną powłokę sh wraz z wymaganymi bibliotekami [1]

- problem z restartem apache’a w szczególności opcji graceful

niestety tego problemu nie udało mi się rozwiązać, może ktoś chętny podzieli się rozwiązaniem ? ;)

Informacje o występujących problemach standardowo znajdziemy w pliku error_log apache’a.

Tym prostym sposobem możemy w znaczący podnieść poziom bezpieczeństwa naszego systemu, oczywiście zachęcam dodatkowo do skorzystania z szeregu opcji filtrowania ruchu HTTP, do tego do czego mod_security przede wszystkim został stworzony.

[1] lista wymaganych bibliotek dla systemu CentOS 5.x i386, nie jest to z pewnościa minimalna wersja

ld-2.5.so

ld-linux.so.2->ld-2.5.so

libacl.so.1->libacl.so.1.1.0

libacl.so.1.1.0

libattr.so.1->libattr.so.1.1.0

libattr.so.1.1.0

libc-2.5.so

libc.so.6->libc-2.5.so

libdl-2.5.so

libdl.so.2->libdl-2.5.so

libnss_dns-2.5.so

libnss_dns.so.2->libnss_dns-2.5.so

libnss_files-2.5.so

libnss_files.so.2->libnss_files-2.5.so

libpthread-2.5.so

libpthread.so.0->libpthread-2.5.so

libresolv-2.5.so

libresolv.so.2->libresolv-2.5.so

librt-2.5.so

librt.so.1->librt-2.5.so

libselinux.so.1

libsepol.so.1

libtermcap.so.2->libtermcap.so.2.0.8

libtermcap.so.2.0.8

[2] http://www.acme.com/software/mini_sendmail/

Mowa będzie o rozwiązaniu fwknop [1], które stanowi rozwinięcie metody port-knocking. W stosunku do standardowego rozwiązania ,,odpukiwania” określonych zamkniętych portów, fwknop wysła tylko jeden zaszyfrowany niepowtarzalny pakiet SPA. W celu wygenerowania ,,otwierającego” pakietu SPA, musimy dodatkowo znać tajne hasło bądź posłużyć się kluczem GPG, w standardowej metodzie port-knocking wystarczyło tylko znać kombinację portów, tak samo jak wystarczyło prostym snifferem podsłuchać taką kombinację. Po pomyślnej akceptacji pakietu SPA wyłuskiwany jest adres IP nadawcy i modyfikowany jest na określony czas zestaw reguł netfilter/ipfw umożliwiając połączenie z wybraną usługą. Najczęściej stosowany jest scenariusz z ukryciem dostępu SSH, ja postaram się omówić metodę uzyskania dostępu do usługi działającej w chronionej sieci (tej samej, w której działa fwknopd).

Konfiguracja fwknopd sprowadza się do edycji dwóch plików: access.conf i fwknopd.conf.

W pierwszym pliku access.conf definiujemy dane potrzebne do uzyskania dostępu:

# dopuszczalne adresy źródłowe
SOURCE: ANY;
# otwarte porty
OPEN_PORTS: tcp/3389;
# tajne hasło
KEY: tajnehaslo;
# czas otwarcia portu
FW_ACCESS_TIMEOUT: 45;
# czy połączenie ma być forwardowane do innej maszyny
ENABLE_FORWARD_ACCESS: Y;

W drugim pliku fwknop.conf definujemy konfiguracje samego fwknopd.conf

# adres na jaki będą wysyłane powiadomienia o uzyskanym dostępie

EMAIL_ADDRESSES             root@localhost;

# adres hostanme

HOSTANAME    hostame;

# linux netfilter

FIREWALL_TYPE               iptables;

# interfejs, na którym fwknop będzie nasłuchiwał pakiety SPA

PCAP_INTF                   eth0;

# translacja adresów oraz adres IP fwknopd w chronionej sieci 

ENABLE_IPT_SNAT             Y;

SNAT_TRANSLATE_IP           _CHANGEME_;

# włączenie trybu forward

ENABLE_IPT_FORWARDING       Y;

# forwarding w linuxie 

ENABLE_PROC_IP_FORWARD      Y;

Po stronie firewall’a chroniącego dostęp prócz otwarcia i przekierowania chronionego portu, musimy przekierować std. port udp/62201 do hosta z fwknopd.
W celu uzyskania dostępu do zdalnego pulpitu maszyny 10.0.0.3 (chroniona sieć) z poziomu klienta wydajemy polecenie:

fwknop -A tcp/3389 -F 10.0.0.3:3389 --Resolve-external-IP -D <adres_fwknopd>

nasz zew. adres IP zostanie automatycznie uzyskany bądź  możemy go zdefiniowaniu po podaniu argumentu -a
Warto w przypadku netfilter’a dodać po stronie fwknopd regułkę, do łańcucha FORWARD i INPUT przepuszczającą połączenia już istniejące (ESTABLISHED,RELATED).
Gdyż przy braku tej regułki po zdefiniowanym timeout’cie w access.conf zostaniemy rozłączeni.

Tym prostym sposobem uzyskaliśmy łatwy i w miarę bezpieczny dostęp do konkretnych zasobów chronionych w naszej sieci, bez uciekania się do dostępu VPN. Zaś użycie klucza GPG ułatwi nam definiowanie dostępu w przypadku wielu użytkowników, gdyż nie musimy się martwić zmianą hasła w przypadku wykluczenia jednego z użytkowników.

[1] http://cipherdyne.org/fwknop/

Czasem potrzebujemy szybko dowiedzieć się o uprawnieniach plików zawartych w danej lokalizacji. W pierwszej kolejności zapewne będziemy się posiłkować za zakładką Security ona jednak przy dużej liczbie obiektów wydaje się być mało efektywna. Następny krok to zapewne narzędzie konsolowe icacls szczególnie z przełącznikiem /T daje nam pełen obraz sytuacji, jednak ten obraz ACL’i nie całkiem bywa czytelny . Ostatni krok to wspomniany AccessEnum[1]:

prosto i przejrzyście nieprawdaż ? ;)

Odpowiednik AccessEnum’a dla zasobów współdzielonych to ShareEnum[2], prezentuje się bardzo podobnie.

[1]  http://technet.microsoft.com/en-us/sysinternals/bb897332.aspx

[2] http://technet.microsoft.com/en-us/sysinternals/bb897442.aspx

Po włączeniu funkcji Access-Based Enumeration użytkownik, który eksploruje udostępniony zasób sieciowy, zobaczy jedynie te foldery i pliki, do których ma dostęp. Widoczność plików i folderów uzależniona jest od tego czy dany użytkownik ma do nich prawo odczytu lub prawo zapisu. W przypadku Samby wystarczy globalnie lub w kontekście definicji pojedynczego zasobu ustawić parametry:

hide unreadable

hide unwritable

Samba w wersji przynajmniej 3.4 oferuje dodatkowo parametr:

access based share enum

która uzależnia dostęp do konkretnego zasobu sieciowego (nie pliku, folderu) w zależności od praw odczytu lub zapisu.

Zaprezentowany sposób podejścia do udostępniana danych podnosi poziom zabezpieczeń, eliminując z pola widzenia niepowołanych osób istnieje wybranych obiektów. Dodatkowo zmniejsza się liczba komunikatów o błędach związanych z brakiem dostępu.

Przedstawiona funkcja Access-Based Enumeration znalazła się również w najnowszym systemie MS Windows Server 2008.

access based share enum