Uprawnienia na /srv

[Tomasz Pala]

On Thu, Nov 13, 2008 at 21:31:46 +0100, Andrzej Krzysztofowicz wrote:

> Dlaczego uwazasz, ze twoja polityka informacyjna/informacja handlowa to
> bezpieczenstwo?

A o ochronie danych słyszałeś? Jeśli nazwa konta jednoznacznie
identyfikuje osobę, stanowi daną osobową i podlega ochronie ustawowej.
Stąd powinienem chronić nawet /etc/passwd (wspomnianymi wcześniej
metodami).

> Informacje, ze to hostujesz ktos(TM) moze uzyskac np. z pozasystemowego
> zrodla.

A to już nie mnie będzie skarżył :) Mnie interesuje, aby informacje nie
wyciekły ode mnie, tylko tyle.

> I tu uwazam, ze tego pojecia naduzywasz.
> Jest to ochrona tajemnicy handlowej/siakiej innej, a nie bezpieczenstwo
> systemu.

Już 2 dni temu pisałem w Message-ID:
<20081112171925.GA17164 w pepin.polanet.pl> oraz
<20081112171925.GA17164 w pepin.polanet.pl>, że to bezpieczeństwo
pozasystemowe.

Pojęcie SbO stosuje się w odniesieniu tylko i wyłącznie do systemu
informatycznego, nie uwzględnia natomiast relacji nietechnicznych.

> I w tej sytuacji cie zapytam: dlaczego musi to byc robione na
> poziomie /srv, a nie np. pietro wyzej?

Zasady budowania polityki bezpieczeństwa nakazują stosowanie wszelkich
możliwych metod na każdym poziomie - w szczególności systemy z dostępem
do sieci publicznej muszą posiadać wysoki poziom zabezpieczeń (dokładnie
czym się różni od podwyższonego i podstawowego można wyczytać w
rozporządzeniu ministra SWiA); ale wracając do tematu, to dowolne
zabezpieczenie może zostać w określonych warunkach przełamane, stąd nie
należy polegać tylko na 1 elemencie.

Jeśli SbO jest takie złe, to po co w ogóle w grsec takie rzeczy jak
filtrowanie zawartości /proc? Przecież z PID-a procesu się nic nie
wyczyta, a można je bardzo łatwo znaleźć (zaledwie 65k prób).

> Tam kazdy moze sobie ustawic
> uprawnienia jakie chce. /srv powinno miec takie, zeby wszystkim pasowalo.

Wszystkim nigdy nie będzie pasowało - pytanie kluczowe brzmi: czy
domyślnie ma być restrykcyjne czy luźne? Wg mnie lepiej pozostawić coś
do odblokowania, niż lukę którą można pominąć.

> A ja akurat jestem z innej branzy i moja rola to udostepnienie userom
> maksimum informacji o systemie. Byle bezpiecznie.

Jeśli więc nie będzie gdzieś dostępu, to ktoś zgłosi i zrobisz dostęp.
Dużo lepsza metoda niż: ktoś uzyskał dostęp, a nie wiesz o tym przez rok.

A żeby pokazać pewną analogię:

http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/apache-common.conf?rev=1.9

# First, we configure the "default" to be a very restrictive set of
# features.
[...]
		Deny from all

czemu to służy jak nie SbO właśnie? Dobrze zabezpieczone pliki nie
wyjdą, bo apache ich nie przeczyta nawet.

Kolejny przykład:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/proftpd.conf?rev=1.17
DefaultRoot         ~

a niby czemu user miałby sobie nie hasać tam, gdzie mu pozwoli system
plików?

A zawartość passwd to już klasyka - pokaż mi listę kont, sprzedam ją
spamerom. Nie stracisz nic a nic z bezpieczeństwa systemu, ale ludzie
zadowoleni raczej nie będą.

> PS. Nie mialbym nic przeciwko zmianie uprawnien /srv, gdyby bylo w PLD
>     narzedzie pilnujace takich roznic w stosunku do bazy rpm-a. Ale x lat
>     temu propozycja stworzenia czegos takiego spotkala sie z dosc powszechna
>     krytyka. Bedzie deja vu?

Nie pamiętam takiej dyskusji, ale jestem za - obecnie sam pilnuję kilku
miejsc, a nigdy nie wiadomo, kiedy zapomnę i zostanie mi dziura.

-- 
Tomasz Pala <gotar w pld-linux.org>