14:10
7/3/2011

Miło jest nam poinformować, że Niebezpiecznik objął patronat nad konferencją Open Source Day 2011, która odbędzie się 22 marca w Warszawie. Z tej okazji wspólnie z organizatorami konferencji przygotowaliśmy dla Was konkurs z atrakcyjnymi nagrodami.

O konferencji Open Source Day 2011

Open Source Day to największe w Polsce wydarzenie poświęcone wolnemu oprogramowaniu. W tym roku odbędzie się ono 22 marca w Wraszawie, w Pałacu Kultury i Nauki. W agendzie konferencji znajdziecie również tematy związane z bezpieczeństwem, m.in.

  • Przegląd nowych mechanizmów bezpieczeństwa w RHEL6
    — Leszek Miś – Linux Polska
  • Endian Firewall – platforma kompleksowego bezpieczeństwa sieci
    — Patryk Malina – B2B

Wstęp na konferencję jest bezpłatny — zapraszamy do rejestracji.

Konkurs

Organizatorzy Open Source Day zachęcają czytelników Niebezpiecznika do odpowiedzi na poniższe konkursowe pytanie. Każdy kto na nie odpowie, będzie miał szansę na zdobycie jednej z nagród ufundowanych przez organizatorów Open Source Day. Nagrodą główną jest urządzenie wielofunkcyjne HP DeskJet 2050, a nagrody pocieszenia to 3 koszulki.

Biorąc pod uwagę fakt, że potencjalnie każdy rodzaj oprogramowania może posiadać błędy, wyraź swoją opinię na temat bezpieczeństwa rozwiązań Open Source. Czy uważasz, że jest ono mniej czy bardziej bezpieczne niż oprogramowanie o zamkniętym kodzie źródłowym?

Odpowiedzi prosimy zamieszczać w komentarzach pod tym postem. Konkurs kończy się w piątek 11-tego marca 2011 roku o godzinie 23:59. Przez weekend odpowiedzi zostaną ocenione przez organizatorów, a nazwisko zwycięzców podamy w poniedziałek 14-tego marca 2011.

Aktualizacja 14 marca 2011
Jak pisze jedna z organizatorek Open Source Day, Kamila Szenejko: “ponieważ dyskusja była zagorzała i byliśmy pod wrażeniem aktywności na forum postanowiliśmy przyznać więcej nagród niż początkowo przewidywaliśmy” — dlatego dodatkowymi nagrodami, oprócz drukarki i koszulek będą 50% kupony zniżkowe na egzamin RHCSA. Poniżej lista zwycięzców:

1. Agresor
2. Dave
3. Jurgi
4. Paweł Goleń
5. Dreadlish
6. mac
7. Morfik

Organizatorzy Open Source Day skontaktują się z Wami w sprawie wysyłki nagród.

Przeczytaj także:

65 komentarzy

Dodaj komentarz
  1. Uważam, że oprogramowanie Open Source jest bardziej bezpieczne. Oczywiście wszystko zależy nad tym jaki zespół ludzi nad nim czuwa. Każdy z użytkowników może być potencjalnym włamywaczem czy niegodziwym osobnikiem, ale może też być testerem i zgłaszać błędy. Im więcej osób ma dostęp do kodu tym więcej osób może poprawić ten kod, lub wyrazić swoje wątpliwości na temat konkretnego fragmentu. No i nie zapominajmy o tym, że wiele osób stawia sobie za punkt honoru znalezienie dziury i zgnębienie użytkowników oprogramowania o zamkniętym kodzie. Dziękuję :)

    • w opensource jest gorzej, nie tylko każdy użytkownik może być włamywaczem ale developer kodu opensource też. powiem więcej: jeżeli masz determinacje i warunki i TYmożesz zostać współtwórcą np. jądra linuksa i dodać tam własny fragment kodu. absolutely no warranty yoyo -> niech to będzie twoją dewizą. co, że możesz przejrzeć cały kod kiedy tego nie robisz (przejrzeć a znaleźć błąd…), a każdy developer-wolontariusz może dodać coś nowego od siebie. dodajmy do tego, że użytkowników jest mniej, więc pisze się mniej złośliwego kodu, który jest efektem najczęściej zamierzonego wykrywania błędów.

      bezpieczeństwo opensource jest jak cholera trudne do określenia i rodzi mase wątpliwości w atmosferze braku jakiejkolwiek gwarancji.

      co nie zmienia faktu, że używam linuksa i bardziej mu ufam niż windowsowi

    • @Marcin: To deweloperzy “zamknięcioźródłowi” nie mają dostępu do źródeł? W kodzie maszynowym piszą, nie rozumiejąc tego co tworzą, żeby czasem nie mogli backdoora dodać?

      To by wyjaśniało stabilność wielu projektów ;D

    • gwyd:
      szukasz problemu tam gdzie go nie ma. do stworzenia backdora i dodania do zainstalowanego windowsa czy do jego instalki to nie problem bez znania kodu. problemem jest dystrybucja takiego oprogramowania i uniknięcie konsekwencji – chodzi o “źłych ludzi” i moje teorie spiskowe. pomijając instalki win z tpb(tam właśnie można nabyć windowsa z backdorem), produktów komercyjnych nie rozprowadza nikt anonimowy. nie wiem czy projekty opensource wymagają od członków podawania personaliów i czy jest to jakoś weryfikowane. jestem pewny, że łatwiej podszyć się pod autora przypadkowego projektu opensource(np zdobywając hasło do cvs’a), niż pod pracownika korporacji. łatwiej też zostać np developerem jakiejś dystrybucji linuksa i nagmerać coś w skryptach, których nikt nie ma ochoty naprawiać, a co dopiero sprawdzać, albo zacząć pomagać przy pisaniu jakiegoś narzędzia, które ma tylko jednego nierozgarniętego autora. wiele projektów cierpi na brak rąk do pracy, a “błąd” może być subtelny. kto go poszuka, kto go znajdzie, kiedy nie ma kto go nawet napisac? przy niszowych projektach niestety dystrybucja jest ograniczona przez małą ilości fanów.

      autorzy kodu z zamkniętymi źródłami są podpisani pod swoim kodem wydaje mi się bardziej wiarygodnie, kiedy taki sam podpis musi być na liście płac przedsiębiorstwa którego prawnie chronioną tajemnicą są te źródła. to wprowadza wiele zależności. ile osób zna kod windowsa? też nie wiem. ale myśle, że nie wszyscy którzy nad nim pracowali, byli na tyle zaufani żeby poznać całość. a za część którą pisali są prawdopodobnie odpowiedzialni w przypadku wycieku tych informacji.

      ale to takie urojone z pomocą mojej manii prześladowcząej zagrożenia terrorystyczne i teorie spiskowe, które bez ludzi o złych intencjach nigdy się nie zdarzą, bo z czego okrdać ludzi, którym żal na system operacyjny. to podobno skuteczne i pożyteczne, jak się ma paranoje w temacie bezpieczeństwa czegokolwiek.
      ale
      potencjalnie każdy rodzaj oprogramowania może posiadać błędy wynikające z przypadku..

  2. Rozwiązania Open Source są bardziej bezpieczne niż zamkniete oprogramowanie z prostego powodu- społeczności. Ona odgrywa największą rolą. Gdy mamy do czynienia z otwartym kodem, każdy może go przejrzeć pod kątem bezpieczeństwa, poinformować o błędzie itp.
    Owszem, każdy również może dodać coś od siebie, co nie jest mile widziane, ale w mgnieniu oka społeczność znajduje lukę i to naprawia.

  3. HP?… ostatnio kupiłem sobie brothera więc się nie skuszę ;) Pytanie z serii oczywista oczywistość i nagrody takie sobie, więc podam tylko przykładowego linka ;P
    http://www.egospodarka.pl/14264,Open-source-i-bezpieczenstwo,1,20,2.html

  4. Bezpieczeństwo oprogramowania open-source generalnie zależy od jego popularności: im więcej ma użytkowników, tym więcej ma potencjalnych testerów i osób zainteresowanych rozwojem nie tylko funkcjonalności oprogramowania, jak również jego zabezpieczeń. Ważny jest również fakt, że open-source jest często używany przez osoby z branży IT, które nie tylko zgłoszą błąd, lecz także zaangażują się w jego naprawienie. Takie osoby mają też podejście znacznie bardziej osobiste do używanego oprogramowania (nie traktują go wyłącznie jak “narzędzie”), co także wpływa pozytywnie na bezpieczeństwo. :)

  5. E.S. Raymond sformułował Prawo Linus’a (ang. Linus’s Law od imienia Linus’a Torvalds’a), o którym możemy przeczytać w jego sławnym eseju „Katedra i Bazar” (ang. „The Cathedral and The Bazaar”). Opiera się ono na stwierdzeniu iż, „danie wystarczająco dużej ilości pary oczu spowoduje, że wszystkie błędy staną się powierzchowne”, co w bardziej formalnej formie oznacza, iż zwrócenie się do wystarczająco dużej ilości beta-testerów oraz współdeveloperów spowoduje bardzo szybką charakterystykę prawie każdego problemu, tym samym dostarczając oczywistych ich rozwiązań. Dlatego bezpieczeństwo Open Source jest, jak tysiąc ludzi budujących Arkę, a bezpieczeństwo zamkniętych źródeł jak setka budujących Tytanica.

    • swietnie to ujałeś!

      (przepraszam za odpowiedz na dole nie trafilem w komentarz :D mialo byc do tego ;))

  6. Uważam że na to pytanie ciężko odpowiedzieć jednoznacznie, odpowiadając się jednocześnie za którymkolwiek z typów oprogramowania. Myślę jednak że u wielu osób panuje mylne przekonanie, że jeśli coś jest ogólnodostępne to musi być gorsze od tego, za co trzeba zapłacić. Uważam jednak że Open Source jest bardziej bezpieczne, gdyż społeczność mając dostęp do kodu stara się go poprawić bo przecież, każdy zaawansowany mniej lub bardziej user chce aby programy z których korzysta były jeszcze lepsze, bezpieczniejsze i wydajniejsze co prowadzi do ciągłego rozwoju programu. Oczywiście istnieje również niebezpieczeństwo gdyż znając kod programu można łatwiej znaleźć w nim luki aczkolwiek myślę że niewielu zabierało by się za włamywanie przez programy Open Source, większym wyzwaniem są dla niech programy o zamkniętym kodzie.

  7. To zależy. W przypadku bardzo popularnych aplikacji, gdzie dużo programistów ochotników bierze udział w rozwoju projektu jest dużo większa szansa na znalezienie wszystkich luk i błędów. Bierze się to z faktu nie tylko liczby osób uczestniczących w rozwoju, ale także potencjalnie szerokiego wachlarza ich zainteresowań (część osób może interesować się bezpieczeństwem, mając większe predyspozycje do wyłapywania luk pod tym kątem). Natomiast w przypadku projektów mniej popularnych, tworzonych na “uboczu opensourcowego światka” bezpieczeństwo aplikacji może drastycznie spaść – mniej osób będzie brało osób w rozwoju projektu, mniejsze szanse na znalezienie błędów, a potencjalny atakujący ma cały szczegółowy “plan banku” dostępny ściągnięcia w każdej chwili. Dlatego nie można jednoznacznie określić zasady działającej dla wszystkich projektów open source, a każde rozwiązanie ma swoje wady i zalety.

    • Całkowicie się z tym jednym komentarzem zgadzam. Open Source jest po prostu inne… Każde swoje rozwiązanie ma swoje wady i zalety. Wolne oprogramowanie otwiera przed nami nowe możliwości, ale także stwarza nowe zagrożenia.

      W dużych projektach z rozbudowaną społecznością Otwarte oprogramowanie > Oprogramowanie zamknięte.

      W mniejszych projektach, nad którymi często pracuje jedna, czy dwie osoby po pracy w “garażowym studiu” w zamian za poklepanie po plecach i tekst “dzięki stary!” od użyszkodników, którym często nie chce się nawet wysłać raportu o błędach poziom bezpieczeństwa drastycznie spada.

      Wspomnieć trzeba też, że projektami takimi często zajmują się ludzie młodzi rozpoczynający swoją przygodę z światem IT i nie koniecznie znający się na rzeczy (pierwsze projekty). Wystawiają często “plan banku” w nadziei, że ktoś pomoże w rozwoju i często się rozczarowują…

  8. Rozwiązania OpenSource są bezpieczniejsze ze względu na to, że każdy może przyczynić się do poprawy bezpieczeństwa projektu zgłaszając błędy lub gotowe poprawki.
    Otwarty kod ma tą zaletę, że każdy może go pobrać, przejrzeć skompilować mając przy tym pewność, że jest on bezpieczny.
    Według prawa Linusa skonstruowanego przez Erica S. Raymonda – “Wystarczająca liczba przyglądających się oczu sprawia, że wszystkie błędy stają się banalne” jest większa szansa na odnalezienie luki w otwartym kodzie niż w zamkniętym ponieważ wraz z liczbą oczu patrzących w kod rośnie prawdopodobieństwo wykrycia błędu.

  9. Biorąc pod uwagę fakt, że potencjalnie każdy rodzaj oprogramowania może posiadać błędy, wyraź swoją opinię na temat bezpieczeństwa rozwiązań Open Source. Czy uważasz, że jest ono mniej czy bardziej bezpieczne niż oprogramowanie o zamkniętym kodzie źródłowym?

    Odpowiedź:
    Oprogramowanie otwarte moim zdaniem jest bardziej bezpiecznie od tego zamkniętego, dlatego, że każdy może odkryć błędy a one będą dla wszystkich jawne w przeciwieństwie do “zamkniętych” gdzie wie o nich osoba zgłaszająca błąd i firma. Ponadto wiele osób zna dany system/program i nie ma potrzeby pisać go od 0, łatwiej razem łatać błędy niż je pomijać myśląc, że nikt ich nie zauważy. W jednym zdaniu: Zbyt wiele osób(tych nawet nie związanych z projektem) widzi kod by mogli coś ukryć.

    P.S
    Koszulkę można ?:]

  10. Moim zdaniem otwartosc kodu moze wplynac na bezpieczenstwo zarowno poprzez odnajdywanie przez spolecznosc bledow i ich zglaszanie w celu szybkiego poprawienia (lub tez zglaszanie gotowych poprawek) jak tez moze byc wykorzystana do ataku – adwersarz moze analizowac kod programu dzieki czemu latwiej jest mu przygotowac atak. Nie mniej jednak, w przypadku wykrycia ataku oraz jego przyczyny (czyli wykorzystanie danego oprogramowania) reakcja w przypadku oprogramowania Open Source moze byc natychmiastowa zas w przypadku oprogramowania o kodzie zamknietym czas reakcji jest uzalezniony od autora oprogramowania.
    Powyzsze ukazuje wyzszosc w kwestii bezpieczenstwa oprogramowania Open Source nad oprogramowaniem o zamknietym kodzie zrodlowym.

  11. Aż chciałoby się powiedzieć, że “No jasne, że open-source jest bezpieczniejsze” – ale wg mnie nie jest to aż tak jednoznaczne.

    Open source potrafi czasem dać _złudzenie_ bezpieczeństwa, jeśli ktoś automatycznie kojarzy open source z bezpieczeństwem. Dlaczego? “Nie znam się na tym programowaniu, ale ten projekt, którego chcę użyć, jest open source, więc na pewno jest bezpieczny”. Czytelnicy Niebezpiecznika zgodzą się jednak zapewne z tezą, że dałoby się wykreować projekt open source, korzystający z różnych technik “zaciemniania” kodu, z zamkniętą listą developerów, dostosowany do potrzeb grupy nieco mniej obeznanej z bezpieczeństwem – bo ja wiem, domów mody na przykład. Kod źródłowy otwarty? No to bezpieczne. Mogłoby minąć trochę czasu, zanim jakiś specjalista przebiłby się przez kod softu i stwierdził, że w rzeczywistości tworzy np. sprytnego backdoora.

    Trochę jak wpadka przy IPSecu w BSD (dobrze pamiętam?) albo OpenSSH w Debianie – wszyscy wiedzą, że jest opensource, i że “przecież ktoś to sprawdza”. Cóż, okazało się, że nie całkiem. Mówimy o open source, mając na myśli, że “przecież każdy może zobaczyć, co się tam dzieje” – ale spójrzmy prawdzie w oczy, przeciętny admin nie ma czasu ani umiejętności na szukanie dziur w apache’u, musi się zdać na elitarną grupę osób, które to potrafią zrobić dobrze. Czyli bezpiecznie zaczyna być dopiero, jeśli wokół projektu zebrała się taka grupa osób.

    Jeśli coś podejrzewamy, chcemy pogrzebać – w open source _możemy_. Korzystając z programów z zamkniętym źródłem – nie bardzo, jesteśmy całkowicie zdani na łaskę producenta oprogramowania. Z drugiej strony (disklamer: nie jestem programistą, więc trudno mi powiedzieć, jakim ułatwieniem dla blackhatów jest dostęp do źródła softu) chyba łatwiej jest przeglądnąć kod w poszukiwaniu upragnionego getc(), niż przebijać się przez deasembler? Więc gorzej wykształcony blackhat w przypadku open source ma ułatwione zadanie.

    Cała rzecz sprowadza się raczej do porównywania, jak kuszącym (w znaczeniu “high-profile”) celem jest dany kawałek softu: np. system operacyjny. Czy Linux jest bezpieczniejszy od Windowsa? Zapewne tak, masa ludzi dba o to, żeby był dobrze i bezpiecznie napisany. Czy Haiku jest bezpieczniejszy od Windows? Tu już zacząłbym się zastanawiać – mniejsza baza użytkowników, developerów, ale też mniejsza baza ludzi, którzy chcą zrobić krzywdę. Czyli trudno powiedzieć.

    Ale podsumowując – moim zdaniem open source JEST bezpieczniejszy od closed source – ale należy mieć świadomość, że bezpieczeństwa tego nie gwarantuje sama dostępność kodu, ale raczej dostępność kodu + ilość ludzi, którzy są gotowi projekt rozwijać i nad nim pracować.

    Sorka za przydługiego posta, a że to mój debiut tutaj – to witam wszystkich :-)

  12. Każdy kij ma dwa końce, z jednej strony więcej oczu patrzy w otwarty kod, z drugiej strony zamknięty kod jest trudniejszy do analizy i wykrycie nieoczywistego błędu wymaga większych zasobów.

    • czy to aby nie klasyczne security by obscurity? ta technika jest deprecated

    • Zakładając jednakową jakość kodu, to znalezienie i wykorzystanie błędu w zamkniętym oprogramowaniu jest po prostu trudniejsze. Czym mniej trywialny błąd, tym więcej pracy potrzeba. Pozostaje kwestia jakości kodu…

  13. Myślę że otwartość kodu odpowiedzi(czyt. jej treści) powoduje nierówne szanse. Ktoś może przeczytać wszystkie odpowiedzi i wyciągnąć z nich wszystkich to co najlepsze :P . Więc równość szans i sprawiedliwość są zagrożone.

    • Ależ przecież to jest istotą open source, każdy korzysta z pracy poprzedników.

  14. Nie uważam aby oprogramowanie zarówno o otwartym jak i zamkniętym kodzie było mniej bezpieczne od tego, które okaże się tym drugim w kolejności – dlatego iż wszystko zależy od najsłabszego ogniwa jakim jest człowiek.
    pozdrawiam

  15. Biorąc pod uwagę to, że oprogramowanie Open Source jest otwarte to trzeba pamiętać o tym, iż do jego kodu źródłowego ma dostęp każdy, a więc każdy może wykryć potencjalny błąd. Tym kimś może być zarówno haker jak i kraker, co prowadzi do tego, że podatność może zostać upubliczniona w taki sposób, aby dać producentowi szansę na załatanie, może też to być Zero Day tudzież może nigdy nie zostać upubliczniona i służyć do złych zamiarów.

    Na świecie istnieje 6 miliardów ludzi więc mniej lub więcej ludzi może błąd wykorzystać w dobry lub zły sposób.

    Oprogramowanie zamknięte ma to do siebie, że wgląd w kod mają tylko producenci natomiast ludzie z zewnątrz aby poznać jego strukturę muszą się znać na inżynierii wstecznej. Prowadzi to do tego, że możliwość wykrywania błędów ma o wiele mniej ludzi, którzy mogą być o wiele, że tak się wyrażę, słabsi w te klocki.

    Tak więc nie ma jednoznacznej odpowiedzi na to czy Open Source jest bezpieczniejsze lub mniej bezpieczne od oprogramowania zamkniętego. Aczkolwiek cały czas nasuwa mi się na myśl ile błędów jest w software Microsoftu czy Adobe w porównaniu do Linuksa.

  16. Odpowiedź jest prosta nie jest ani mniej ani bardziej bezpieczne. Oprogramowanie open source jest raczej sposobem prowadzenia projektu i jak każdy ma swoje wady i zalety. Żeby tego nie zamieniać w wielki elaborat porównujący zamknięte i otwarte projekty warto sobie uświadomić gdzie są granice poszczególnych podejść. Jak dużo kodu mogą sprawdzić zatrudnieni specjaliści, a ile błędów może znaleść napalony developer w nieprzespane noce :) Z drugiej zaś strony nie można założyć, że jeśli projekt jest dostatecznie duży, otwarty i mainstreamowy to automatycznie jest bezpieczny, ponieważ wystarczy rzucić informacje o backdorze w ip stacku (temat z fbi i bodajrze openbsd) i wszyscy się zastanawiają czy może jednak :> Reasumując prostej odpowiedzi nie ma i dobrze jest mieć przy sterach ponadprzeciętną jednostkę z wizją aby nad tym wszystkim czuwała. A prywatnie i z doświadczenia uważam, że bardziej ufam oprogramowaniu otwartemu szczególnie że sam mogę sobie pogrzebać w źródełkach, debugować i poprawiać. I uważam, że projekty zamknięte częściej stosują ukrywanie błędów niż ich faktyczne łatanie a następnie jeśli łatają to naprawdę dramatycznie duzo zajmuje im to czasu (np: MS ze swoim WIN). Projekt otwarty mimo, że znaleziono w nim dziursko (np: ostatnia dzura w php), developerzy wydali dość szybko poprawkę ale już parę godzin po wypłynięciu pojawiły się łatki nieautoryzowane które równie dobrze załatwiały sprawę. Można moim zdaniem spokojnie napisć tak: open source sprzyja lepszemu bezpieczeństwu, a jak to zostanie wykorzystane to zależy od developerów.

  17. Ja troszkę z innej beczki…
    Zastanawiam się nad nazewnictwem tej konferencji i agendą ,która jej towarzyszy.
    Wszyscy wiemy co to jest Open Source i jak ważna rolę pełni w naszym życiu tego rodzaju “kod”.
    Zastanawiam się, dlaczego w agendzie jest tak nie wiele z open source, a tak “napaćkane” komercją i rozwiązaniami (NIE)open source.
    Chciałem iść :), ale moim zdaniem szkoda czasu. (to oczywiście moje zdanie).

  18. na tak zadane pytanie głosuje iż bardziej bezpieczne jest zamkniete oprogramowanie.

    Jak wspominaja wczesniej przez “nierowność szans” .. moze kiedys kazdy byl w stanie przejrzec kod i kompilować kod, dzis raczej cięzko z racji tego polegamy w wiekszosci na gotowych binariach. I łatwiej kontrolować garstke osób majaca dostep do żrodel niz “masy”, łamiące bezpieczeństwo majac kody zrodlowe. Łamanie zabezpieczeń w ciemno jest wiele trudniejsze, nawet jesli sa wstanie dokonac dekompozycji aplikacji do kodu jakiejs postaci żrodłowego.

    Prosze sobie wyobrazic sytuacje ujawnienia pełnego kodu zrodlowego windows :) co by sie to działo.

    Podnoszenie argumentów, kiedy OpenSource umozliwia szybsza reakcje przy usuwaniu zagrożen, chyba nie jest na miejscu. Wszystko zalezy od podejścia do kwestii zabezpieczeń. Nie myliłbym łatwości potencjalnego usunięcia defektu kiedy mamy jej kod z realną możliwością. Co nie zmienia faktu, ze zadajac pytanie “czy aplikacje OpenSource mogą być bardziej bezpiecznie niz z kodem zamknietym”, wtedy odpowiem: Tak 100x TAK, w szczegolnych wypadkach.

  19. Właściwie wszystko zostało już w tym temacie powiedziane. W największym skrócie odpowiedź na pytanie brzmi: “i tak i nie”.

  20. Zakładając, że rozwiązania Open Source “są” tak samo popularne jak produkty zamknięte (czytaj Windowsy – pod warunkiem, że nie ma się dostępu do kodu, a taka możliwość jest w pewnych przypadkach) to można pokusić się o stwierdzenie, że mogą być bezpieczniejsze. Dlaczego? bo będzie duża grupa zapaleńców, miłośników otwartego kodu, czy też ekspertów, którzy po godzinach pracy normalnego developera napiszą kawałek kodu (bo mają dostęp do źródła) i zminimalizują czas dostępności podatności w danym systemie. W przypadku zamkniętego kodu sprowadza się to do “zgłoszenia incydentu, uruchomienia sztabu analityków i programistów, testerów, itd.” i jak widać ścieżka stworzenia samej poprawki będzie o wiele dłuższa oraz kosztowna, a sama publikacja może pojawić się po miesiącu lub dłuższym okresie czasu. W aspekcie bezpieczeństwa należy rozważyć również kwestię samego podejścia programisty, który kod napisze – w podejściu zaprezentowanym powyżej kod otwarty nie koniecznie musi być “dobrej jakości”, ale na pewno poprawki pojawią się szybciej niż w kodzie zamkniętym.
    Patrząc na same systemy zabezpieczeń bazujące na kodzie otwartym lub zamkniętym, nie można w prosty sposób odpowiedź na pytanie, co będzie “bezpieczniejsze”? Każda forma ma swoje wady i zalety. Patrząc na obecne środowiska IT w każdym z nich znajdziemy rozwiązania heterogeniczne, więc nie ma nastawienia na rozwiązania “tylko otwarte” lub “tylko zamknięte”!

  21. Otwarty kod MOŻE być bezpieczniejszy. Lecz sama licencja go takim nie czyni.
    Warto rozważyć parę kwestii w tym porównaniu

    a) “security through obscurity” – do którego rozwiązania jest skłonośc w zamknięto źródłowych projektach. W opensource nie ma możliwości jego wprowadzenia. Takie “rozwiązanie” będzie działać przez jakiś czas (przez czas mam tu na myśli czas * ilość użytkowników), po czym zagrożona
    b) ograniczone zasoby/weryfikacja – przy ograniczonym zespole, kod napisany będzie jedynie na miarę jego umiejętności, w opensource, możemy liczyć jednak na ewelucje oprogramowania, która wyeleminuje jego słabe fragmenty (zdolniejszy programista naprawi to co sknocił poprzednik). Także na jeden fragment kodu spojrzy dużo więcej osób – tutaj jest prosta zasada co dwie głowy to nie jedna. Nie należy jednak zakładać że bycie opensource od razu oznacza, ze miliony ludzi będą chcieli nasze oprogramowanie udoskonalać. Wszystko zależy od popularności.
    c) backdoor – wprowadzenie backdooru jest dużo łatwiejsze w opensource (jeśli pozwalaja na wprowadzanie zmian z zewnątrz), ale jego ukrycie już znacznie trudniejsze patrz pkt b
    d) aktualizacje/wykrywanie błędów – w opensource nowo wprowadzono błąd jest łatwiejszy do wykrycia i wykorzystania, ale także do załatania. Największym problemem jest tu także czas reakcji administratora.
    e) popularność – i tu kwestia jak na to spojrzymy. Jeśli na obecną sytuacje – gdzie jednak nadal software opensource jest rzadziej spotykany w domach, to jesteśmy bardziej bezpieczni – w końcu atakuje się jak najbardziej popularne platformy. Jeśli jednak chcemy skonstruować bardziej ogólną zasade, to należy zauważyć, że zagrożenie w opensource zwiększa się równie szybko jeśli nie szybciej (patrz pkt d), ale powinno być równoważone przez zwiększającą się społeczność dewolperów (patrz pkt b).

    Sądzę, że jeśli otwieramy nasz kod, i czerpiemy wszystkie korzyści z tego poprzez dobrą współpracą ze społecznością, poziom bezpieczeństwa może bardzo wzrosnąć. Szczególnie jeśli nasza społeczność skupia głównie poweruserów.

    Jednak jest to tylko możliwość. a nie automatyczna gwarancja jakości.

  22. Sam konkurs tez jest widze open source ;] Wszystkie odpowiedzi dostepne sa dla wszystkich :D

  23. piewcy open source, porownajcie sobie ilosc bugow w IE8 w tym roku, do ilosci bugow w webkicie / firefoxie. porownajcie sobie tez ilosc bugow w jadrze w7 i w jadrze linuxa.

  24. jak ktoś popsuje coś w open source to sam sobie to naprawię,
    jak coś popsuję w open source to ktoś to prędzej czy później naprawi :>

  25. Z bezpieczeństwem programów open source jest jak z bezpieczeństwem samodzielnie upieczonego ciasta, wszyscy znamy przepis, wiemy jakie składniki są użyte i co nam grozi.
    Ciasto kupione w cukierni, może być smaczniejsze i bardziej renomowane, ale nie wiesz czym tak naprawdę jest napchane.
    Oba ciastka spełniają to samo zadanie – są smaczne i słodkie, aczkolwiek w open source’owym rozwiązaniu to ja i osoby układające przepis mają wpływ na bezpieczeństwo rozwiązania. W zamkniętych “przepisach” mogę zdać się tylko na markę, “wiarę” w profesjonalizm.

  26. Oprogramowanie Open Source jak i “zamknięte” projekty mają swoje wady i zalety w zakresie bezpieczeństwa. Do kodu projektów Open Source dostęp ma każdy, więc każdy może znaleźć jakiś błąd. Wszystko jest ok dopóki ktoś nie poinformuje o błędzie i go wykorzysta, jednak może to się zdarzyć również w zamkniętym projekcie, chociaż będzie to wymagało od “zainteresowanego” większego doświadczenia i poświęcenia większej ilości czasu. Kod Open Source może zostać szybciej załatany, a błędy mimo wszystko szybciej znalezione i naprawione. Ponadto w tego typu projektach, w wielu przypadkach istnieje możliwość zabezpieczenia się przed wykorzystaniem znanych błędów na wiele sposobów, co pozwala na zwiększenie poziomu bezpieczeństwa poszczególnych projektów opartych na tym samym kodzie źródłowym. Podsumowując – projekty Open Source są lepiej zabezpieczone dopiero po pewnym czasie istnienia, natomiast projekty o zamkniętym kodzie źródłowym są mniej podatne na błędy na początku, jednak z czasem błędów tych pojawia się coraz więcej i trudniej jest je “wytropić”.

  27. Zacząć trzeba od tego, iż nie ma pojęcia “bezpiecznie oprogramowanie”. Bezpiecznie oprogramowanie, to takie, które nie posiada dziur bezpieczeństwa. Jednak dzisiejsze realia pokazują, iż każde narzędzie, program może posiadać dziury. Kwestia tego, ile osób jest w stanie pracować nad źródłem takiego oprogramowania. Zamknięty kod ma to do siebie, iż jedynie twórcy mogą implementować łatki, lub zapobiegać zawczasu problemom luk. W tym przypadku, osoby, które znajdą lukę, mogą przekazać developerom softu informację, że taka luka istnieje – albo nie. W tym momencie, takie oprogramowanie będzie cały czas narażone na ataki – jeśli dziura zostanie wykryta, a nie zgłoszona, to osoba która ją znajdzie, może dalej atakować. Rzecz ma się trochę inaczej w stosunku do oprogramowania Open Source. Nad kodem może pracować wielu ludzi, jeśli ktoś znajduje dziurę – może sam ją załatać. Ale można również znaleźć dziurę w kodzie, i tak ją wykorzystywać, nie poprawiając/ nie informując społeczności która nad danym oprogramowaniem pracuje.

    Reasumując. OpenSource może być bardziej bezpieczny z racji tego, iż więcej osób może wpływać na jego rozwój i bezpieczeństwo.

  28. Odpowiedź prosta. Jednym płacą za pisanie kodu, drugim nie zawsze, zależnie od chęci wpływa to na jakość. Ale jedną rzecz OS ma dobrą: każdy może wejść w źródło, zobaczyć co programista miał na myśli, wprowadzić/zasugerować swoje poprawki czy zabezpieczenia. Przez ‘każdy’ mam na myśli praktycznie całą społeczność Internetu, daje to właściwie pełne spektrum możliwych sposobów myślenia, ogromne możliwości ulepszenia kodu.

    Poza tym, założę się, że ktoś wyżej już to samo napisał ^.^

  29. Uważam, że znaczenie kwestii otwartości kodu dla bezpieczeństwa oprogramowania jest mocno przeceniane. Otwartość jest bowiem mieczem obosiecznym, dającym obydwu stronom (użytkownikom/włamywaczom) większe możliwości. Z jednej strony możliwość wygodnej (bez reverse engineeringu) analizy kodu i szukania (oraz wprowadzania błędów), z drugiej potencjalnie większe grono audytorów i szybsze wprowadzanie poprawek.
    Summa summarum wszystko i tak sprowadza się do przewagi (intelektualnej bądź liczebnej) strony atakującej i broniącej się. Siła obu stron zaś zwykle jest proporcjonalna do atrakcyjności celu, czyli popularności oprogramowania.
    Ostatnie stwierdzenie skutkuje paradoksalnym wnioskiem, że nawet stosowanie mniej popularnego oprogramowania niekonieczne oznacza mniejsze ryzyko – mniejsze szanse na zainteresowanie się nim przez włamywaczy idzie bowiem w parze z mniejszymi szansami na szybkie załatanie dziur.
    Ostatecznie najważniejszym czynnikiem jest sam użytkownik, dokładniej zaś jego umiejętność wyboru bezpieczniejszego rozwiązania, umiejętność rozpoznania niepokojących symptomów, wreszcie umiejętność wykorzystania ewentualnych zalet wynikających z otwartości kodu.
    Otwarte oprogramowanie ma wiele przewag nad zamkniętym, ale kwestia bezpośredniego bezpieczeństwa (podatności i dziur/łatania i poprawek) raczej do nich nie zależy, jeśli porzucimy tendencję do skupiania się na jedynie kilku najpopularniejszych aplikacjach.

  30. Open Source jest bezpieczne, bo używając Open Source nie będziecie ukamieniowani:
    “Na podstawie J 8:2-16
    Wówczas uczeni w piśmie i agenci BSA przyprowadzili do niego kobietę, którą pochwycono na kopiowaniu CD-ków, a postawiwszy ją pośrodku, powiedzieli do Niego:
    Nauczycielu, tę kobietę dopiero pochwycono na kopiowaniu CD-ków. W prawie Ustawa o Prawach Autorskich nakazuje nam takie kamieniować. A Ty co mówisz?. Mówili to wystawiając go na próbę, aby mieli o co go oskarżyć.

    Lecz on nachyliwszy się nad laptopem kodował w assemblerze. A kiedy w dalszym ciągu go pytali, podniósł się i rzekł do nich: Kto z was nie miał nigdy pirackiej kopii, niech pierwszy rzuci na nią kamień. I powtórnie nachyliwszy się kodował w assemblerze. Kiedy to usłyszeli, wszyscy jeden po drugim zaczęli odchodzić, poczynając od starszych, aż do ostatnich. Pozostał tylko on i kobieta, stojąca na środku.
    Wówczas, zachowawszy kod na dysku rzekł do niej “Kobieto, gdzież oni są? Nikt cię nie potępił?” A ona odrzekła “Nikt, Panie!”. Rzekł do niej: i ja ciebie nie potępiam. Idź, a od tej chwili nie bierz już do ręki CD-ka chronionego prawem autorskim.

    A oto znów przemówił do nich tymi słowami: Ja jestem open source, kto idzie za mną, nie będzie płacił bandytom za licencje. Rzekli do niego prawnicy: Ty sam sobie wydajesz licencję. Licencja twoja nie jest prawdziwa! W odpowiedzi rzekł do nich: Nawet jeśli ja sam sobie wydaję licencję, licencja moja jest prawdziwa, bo wiem skąd powstał mój kod źródłowy open source i jak będzie działał. Wy zaś nie wiecie ani co jest w execach, ani co one robią. Wy dajecie sąd według zasad bandyckich, ja nie bronię licencji nikomu. A nawet, jeśli zabronię, to moja licencja jest prawdziwa, bo nie jest to mój exec, ale wszystkich, którzy się do niego przyczynili.”

  31. Naprawdę ciężko jednoznacznie stwierdzić, który typ oprogramowania jest bezpieczniejszy. Zarówno za wadę jak i zaletę można uznać dostępność do otwartego kodu.
    Jednak pytanie precyzuje – “wyraź SWOJE zdanie”. Dlatego moim zdaniem Open Source jest bardziej bezpieczny. Co prawda na pewno kilka osób będzie chciało znalezione błędy wykorzystać w niekoniecznie dobrych zamiarach, jednak znaczna większość (głównie z pasji do tego co robi) będzie próbowała “załatać” daną lukę. Chodzi tu o SPOŁECZNOŚĆ. Często producentami zamkniętego oprogramowania są firmy, które mało co obchodzą mniejsze (co nie znaczy bezpieczniejsze) błędy, których nie kwapią się szybko naprawiać. Oni robią oprogramowanie dla zysku. Open Source (głównie) tworzone jest z pasji i dlatego jest ono bezpieczniejsze (co nie znaczy, że nie do pokonania ;) ) niż oprogramowanie zamknięte.

  32. Niestety – nie ma zwycięzcy. Nie można powiedzieć czy bezpieczniejszy jest OSS czy soft własnościowy. Przy własnościowym mamy jednak kogoś, kto ponosi odpowiedzialnośc za jakość, bezpieczeństwo (także licencyjne) i szybkośc przygotowania poprawek.
    A co do OSS – czasami jest bezpieczniejszy niż się wydaje “społeczności”;-)
    Opowieści o czytaniu i rozumieniu kodu przez tysiące programistów należy między bajki włożyć. A najlepszym na to dowodem jest słynna sprawa IPSec stack w OpenBSD
    http://www.pcworld.com/article/213751/former_contractor_says_fbi_put_back_door_in_openbsd.html?tk=rss_news
    http://www.lockergnome.com/theoracle/2010/12/15/openbsd-compromised-by-fbi-insider/
    Pryska czar – mimo że ludzie przez 10 lat widzieli kod, to nie dostrzegali “furtek”. Gdy kod pisze naprawdę DOBRY programista – to tylko programista LEPSZY będzie w stanie zrozumiec pełni co ten kod robi…

  33. Bezpieczeństwo twojej infrastruktury IT nie zależy od tego czy używasz oprogramowania open sourse czy oprogramowania własnościowego. Bezpieczeństwo twojej infrastruktury IT zależy od tego jak zaimplementujesz w niej to oprogramowanie oraz jak będą z niego korzystać ludzie.

  34. Dokładnie już ktoś to tutaj napisał… agenda śmierdzi komercją…

  35. Tak jak w przyrodzie panuje równowaga, tak zarówno w świecie rozwiązań bezpieczeństwa oprogramowania można znaleźć oba typy tj. z zamkniętym i otwartym kodem (i dzięki bogu ;), a każdy użytkownik ma sposobność na własnej skórze przekonać się o zaletach i wadach, co jest największą zaletą – brak monopolu i dominacji – równowaga. Zatem każdy malkontent może wyrobić swoje zdanie i pogląd w tym temacie. Nie podlega dyskusji fakt, że w obu przypadkach musimy polegać na uczciwości programistów (jeśli sami nie potrafimy nic zadziałać w tej materii), a branie na widelec czasu-szybkości reagowania na incydent, co czasami jest kwestią krytyczną, zależy od stopnia komplikacji błędu i tutaj trudno wyłonić jednego zwycięzcę. Analizując historię tego typu incydentów, pokuszę się o stwierdzenie, że tutaj również jest równowaga pomiędzy oboma typami, otwartym i zamkniętym. Do mnie osobiście rozwiązanie otwarto-źródłowe przemawia bardziej z jednego powodu, wszem i wobec wszystkim znanemu i oklepanemu …. , ze względu na ocenę znalezionego zagrożenia przez wielu niezależnych ekspertów niezrzeszonych przez jedną organizację. Dodatkowo pożądane jest aby w przypadku znalezienia luki, również jej dokumentacja wraz z opisem procedury patch-owania była ogólnodostępna i opisana językiem zrozumiałym, nie tylko technicznym. Warto docenić pracę tysięcy wolontariuszy! Cieszę się, że nie jestem skazany ‘na sukces’ jednego ‘wiodącego rozwiązania’. Dzięki nim świat nie dąży do monopolizacji.

  36. Jeśli nie wiadomo do końca kto edytuje dane oprogramowanie Open Source, to nie jest to bezpieczniejsze od ‘zamkniętego’ oprogramowania – chociażby ostatni backdoor w stosie IPSEC. Z drugiej strony, brak dostępu do źródeł powoduje, że czasem programiści piszą kod niechlujnie, byle by działało, bądź opierają się na ‘security by obscurity’. Proste przykłady: ostatnio hackowanie PS3 oraz wieczne problemy z Windowsami ;] Tak więc jednak Open Source jest bezpieczniejszy, jako że takie źródła ludzie przeglądają nie tylko po to, żeby zhackować coś, ale przede wszystkim żeby naprawiać. Przykład z OpenBSD świetnie to pokazuje – znalazł się ktoś, kto znalazł i upublicznił backdoora ;]

  37. Naturalnie oprogramowanie komercyjne jest bezpieczniejsze.
    W przypadku powstania szkody zawinionej przez producenta, odpowiada on zazwyczaj do wartości oprogramowania, co przy OS często jest równe 0 PLN-ów.
    Komercyjne przeważnie ma wyższą wartość.

    Może to i ułomna metryka “bezpieczności” ale i tak o niebo lepsza niż te bzdury o możliwości analizy kodu.
    Niby mam taką możliwość, ale po pracy to mi się zwyczajnie nie chce grzebać w cudzym kodzie.

  38. Dla popularnych i niezbyt szybko zmieniających się aplikacji OS powinno być zdecydowanie bezpieczniejsze, gdyż więcej osób spogląda na każdą linię kodu.
    Ale dla jakichś bardzo dynamicznych lub bardzo mało popularnych projektów będzie raczej na odwrót.
    A w pozostałych wypadkach pewnie więcej zależy od teamu i procesu, niż podziału Open/Close source.

  39. Ogolnie to nie ma znaczenia czy chodzi o otwarty lub zamkniety kod. Kwestia ktora wersja ma lepsze wsparcie. Zaawansowany uzytkownik bedzie wolal programy w ktore sam moze ingerowac /zabezpieczac/zmienac co w sumie nie jest wolne od bledow ,ale moze pomagac przyestosowac program do wlasnych potrzeb. Poczatkujacy uzytkownik nie posiadajacy duzej wiedzy na temat nie bedzie mogl za duzo zdzialac ,ale bedzie mogl wykorzystac to co stworzyl ten bardziej zaawansowany. Pytanie jest czy ten zaawansowany uzytkownik nie dodal tam jakiegos “evil” kodu.

  40. Ale się tutaj laurek na temat open source naczytałem :) Bezpieczeństwo oprogramowania w mniejszym stopniu zależy od tego, czy jest to open source czy closed source. Bardziej istotny jest sposób jego rozwoju (istnienie SDLC), a to w obu przypadkach można, mówiąc kolokwialnie, spieprzyć.

    Nie do końca przemawia do mnie również argument “każdy może sprawdzić”. Nie przemawia z kilku powodów. Choćby dlatego, że nie każdy może sprawdzić, bo do tego potrzebne są jednak pewne kwalifikacje i nie każdy je posiada. Po drugie w takim przypadku często następuje rozmycie odpowiedzialności na zasadzie “weźmy i zróbcie”. Ten problem nie dotyczy wyłącznie kwestii związanych z programowaniem, ale ogólnie z postępowaniem człowieka. Przykładowo w trakcie kryzysu (wypadek, katastrofa) nie można mówić “niech mi ktoś pomoże”, “niech ktoś zadzwoni po pomoc”, bo wówczas każdy będzie czekał, aż ktoś inny zareaguje. W tym kontekście siła społeczności jest, moim zdaniem, przeceniana. Oczywiście nie neguję istnienia projektów open source z dobrze i konsekwentnie działającą społecznością. Założenie, że dla każdego projektu taka społeczność istnieje, jest zwyczajnie naiwne i niestety nieprawdziwe.

    Kolejna sprawa to środki, które można zainwestować w budowanie bezpieczeństwa produktu. Dobre narzędzia do statycznej analizy kodu źródłowego kosztują, nie każdy projekt open source może sobie na nie pozwolić, nie każdy jest na tyle duży/znany, by zasłużyć sobie na “sponsorowany” przegląd kodu. I oczywiście działa to w drugą stronę, wcale nie jest powiedziane, że projekt closed source, który kosztuje wiele $$$ z takich narzędzi na pewno korzysta. Czyli wracamy do początku – nie to czy projekt jest open source czy closed source, ale jak wygląda proces tworzenia kodu, testowania, utrzymania.

    I na koniec jeszcze jedno – bezpieczeństwa oprogramowania nie buduje się tylko przez łatanie dziur…

  41. Z jednej strony mamy oprogramowanie Open Source. Pracują nad nim niezliczone rzesze ludzi którzy próbują znaleźć wszelakie błędy w programach. Jednakże kod źródłowy jest ogólnie dostępny i można na własną rękę poszukać w nim błędów i wykorzystać je do pisania idealnych exploitów. Z drugiej strony mamy programy o zamkniętym kodzie źródłowym, który jest znany tylko dla wąskiego grona specjalistów/pracowników. W tym przypadku mamy mniej oczu do szukania błędów w kodzie, ale za to nikt nie odpowiedni nie dostanie się do niego(Poza przypadkami wyniesienia kodu źródłowego. Np. Przez pracownika firmy Ka$persky).
    Na przykładzie Linuxa
    Przyjęło się że Open Source jest święte i wolne od ataków. Większość populacji ma w komputerach oprogramowanie z rodziny Windows i w nie były wycelowane praktycznie wszystkie ataki. Lecz czasy się zmieniły. Teraz przez zwykłą przeglądarkę internetową można zostać zaatakowanym a takowe są Multiplatformowe więc każdy jest narażony.
    Patrząc na to nie można jednogłośnie powiedzieć co jest bezpieczniejsze. Można jedynie spekulować.
    Według mnie jednak oprogramowanie Open Source jest bezpieczniejsze.

  42. W teorii każdy rodzaj oprogramowania jest tak samo bezpieczny jak inny – zasadniczo w praktyce jest tak samo. Wszystko zależy od tego jak developerzy i programiści podejdą do sprawy lub też jak zorganizują sobie mechanizm zgłaszania błędów i rozpatrywania ich, a także jak dokładnie przetestują swój produkt. W projektach opensourcowych testowanie jest prowadzone praktycznie na bieżąco – każdy może ściągnąć sobie wersje unstable/dev z gita, svna, cvsa, czy innego systemu kontroli wersji, więc jest ono bardziej odporne dziury, gdyż część dziur zostanie wykryta jeszcze przed wydaniem kolejnej wersji oprogramowania. W projektach zamknięto-źródłowych testowanie przypada zazwyczaj na wąską grupę ludzi, która nie wychwyci niektórych błędów, bądź pomyłek w oprogramowaniu. Poza tym wykrywalność dziur wiąże się także z popularnością lub wielkością projektu – więcej luk może być wykryte np. w GNOME, niż w Openboksie, dlaczego? Bo ten drugi jest dużo mniejszy i mniej popularny od tego pierwszego. Według mnie projekty Open Source są bardziej bezpieczne niż zamknięte, bo użytkownicy tych pierwszych mają zazwyczaj ładną bugzillę, gdzie mogą zgłosić każdą swoją wątpliwość dotyczącą produktu, programistów, którzy piszą kod, bo chcą, a nie, bo muszą, a ci, co używają zamkniętych aplikacji mają albo skomplikowane procedury, albo “radź sobie sam”. Reasumując to wszystko, wiele zależy od ludzi tworzących cały projekt, bo można robić dobry kod i chcieć go robić, a także można robić zabugowany kod i odwalać pańszczyznę.

  43. Typowe pytanie z serii windows czy linux, albo nvidia czy coś(zapomniałem).
    Wszytko co się dało wymyślić, zostało już powiedziane/napisane, dodatkowo nie ma możliwości obiektywnego wybrania zwycięzcy, i ostatecznie jest to konkurs na najlepsze wypracowanie(bezsens) albo początek flejma.

  44. Rozwiązania OpenSource mają sporą przewagę nad zamknięto-źródłowymi nie tylko ze względu na możliwość analizy i ew. wnoszenia poprawek do kodu przez zapaleńców, ale również, co być może często jest istotniejsze – z ekonomicznego punktu widzenia, m.in. ze względu na tzw. Vendor Lock-in. Zamknięto-źródłowe aplikacje często mają tak skonstruowaną licencję, że tylko organ wydający (twórca oprogramowania, dystrybutor) mają prawo wprowadzać jakiekolwiek zmiany w oprogramowaniu. Stwarza to duże pole do nadużyć na tle monopolu dla twórcy oprogramowania (wszelkie przystawki do systemu musi wykonywać ta sama firma, która wydała oprogramowanie), ale również może być problematyczne, gdy firma, która stworzyła oprogramowanie upada, a stworzone przez nią oprogramowanie jest nadal w użyciu. Gdy przychodzi konieczność wprowadzenia zmian w systemie, nikt nie ma prawa tego zrobić, ponieważ twórca (firma, jako podmiot prawa cywilnego, jako jedyna uprawniona na mocy licencji do tego) nie istnieje. Jest to sytuacja szczególnie niebezpieczna, gdy dotyczy systemów zarządzających ogromną ilością istotnych danych, jak np. systemy bankowe czy urzędy. Wprowadzenie nowego systemu w życie może być w najlepszym przypadku tylko ogromnie kosztowne, a w skrajnych przypadkach dane mogą być niemożliwe do odtworzenia i przeniesienia do nowego systemu. Sytuacja może dotyczyć zarówno konieczności wprowadzenia zmian w działającym systemie, jak również poprawy znalezionych błędów w oprogramowaniu.
    Jeśli chodzi o możliwość znajdowania i poprawiania błędów w oprogramowaniu, warto pokazać na przykładzie jak świetnie społeczność open-source potrafi sobie radzić z tym problemem.
    Takim przykładem może być sposób tworzenia i prowadzenia projektów na github’ie (github.com), gdzie ludzie na bazie istniejących projektów tworzą własne (“forkują” te istniejące), wówczas kod raz stworzonego projektu jest wielokrotnie, przez różnych programistów, analizowany i dopasowywany do potrzeb swoich projektów. Nie ma możliwości, by osoba forkująca po zauważeniu błędu nie zgłosiła go do main-developera. Tym bardziej, że bardzo łatwo można wychwycić zmiany wprowadzone względem forkowanej dystrybucji.
    Warto również zwrócić uwagę na fakt potencjalnie wyższej jakości kodu open-source, wynikający z chęci pochwalenia się umiejętnościami programistycznymi, które każdy może zaobserwować przeglądając źródła danego programisty. Projekty open-source są swego rodzaju wizytówką (portfolio) programisty.
    W przypadku projektów zamknięto-źródłowych wąska grupa osób może dostrzec jakiej jakości kod tworzy programista, więc nie przykłada się tak wielkiej wagi do sztuki tworzenia dobrego kodu, zgodnie z zasadą – liczy się cel, nie środki (dopóki nie przyjdzie nam szukać błędu w zagmatwanym kodzie). Być może nie jest to regułą, ale może zdarzyć się, że tak jest.

  45. Moim zdaniem zależy to od 2 czynników.
    1 Jakości kodu
    2 Umiejętności i samodyscypliny ekipy wdrażającej/utrzymującej projekt.

    Projekty open source są z jednej strony bardziej narażone na ataki (łatwiej znaleźć błąd) ale i dogłębniej przetestowane.
    Jeśli więc wdraża je ktoś kompetentny kto będzie czuwał nad natychmiastowym aktualizowaniem projektu za który odpowiada Open Source jest doskonałym wyborem.

    Jeśli jednak wdrożenie ma wyglądać jak “odpal i zapomnij” decydując się na open Source’a podpisujemy na projekt wyrok śmierci.

    Jak zwykle w dziedzinie bezpieczeństwa liczy się szybkość łatania ;)

  46. AVE…

    Open Source bezpieczniejsze nie jest:
    1. To, że wielu może przeglądać kod nie oznacza jeszcze, że każdy będzie oglądał inny jego kawałek. Co, jeśli wszyscy skupią się na głównej części programu/systemu, ale oleją jakiś mały duperelek, który zawiera w sobie błąd, dziurę lub backdoora?
    2. Każdy developer może dołożyć ukrytego backdoora i nikt nie sprawdzi, czy czegoś takiego nie umieścił dzięki tajemnej sztuce pisania komentarzy do fragmentów kodu. Ludzie ufają komentarzom, bo te czyta się łatwiej, niż zagmatwany kod. Sprawa z backdoorem w stosie IPSEC w systemach BSD wynikła tylko dlatego, że były współpracownik FBI puścił farbę. Do tej pory nikt by o tym nie wiedział, gdyby nie to. Prawo Linusa nie sprawdziło się w tym przypadku z powodu zaufania do autorów kodu.
    3. W jądrach uniksowych i linuksowych do tej pory tkwią procedury obsługi sprzętu, który wyszedł z użycia 20-30 lat temu. Zły programista może znaleźć taki przestarzały kod i zamienić go tak, by działał jako backdoor lub odkryć błędy w nim zawarte i wykorzystać je jako exploit. Nikt tego nie sprawdzi, bo nikt nie ma sprzętu, którego obsługą zajmował się taki kawałek kodu. Nikt nie odśmiecił jąder na wypadek, gdyby ktoś jeszcze pracował na komputerach PDP-11 i potrzebował korzystać z pamięci taśmowej z tej rodziny.
    4. W otwartych projektach jest jeszcze brak presji na dobre i szybkie programowanie oraz brak efektywnej kontroli. Jak ktoś odwali fuszerkę z lenistwa, to nikt się nie zorientuje przez długi czas, a potem nie będzie na kogo zwalić winy. Przy zamkniętym systemie każdy programista ma określone zadania, i jak wywiąże się z nich źle, to obrywa. A dzięki rozumieniu własnego programistycznego bełkotu sam może naprawiać błędy w miarę ich wykrywania. W systemie otwartym panuje zbyt duża samowola. Jak widzę program w wersji 0.8.1.1, to wiem, że działa w 80% i ma 11% niewykrytych błędów. Do tego tylko duże projekty mają szansę na uniknięcie błędów, mniejsze zaś nigdy nie zostaną skończone i są tylko sposobem na marnotrawienie potencjału. To też zwiększa ryzyko. Ktoś decyduje się na mały system z przydatnymi funkcjami, ale w razie istnienia dziur będzie czekał ad mortem defecatam na ich usunięcie.

  47. Rozwiązania Open Source są mniej bezpieczne od zamknięto źródłowych rozwiązań ponieważ łatwo jest przy określonych działaniach wstrzyknąć kod który nie powinień się znaleść w tym projekcie (np jakiegoś backdora). Takie działania są też zależnie od wielkości projektu, częstości aktualizacji oraz ilości i składu osób pracujących w danym projekcie. Zamknięte oprogramowanie ma przy tym plusy bo ma zaufanych edytorów i uczestników projektu.

  48. 1. Jak zapewne wszyscy wiemy, linux jako projekt opensource zainstalowany jest na około 1% komputerów. Oczywiście przeważają zastosowania serwerowe. Przez małą liczbę urządzeń mamy mało incydentów związanych z bezpieczeństwem (backdoor, wirusy). To zaleta na korzyść OpenSource. Na rynku serwerów i desktopów raczej nic się już nie zmieni.
    Pod tym względem zastosowania systemowe opensource mają przewagę nad rozwiązaniami zamkniętymi (etc. Windows).

    2. Co do oprogramowania opensource zdanie jest dwojakie. Mając dostęp do kodu, każdy złośliwy lub nieuważny developer może wrzucić niepożądany kod, który coś popsuje. Jednak zauważmy, że obecnie każdy projekt jest monitorowany przez systemy kontroli wersji. Jaki projekt opensource nie jest kontrolowany, na np. popularnym github.com ,czy SVN. Cała społeczność opensource monitoruje kto i co wrzuca. Jak ktoś wrzuci coś szkodliwego, zostanie prawdopodobnie wykluczony…

    3. Moim zdaniem projekty opensource rozwijają się dynamiczniej niż produkty zamknięte, bo tworzy je znacznie większa grupa ludzi.

    • AVE…

      Systemy Open Source obejmują około 2% desktopów, ale bodaj 20-30% serwerów, jeśli nie więcej. Częściowo otwarty Google Android pokazał swoją słabość, gdy pojawiły się aplikacje celowo zawirusowane w ich bazie oprogramowania…

  49. Podstawą bezpieczeństwa aplikacji jest poprawne jej działanie. W przypadku kodu otwartego, prawdopodobieństwo wykrycia ewentualnych błędów jest sporo większe niż w przypadku kodu zamkniętego. Dzieje się tak dlatego, gdyż dostęp do kodu źródłowego mają nie tylko developerzy konkretnych aplikacji ale również różnej maści średniej i niskiej klasy programiści. W strukturze opensource istnieje wielokrotna weryfikacja kodu i to bynajmniej nie przez zatrudnionych na etat programistów, którym można zapłacić za „przemilczenie” pewnych spraw. Dosłownie każdy może przejrzeć kod, a w przypadku posiadania umiejętności programistycznych, może ten kod dowolnie zmienić. Może także poprawić znalezione błędy lub zgłosić je do twórców projektu. Prawdą jest fakt, że są ludzie, którzy potrafią wykorzystać otwartość kodu do swych niecnych celów. Jeżeli założymy, że prawdopodobieństwo tego zdarzenia jest większe od 0, to również większe od 0 jest prawdopodobieństwo, że ktoś ten incydent wykryje i opublikuje np. w internecie. Ludzie w społeczności opensource cenią sobie swobodę wymiany informacji, dlatego też wieści o osobach, które działają na szkodę konkretnego projektu lub jego użytkowników, są szybko publikowane przez jednych, a następnie wnikliwie weryfikowane przez innych ludzi. Tego typu sytuacja nie ma miejsca w przypadku kodu zamkniętego, gdzie jesteśmy zdani na łaskę lub niełaskę twórców tego typu oprogramowania.

    Są jeszcze dwie kwestie, które pragnę poruszyć. Jedną z nich jest stosunek użytkowników oprogramowania do twórców tegoż oprogramowania. W przypadku opensource użytkownik czuje emocjonalną więź z twórcami projektu. Czemu? Gdyż ci programiści poświęcają bezinteresownie swój czas, by uczynić tworzone przez siebie oprogramowanie możliwie użyteczne i bezpieczne. Oprogramowanie o otwartych źródłach jest darmowe, a skoro ktoś je tworzy, to nie robi tego z chęci zysku. Przynajmniej nie jest to jego głównym motywem. Twórcy oprogramowania wiedzą doskonale, że jeżeli ich projekty spodobają się odbiorcom, to oni zostaną za to wynagrodzeni. Jest to główny bodziec napędowy otwartego oprogramowania – rób przydatne i bezpieczne rzeczy, a zyskasz sławę, pieniądze i panienki :]

    Ostatnią kwestia jest przyznanie się do błędu. W przypadku wielkich firm, zwłaszcza korporacji wpadki czy błędy są pokazywane w świetle „zaufajcie nam, nie ma powodów do obaw, nic się nie stało”. A przez to bezpieczeństwo użytkownika nie jest traktowane priorytetowo. Jeżeli chodzi o opensource liczy się jak najszybsze wykrycie błędów oraz ich wyeliminowanie, a w przypadku gdy problem tkwi głębiej, poinformowanie swoich użytkowników o rozwiązaniu, jakie mogą zastosować we własnym zakresie, by tymczasowo załatać lukę w bezpieczeństwie.

    Pamiętajmy, że oprogramowanie jest bezpieczne do chwili, aż ktoś nie znajdzie w nim dziury. Na obecnym etapie technologicznym nie jest możliwe stworzenie aplikacji pozbawionej błędów. Dlatego też dużą rolę w bezpieczeństwie oprogramowania odgrywa czynnik ludzki, bo co dwie głowy to nie jedna :]

  50. Każdy kij ma dwa końce OpenSource zapewnia łatwiejsze znalezienie błędu. Ale jeżeli ktoś znajduje lukę w popularnej aplikacji typu CMS to z automatu ma możliwość włamania się na wszystkie strony oparte na tym systemie (dodatkowym ułatwieniem jest nazwa systemu w stopce zaindeksowana przez wyszukiwarki). W przypadku aplikacji o zamkniętym źródle znalezienie takich dziur przez przypadkową osobę jest dużo trudniejsze.

  51. uważam iż nie ma jednoznacznej odpowiedzi na postawione pytanie.
    W teorii bezpieczniejszym jest otwartość kodu źródłowego. Przemawia za tym fakt, iż większa liczba użytkowników – i tych doświadczonych, którzy opracowali pierwotny kod źródłowy, i tych mniej doświadczonych/pozostałych, ma wgląd do tegóż kodu, co zwiększa prawdopodobieństwo wykrycia oraz załatania luki w krótszym czasie (krótszym od zamkniętego zespołu programistów, równie doświadczonych co ci którzy pracowali nad oprogramowaniem o otwartym źródle). Inną kwestią jest możliwość wzglądu w kod celem wykrycia luk które mogą zostać wykorzystane przy planowanym ataku na jeden, określony cel. W tym przypadku bardziej liczy się utrudnienie intruzowi wykorzystania podatnosci systemu (która zawsze się znajdzie w każdym systemie) niżeli szybki czas reakcji na zagrożenie. Innymi słowy, samo bezpieczeństwo kodu zależy od tego czy rozumiemy przez to mniejszą ilość luk (przewaga open-source), czy też trudniejszy dla przestępcy sposób wykorzystania/znalezienia jej (przewaga oprogramowania o zamkniętym źródle).

  52. Biorąc pod uwagę fakt, że potencjalnie każdy rodzaj oprogramowania może posiadać błędy, nie można jednoznacznie stwierdzić przewagi. Zdecydowanie Open Source ma dość dużo zwolenników, aby otrzymywać raporty błędów, przy czym na zamkniętym oprogramowaniu jest ich tylko garstka. Ważną kwestią jest tu motywacja, której nie brakuje programistom Open Source, którzy klepią kod dla czystej przyjemności, w przeciwieństwie do Close Source klepiących kod dla samego zysku. Open Source jest także łatwiejsze do wykrycia błędu i wykorzystania go do złych lub dobrych celów. W komercyjnych programach jest napewno trudniej wyłapać taki błąd w deasemblerze, przy czym komercyjne firmy zapewne poprawią go po ok. miesiącu ;p Nie można jednoznacznie stwierdzić, która strona wygrywa, jednak większość kumatych znajduje się raczej po stronie Wolnego Oprogramowania.

  53. Oprogramowanie Open Source jest bardziej bezpieczny nie tylko dlatego, że weryfikuje je ogromna społeczność, ale również dlatego, że jest generale UNIX-based. A systemy *NIXowe mają prosty, przejrzysty i logiczny model bezpieczeństwa… oraz… twórcy oprogramowania Open Source nie są najczęściej korporacjami, które mają podpisaną stosowną umowę z NSA o “wpieraniu bezpieczeństwa narodowego” – wiadomego państwa, którego – wbrew pozorom i wbrew słowom piosenki Rammsteina ;-) – nie jesteśmy wszyscy obywatelami (jeszcze).

    Dlatego np. dobrze skonfigurowany serwer na Debianie zawsze jest lepszym rozwiązaniem pod względem bezpieczeństwa, niż najlepiej skonfigurowany serwer na W2008R2. Amen.

  54. Uważam że oprogramowanie open source jak i to o zamkniętym kodzie może być równie bezpieczne. Wszystko zależy od zaangażowania, zdolności programistów, czasu poświęconego na testowanie w odniesieniu do wielkości aplikacji. Cóż bym wybrał gdybym zmuszony był wybrać? Wybrałbym to oprogramowanie z którym w przeszłości było jak najmniej problemów, wykrytych poważnych błędów. Błędnym założeniem jest że otwarte oprogramowanie jest bezpieczne, co pokazuje przykład chociażby OpenBSD i FBI, natomiast zamknięte bezpieczne, i niech za przykład podam chociaż wiele krytycznych luk w Adobe Flash oraz starej przeglądarce IE 6. ;-)

  55. Open- i closed-source to tak jak prostytutka i żona.

    Generalnie “open” jest lepsze, bo ma się mnogość wyboru, dopasowanie do własnych potrzeb i możliwości oraz świadomość o szerokim przetestowaniu przez innych użytkowników. Problem tylko w tym, iż niekiedy bezpieczeństwo może być złudne i w najmniej spodziewanym momencie można się mocno zdziwić.

    Więc może “closed”? Wada taka, że jest się przywiązanym do jednego pakietu i jest się na łasce developerów. Ale za to ma się duuużo czasu by produkt wszechstronnie przetestować i przekonać się, iż mimo wyższych kosztów, przy umiejętnym wykorzystaniu, na myśl o open-source można się skrzywić. Ale…. no właśnie, niekiedy może się okazać z 20 latach pożycia przez 15 lat w systemie był babol umożliwiający nieautoryzowany dostęp sąsiadowi.

    Tak więc open i closed-source w kategorii bezpieczeństwa różni się tylko jednym: zaufaniem.

  56. Miło mi być na liście zwycięzców, zwłaszcza, że jestem „spoza branży”.
    Gratuluję wszystkim współzwycięzcom.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: