firewall-init

[Andrzej Krzysztofowicz]

Marek Guevara Braun wrote:
> Andrzej Krzysztofowicz wrote:
> >
> > Jak bardzo bedzie ograniczalo funkcjonalnosc uzycie jako skladni pliku
> > konfiguracyjnego - skladni linii polecen dla iptables.
> 
> Podstawowe pytanie - jaki jest cel tego pliku konfiguracyjnego?

separacja uprawnien. wieksze bezpieczenstwo.

> > Taka propozycja padla, nikt sie do niej nie ustosunkowal.
> > Cos sie przy niej traci? Co konkretnie - przyklady.
> 
> Jak na teraz (dla firewall-init z Ra) - definiowanie własnych chainów.
> Nie wiem jak jest z accountingiem - można?

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)

> Dla iptables można pomyśleć o tych co korzystają/będą chcieli korzystać 
> z własnych łańcuchów (w firewall-init 2.99 to jest), dodatkowych
> ficzerów, takich jak ebtables ...
> 
> Złożoność enginu przetwarzającego plik konfiguracyjny o *pełnej*
> funkcjonalności polecenia ${iptables} będzie taka sama jak

dla
iptables $LINE
?

Rzeczywiscie zlozony parser bedzie potrzebny ;)

> enginu przetwarzającego wszelkie wariacje skryptu shellowego
> z wywołaniami iptables - trzeba wszystko uwzględnić.

Patrz wyzej. Nigdzie nie twierdze, ze chce sie wzorowac w skladni pliku
konfiguracyjnego na RA.
 
> >>rozwiązanie z firewall-init z Ra i dodać tylko weryfikację wszystkich
> >>przekazywanych z konfiga wartości, coby nikt ';rm -rf /' jako parametr
> >>firewalla nie podał ;-)
> > 
> > Tego akurat mozna latwo uniknac.
> 
> s/można/trzeba/ :-) i nie do końca łatwo - zarówno dla podejścia "plik
> konfiguracyjny modyfikowany przez usera" jak i "sudo na iptables",
> pozostaje otwarta kwestia bezpieczeństwa samego polecenia iptables -
> jego odporność na ciągi formatujące, przepełnienie bufora itp.

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

Nawet do RA to jak widze warto dodac.

> Do tej pory zakładaliśmy że iptables może wywołać root i to root
> odpowiedzialny jest za wszystkie parametry przekazywane do tego
> polecenia gdy jest ono wywoływane na prawach roota.
> 
> Jeśli w poleceniu jest dziura, ale by z niej skorzystać trzeba mieć
> roota, to jej istnienie jest mało istotne. Gdy nie będąc
> rootem mamy wpływ na to co jest wywoływane z prawem roota
> i w poleceniu jest eksplojtowalna luka to .. mamy roota
> - nie jestem pewien czy /usr/sbin/iptables jest poleceniem
> bezpiecznym :-(.
> 
> >>Co do psucia przez userów poza firewallem, to przy dawaniu userom prawa
> >>do wywoływania skryptów z 'sudo ${iptables} ..' trzeba pamiętać by
> >>skrypty te nigdy nie były wykonywane przez root-a, a tylko przez tego
> >>usera.
> > 
> > Jak proponujesz to zagwarantowac?
> 
> Po prostu - userzy nie mają prawa do zapisu swoich poleceń do skryptów
> wywoływanych przez init-skrypty firewalla z prawem roota.

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

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

> > 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.

> 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.

> > Wlasnie do unikniecia tego daze: do _separacji_ skryptow i konfiguracji.
> 
> Taka separacja nie daje do końca pewności że "jest bezpiecznie"

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

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.

> > Jak ktos chce uzywac wlasnych skryptow, to mu niepotrzebne init.d/firewall*
> > - moze uzywac wlasnego. Mozemy nawet takie rozwiazanie wspierac, ale IMVHO,
> > nie jako podstawowe.
> 
> IMO dawanie userom prawa do modyfikacji firewalla nie powinno być
> dostarczane jako rozwiązanie standardowe.

Zdecydowanie.

> Pozdrawiam,
> Marek
> 
> PS. Zawsze ${iptables} może być równe '/usr/bin/sudo /usr/sbin/iptables'

To jest jakis pomysl.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology