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: <[EMAIL PROTECTED]> oraz <[EMAIL PROTECTED]>, ż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 <[EMAIL PROTECTED]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
