firewall-init

[Marek Guevara Braun]

Andrzej Krzysztofowicz wrote:
> Marek Guevara Braun wrote:

>>Podstawowe pytanie - jaki jest cel tego pliku konfiguracyjnego?
> 
> separacja uprawnien. wieksze bezpieczenstwo.

OK

> ZTCW wsparcie dla wlasnych lancuchow w RA jest. Nie sprawdzalem jak dziala
> (potencjalnie widze problem z kolejnoscia ich aktywacji - ale to mozna
> rozwiazac poprzez odpowiednie nazwy)

No nie wiem. Wydawało mi się ze tylko input, output i forward.
Może źle przeczytałem.

>>Złożoność enginu przetwarzającego plik konfiguracyjny o *pełnej*
>>funkcjonalności polecenia ${iptables} będzie taka sama jak
> 
> 
> dla
> iptables $LINE

OK. To jest proste, ale jeśli user ma wpływ na $LINE to potencjalnie 
może wrzucić tam coś nieporządanego, co bez analizy składniowej 
parametrów (złożone i pracochłonne) może nie zostać odfiltrowane.

Oczywiście można założyć że niezaufany user nie ma dostępu do
tego pliku.

> Rzeczywiscie zlozony parser bedzie potrzebny ;)

Odrzucanie podejrzanych znaków - nie wiem jak z escapeowaniem unikodu
ale to może być problem w najbliższym czasie, jeśli shelle zaczną
interpretować eskejpowany unikod (już rozpoznają ??), dla niektórych
modułów iptables ich parametry mogą pokrywać się z "zastrzerzonymi"
znakami.

> Patrz wyzej. Nigdzie nie twierdze, ze chce sie wzorowac w skladni pliku
> konfiguracyjnego na RA.

Chyba byłoby to trudne/mało elastyczne. Z drugiej strony to co daje
firewall-init dla Ra wystarcza w wielu zastosowaniach.

> Mozna ograniczyc zakres dozwolonych znakow w pliku konfiguracyjnym.
> Np. bez ; ` ( ) { } itp. Nie ograniczy to raczej funkcjotalnosci.

Jeszcze
&  -- iptables .... && chmod 777 /etc/passwd
 >  -- iptables .... && echo "blabla" > /etc/passwd
|  -- iptables .... | moj_program
interpretowane przez shell sekwencje escapowe  -- nie mam pomysłu ;)
/ - nie za bardzo można bo /24
....

Tego może być dużo :-(

> Nawet do RA to jak widze warto dodac.

Tam przynajmiej jest tak, że tylko root pisze do konfiguracji.

> Tak, ale w jaki sposob user X moze zmienic zachowanie firewalla przy starcie
> systemu ?
> Do tego daze.

Jeśli user dodaje jakieś wpisy to firewall-init może robić
iptables-save iptables-restore z uwzględnieniem tej konfiguracji
(nie jest to idealne rozwiązanie bo w trakcie działania firewalla
reguły mogą być modyfikowane, a przy starcie możemy chcieć mieć tylko
konfigurację bazową bez tego co zmienił np. snort, ale już z wpisami
naszego usera).

Oczywiście danie userowi prawa do wpisu do pliku konfiguracyjnego
jest łatwiejsze.

> Przeciez usetrzy nie beda sobie tworzyc wlasnych firewalli, to jest funkcja
> ogolnosystemowa, nie per user.

Tak.

>>>konfiguracja firewalla zalezna nie od systemu, ale od usera, ktory wola
>>>skrypty startowe? Paranoja.
>>
>>Chcesz dać userom prawo do modyfikacji firewalla. To nie powinno być
>>czymś standardowym, by każdy user mógł modyfikować reguły firewalla.
> 
> 
> Nie chce tego nikomu dawac domyslnie. Chce miec *mozliwosc* zrobienia tego,
> jesli zechce.
> Obecne firewall-init nie daje takiej mozliwosci.

Można to dodać bardzo tanim kosztem (zaraz opiszę).

>>Jeśli chcesz by konfiguracja wprowadzona przez usera była wywoływana
>>automatycznie przez init-skrypty to zawsze można umieścić
>>w strukturze /etc/sysconfig/firewall-users/{benio,jasio,grzes}
>>a skrypt firewall przed wykonaniem poleceń z odpowiednich
>>skryptów przyjmowałby euid/egid danego usera - wtedy sudo na iptables
>>musiało by być bezhasłowe.
> 
> Zmiana konfiguracji - to rowniez usuniecie istniejacej reguly.
> I to niekoniecznie wprowadzonej przez danego usera.

Racja - dla wielu plików zarządzanych niezależnie mogą być
problemy związane z kolejnością i ogólnym rozbiciem na wiele plików.
To nie był najlepszy pomysł.

> Ale zgodzisz sie, ze jest wowczas bezpieczniej, niz gdy pozwala sie im
> edytowac skrypty odpalane przez root-a ?

Z drugiej strony root nie musi wcale odpalać skryptów firewalla - można 
utworzyć nowego usera (rolę w systemie) aka firewall-admin, który by
miał tylko sudo do odpowiednich binarek iptables - skrypty używać mogą
ospowiednio przypisanego ${iptables}

Można mieć 2 tryby pracy:

* normalny gdzie tylko root grzebie w konfigach i to on odpala firewall
   (tak jak teraz)
* user-enabled, gdzie grzebać w konfigu może ten pół root, ale by nie
   nabroił skrypty odpala się z euid/egid firewall-admina, do
   zmiennych ${iptables} ${iptables6} przypisuje się 'sudo iptables/6'
   i pomimo wprowadzenia "niezaufanych" poleceń shellowych w skryptach
   nie mają one dużego wpływu (bo odpala je nie root)

> Jezeli ktos ma dostac uprawnienia do modyfikacji firewalla, to musi to byc
> odpowiedzialna osoba. Taki pol-root. Co nie oznacza, ze nalezy mu od razu
> pozwolic na wszystko.

Tak.

Pozdrawiam,
Marek