Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Pogromcy Mitów: Niebezpieczne, otwarte źródła

Ostatnio zaczyna dominować opinia o szkodliwości otwartych źródeł oprogramowania, zwłaszcza ze strony fanów Windowsa. Dla mnie to nielogiczne rozumowanie. Fakt, że otwarte źródła są jakoś związane z Linuksem, czyli bezpośredniej konkurencji Windowsa, nie znaczy, że te programy nie rozwijają także i tego drugiego systemu. Wystarczy wymienić Firefoksa, VLC Player, GIMP, Blender bez których wiele osób nie wyobraża sobie wygodnej pracy z Windows, często nie znajdziemy na Windowsa bardziej wartościowych odpowiedników tych programów w podobnym przedziale cenowym. Krótko mówiąc Open Source łata poważną lukę w Windowsie, dlaczego więc ma być szkodliwe dla tego systemu?

Powyższy przykład pokazuje oczywiście paradoks takiej walki. Linux jest oparty głównie na otwartych źródłach, więc należy walczyć także z otwartymi źródłami. Tyle, że otwarte źródła nie są wyłącznie przypisane do Linuksa. To tak jakby wyznawców jakiejś religii zwalczać na podstawie koloru skóry dominującego w tej społeczności wyznaniowej.

Bezpieczeństwo przede wszystkim

Niemniej jednak jak bardzo niedorzeczna wydawałaby się to walka, to najbardziej niedorzeczne są argumenty przeciwników podważające wartość otwartości (i wolności), a zwłaszcza zarzucanie takiemu oprogramowaniu narażaniu się na niebezpieczeństwo właśnie poprzez otwarcie kodu do wglądu dla każdego. Poniżej nie mam zamiaru oczywiście udowadniać, że jest to oprogramowanie w 100% bezpieczne. Tu może zawieść każdy z czynników umieszczonych na całym etapie dystrybucji, mogę jednak śmiało wysunąć tezę, że taki atak to sztuka dla sztuki w efekcie nie jest on na tyle skuteczny, aby było opłacalne jego wykonanie i to pomijając nawet małą obecnie popularność dystrybucji linuksowych.

Złośliwie mogę nawet założyć, że jedyne co może narazić Linux na niebezpieczeństwo, w przypadku jego zakładanej popularności, to będą luki w zamkniętym oprogramowaniu, które zacznie być dla niego tworzone przez firmy produkujące obecnie dla Windows. Czy to świadczy o wadliwości Open Source? Nie sądzę! Te dwa środowiska programistów nadal są w tym przypadku dla siebie konkurencją, pomimo istnienia ich produktów na tej samej platformie.

Druga sprawa to serwery oparte na Linuksie, które w obecnej chwili powinny być bardzo łakomym kąskiem dla hakerów. Myślę, że zgromadzone na nich dane są obecnie bardziej wartościowe niż desktopy "przeciętnego użytkownika". Zwłaszcza w obliczu umieszczania coraz to większych informacji w chmurze. W tym przypadku linuksowa popularność bije na głowę inne platformy. Pojawia się więc pytanie: Dlaczego to nadal nie jest atrakcja, aby złamać Linuksa?

A jak chronią nas otwarte źródła?

System kontroli wersji.

Jest to "oprogramowanie służące do śledzenia zmian głównie w kodzie źródłowym oraz pomocy programistom w łączeniu zmian dokonanych przez wiele osób w różnych momentach." [wikipedia] System taki umożliwia prezentację kodu w sieci i ewentualną współpracę nad nim wielu osób na bazie przyjętych zasad. Pozwolę tu się posłużyć przykładem Git, czyli systemu stworzonego przez Linusa Tordvaldsa. Jest to system rozproszony. Każdy więc może pobrać kod źródłowy zmodyfikować go w jednej z gałęzi (powstaje wtedy fork podstawowego projektu) i dopiero po akceptacji ze strony właściciela gałęzi Master taka modyfikacja może trafi do projektu

Takie postawienie sprawy już na wczesnym etapie uniemożliwia wprowadzenie szkodliwego kodu, tym bardziej, że wszystkie gałęzie Gita są otwarte, więc ktoś może zauważyć szkodliwy kod jeszcze zanim zostanie on zaproponowany do linii Master, czyli jeszcze na etapie jego tworzenia. W zasadzie taki kod może wprowadzić tylko osoba zarządzająca linią Master i najlepiej, żeby nikt nie zainteresował się tym projektem, bo może wykryć niecne plany twórcy.

Paranoidalny jest więc fakt, że w środowisku, gdzie tysiące oczu patrzy na twój kod, nie można sobie pozwolić na promocję takiego szkodliwego kodu, bo a nuż ktoś się nim zainteresuje choćby po to, aby zamieścić go w swoim projekcie. Sprawia to także, że taki kod ma wątpliwe szanse na trafienie do komputera jakiegokolwiek użytkownika i potwierdza moją teorię o nieopłacalności podrabiania otwartych źródeł tym bardziej, że po drodze są jeszcze...

Repozytoria

Repozytorium to rodzaj archiwum, gdzie przechowywane są spakowane źródła, a których instalacja odbywa się zazwyczaj za pośrednictwem menedżera pakietów. Tylko czy taki sposób dystrybucji programów w jakikolwiek chroni nas przed dostaniem się nieszkodliwego kodu? Nie zawsze, niekiedy zdarzają się włamania na serwery przechowujące repozytoria i fałszowanie plików. Duży tu udział ma czynnik ludzki, czyli np. słabe hasło do serwera. W praktyce jednak nadal nie jest to ani skuteczne, ani opłacalne, a oszustwa można łatwo wykryć.

Każdy pakiet posiada indywidualny klucz cyfrowy, tworzony na bazie zawartości tego pakietu. Nie jest możliwe podrobienie takiego klucza, bez posiadania superkomputera (nawet wtedy są małe szanse). Każdy podrobiny pakiet, który wstawimy do repozytorium, będzie musiał być już innym kluczem, bo posiada inną zawartość. Prostą sprawą jest po prostu sprawdzenie co jakiś czas kluczy pakietów przez właściciela repozytorium.

Najważniejsza jest jednak sama idea repozytoriów, a zwłaszcza idea wielu dystrybucji. Oczywiście zakładamy, ze udało nam się stworzyć szkodliwy program dla Linuksa i chcemy go rozpowszechnić. Musimy więc poprosić (wypromować program) osobę odpowiedzialną w danej dystrybucji za tworzenie paczek. Ponieważ ta osoba nie wstawia stworzonego przez nas pakietu, tylko robi własny pakiet na bazie kodu źródłowego, czyli ma do niego wgląd i może wykryć nasze oszustwo. No chyba, że trafimy na kompletnego ignoranta, lub znajdziemy sobie wspólnika w przestępstwie. Pamiętajmy także, że w repozytorium znajdują się także źródła, z których dany pakiet jest zrobiony. Często zawierają one poprawki, których nie ma w oficjalnym wydaniu, a które trafią do niego w następnym. Osoby znające się na pisaniu kodu mogą więc go cały czas przeglądać niezależnie od paczkującego, a nawet sprawdzić, czy za pomocą tych źródeł otrzymamy taki sam pakiet.

Oczywiście nawet w takim przypadku pozostają jeszcze paczkujący dla innych dystrybucji, co potwierdza tylko, że taka różnorodność nie jest szkodliwa dla rozwoju Linuksa, a wręcz inne dystrybucje pomagają dbać o swoje bezpieczeństwo nawzajem. Jako fan wolności oprogramowania muszę więc protestować, gdy ktoś sugeruje, że otwieranie źródeł dopiero podczas premiery jest bezpieczne dla użytkowników (nie mówiąc o stabilności takiego oprogramowania), dla mnie to zamach na jeden z ważnych etapów kontroli bezpieczeństwa. Przejdźmy jednak do premiery dystrybucji.

System

Oczywiście okres testowy to ważny etap w produkcji systemu. W tym momencie wiemy już miej więcej co ma trafić do finalnego wydania, więc można ograniczyć testy do konkretnego oprogramowania i nie tylko wykryć więcej błędów, jak i niebezpieczeństw jakie może czyhać z różnych stron. Dla mnie idea "system dla początkujących", oznaczająca tyle co "system nie dla zaawansowanych", skutecznie ogranicza liczbę osób, które mają wiedzę, aby na tym etapie naprawiać źródła. To oczywiście moja osobista wycieczka w stronę wiadomo jakiej dystrybucji, ignorującej bezpieczeństwo na tym etapie produkcji, poprzez nie publikowanie źródeł w odpowiednim czasie.

Ale wracając do systemu. System także zawiera środki przeciwdziałające niebezpieczeństwu. Jednym z takich przykładów (wielu) jest np. AppArmor, który obecnie jest modułem bezpieczeństwa jądra. AppArmor pozwala administratorowi systemu na stworzenie profilu bezpieczeństwa dla danego programu. Oznacza to, że możemy ograniczyć programowi korzystanie z sieci (skoro z niej nie korzysta) i w ten sposób unikniemy wycieku informacji z niego do internetu. Oczywiście jest to bardziej złożone w praktyce i zazwyczaj korzystamy z profili przygotowanych przez dystrybutora, które są zazwyczaj skuteczne. W każdym razie AppArmor nie pozwoli, aby jakiś szkodliwy kod wykorzystał inną aplikację w sposób do którego nie została przeznaczona. Taki szkodliwy kod nie będzie też potrafił obejść zabezpieczeń stosowanych przez ten program (np. pominąć hasło, którego wykonanie jest przypisane tylko uzytkownikowi).

Moim skromnym zdaniem

Jak napisałem powyżej nie miałem zamiaru udowadniać, że system bezpieczeństwa Linuksa jest w 100% sprawny. Na każdym etapie znajdują się możliwości ataku. są one jednak łatwo tłumiony, albo przez mechanizmy własnej kontroli, albo na następnym etapie dystrybucji, który nie jest łatwo pominąć. Dotarcie do finalnego użytkownika może być więc nie tyle nieskuteczne, co nie opłacalne z punktu widzenia popularyzacji szkodliwego kodu.

Niektórzy zapewne uznają ten artykuł za atak na Windows. Osobiście nie miałem takiego zamiaru (patrz: Wstęp). Nie mam tu zamiaru leczyć kogoś z paranoi, że opisywanie zalet jakiegoś programu to atak na inny rodzaj oprogramowania. Po prostu lepiej niech ktoś napisze, że taki program jest chroniony skuteczniej i użytkownik ma większą kontrolę dzięki temu nad własnym bezpieczeństwem.

Na zakończenie refleksja

Zastanawiam się dlaczego Linux nie pokazuje się na zawodach Pwn2Own? Albo po prostu nikt o nim nie mówi (pomijam tu Androida i Chromebooki). W każdym razie po spektakularnym sukcesie w 2008r. Ubuntu 7.10 jakoś niespecjalnie słychać o jego uczestnictwie na tych spotkaniach. 

linux internet

Komentarze

0 nowych
  #2 26.06.2013 22:55

Quest-88 patrzcie jaki się znalazł ;)

GregKoval   8 #3 26.06.2013 23:17

@Quest-88

Znalazłem dość sporo modyfikacji tego obrazka więc uznałem, że jest stworzony na jakiejś liberalnej licencji. Jeśli masz jakiś inne informacje to proszę o kontakt.

  #4 26.06.2013 23:43

Bardzo ciekawy wpis. Ciekawi mnie jakby wyglądała próba ataku na Debiana, skonfigurowanego przez doświadczonego użytkownika.

Quest-88   15 #5 27.06.2013 01:19

A więc sądzisz, że coś jest na liberalnej licencji, bo ma wiele modyfikacji? Naiwne myślenie. Pytałem, bo sam bym chętnie skorzystał z tego obrazka. Wrzuciłem go do TinEYE i pierwszy wynik to... sklep.

http://www.istockphoto.com/stock-photo-12421954-lock-background.php

GregKoval   8 #6 27.06.2013 02:24

Dla pewności zmieniłem obraz na bardziej neutralny :) Staram się nie przywiązywać do takich rzeczy sprawy to dla mnie tylko ozdobniki tekstu.

Autor edytował komentarz.
tfl   8 #7 27.06.2013 08:21

To, ze fani windowsow uwazaja za niebezpieczenstwo otwarte zrodla (dlatego, bo kazdy moze do nich zajrzec) jest tak samo niedorzeczne, ja to, ze fani linuxow uwazaja za bezpieczne otwarte zrodla (dlatego, bo kazdy moze do nich zajrzec).

Co do samego wpisu... ten fragment o gicie jest nieco... delikatnie mowiac... na wyrost. Przy pomocy systemow kontroli wersji powstaja wszystkie projekty, wieksze od kury. Nie tylko o otwartych zrodlach.

Loombago   8 #8 27.06.2013 08:24

GregKoval a dla kogoś strata kasy ;).

command-dos   17 #9 27.06.2013 08:26

w kilku słowach: http://pl.wikipedia.org/wiki/Security_through_obscurity - przykładem, który potwierdza że bezpieczeństwo nie zależy od otwartości, jest TrueCrypt. Każdy zna budowę i zasadę działania programu, ale mimo tego zaszyfrowane nim dane są bezpieczne i bez klucza ani rusz: http://pl.wikipedia.org/wiki/TrueCrypt

IMHO otwartość kodu świadczy o braku rzeczy do ukrycia - mam tu głównie jakieś bacdoor'y na myśli, nie mówiąc o zwykłym niechlujstwie, albo ukrywania faktu wykorzystania cudzego kodu...

GregKoval   8 #10 27.06.2013 09:59

@tfl
>>"To, ze fani windowsow uwazaja za niebezpieczenstwo otwarte zrodla (dlatego, bo kazdy moze do nich zajrzec) jest tak samo niedorzeczne, ja to, ze fani linuxow uwazaja za bezpieczne otwarte zrodla (dlatego, bo kazdy moze do nich zajrzec). "

Myślę, że gdybym miał polegać tylko na zasadzie "wiele oczu patrzy" to ten art miałby tylko jeden akapit. Myślę, że opisałem pewien system narzędzie wzajemnie się kontrolujących, które nie jest 100% bezpieczny, ale daje pewne zaufanie. W przypadku zamkniętych źródeł nie mam takiej pewności, choć nie przeczę, że Windows może być bezpieczny, ale ze strony użytkownika będzie wymagał większej uwagi, ograniczeń, stosowania większej ilości zabezpieczeń itd. W Linuksie jest to więc o wiele prościej i w zasadzie nawet w przypadku większej popularności systemu nie będzie aż tak opłacalne.

tfl   8 #11 27.06.2013 10:40

@GregKoval

Niepotrzebnie wzials to tak do siebie. Raczej wyglaszalem wlasne ogolne zdanie na ten temat.

Zadna aplikacja nie staje mniej bezpieczna lub bardziej bezpieczena ze wzgledu na dostepnosc jej kodu zrodlowego. Aplikacja jest bezpieczna jesli jest dobrze napisana. Okolicznik ten nie jest uzalezniony od dostepnosci do kodu, tylko od developerow, testerow itd.

Wplyw udostepnienia kodu na bezpieczenstwo jest porownywalny do wplywu na jego niebezpieczenstwo. Wszystko ma swoje wady i zalety, a umiejetnosc wyznaczenia odpowiedniego balansu jest droga do sukcesu (czyli w tym przypadku - bezpieczenstwa)

  #12 27.06.2013 10:51

Mi się zawsze wydawało, że więcej jest ludzi wierzących w mit całkowicie bezpiecznych projektów open source... A przecież nawet i tam zdarzają się backdoory i dziury nie łatane od lat - co jest szczególnym ewenementem - w końcu jeśli tyle osób ma dostęp do kodu źródłowego, to jak to możliwe, że nawet w Linuxie były dziury związane z bezpieczeństwem nie łatane przez kilka lat.
Zresztą jeśli użytkownik jest niezbyt mądry to żadne zabezpieczenia nie pomogą, a takie mity o bezpieczeństwie danych systemów "bo coś tam" tylko powodują takie wpadki jak to było np. z Mac OS X i fałszywymi antywirusami - ludzie tak uwierzyli w to, że system jest bezpieczny, że całkowicie olali podstawowe zasady bezpieczeństwa.
Mało tego dość mocno na bezpieczeństwo wpływa popularność danego produktu - jeśli coś jest popularne to opłaca się kombinować i próbować to złamać, a wtedy otwarty kod źródłowy może się okazać nawet minusem (łatwiej znaleźć błąd przez crackera - a przecież informacji o błędzie udostępniać nie musi, ale wykorzystać w "złym celu" może).

  #13 27.06.2013 10:51

Mi się zawsze wydawało, że więcej jest ludzi wierzących w mit całkowicie bezpiecznych projektów open source... A przecież nawet i tam zdarzają się backdoory i dziury nie łatane od lat - co jest szczególnym ewenementem - w końcu jeśli tyle osób ma dostęp do kodu źródłowego, to jak to możliwe, że nawet w Linuxie były dziury związane z bezpieczeństwem nie łatane przez kilka lat.
Zresztą jeśli użytkownik jest niezbyt mądry to żadne zabezpieczenia nie pomogą, a takie mity o bezpieczeństwie danych systemów "bo coś tam" tylko powodują takie wpadki jak to było np. z Mac OS X i fałszywymi antywirusami - ludzie tak uwierzyli w to, że system jest bezpieczny, że całkowicie olali podstawowe zasady bezpieczeństwa.
Mało tego dość mocno na bezpieczeństwo wpływa popularność danego produktu - jeśli coś jest popularne to opłaca się kombinować i próbować to złamać, a wtedy otwarty kod źródłowy może się okazać nawet minusem (łatwiej znaleźć błąd przez crackera - a przecież informacji o błędzie udostępniać nie musi, ale wykorzystać w "złym celu" może).

GregKoval   8 #14 27.06.2013 12:05

@tfl

Tu opisuję nie tylko zasadę otwartego źródła jako podstawę bezpieczeństwa, ale raczej system wzajemnie się kontrolujących narzędzi, gdzie otwartość jest tylko jednym z elementów, ale także takim, który pozwala na zastosowanie innych skutecznych zabezpieczeń.

@pusiak

Zdaję sobie sprawę, że nikt nie jest bezpieczny i nawet zamknięty za betonowymi drzwiami mogę być w nich zalany ulewą z góry. Co innego jest jednak wykrycie luki, a co innego wprowadzenie do systemu kodu wykorzystującego tę lukę. To tak jak z tymi wirusami na Linuksa - tak są, tak działają, tylko najpierw musisz je sobie sam skompilować. Na szczęście dostałem zestaw narzędzi, który pozwala mi się czuć bezpiecznie nawet pomimo istnienia luki w systemie, bo program ją wykorzystujący musiałby przejść przez wiele etapów wersyfikujących jego działanie, aby skutecznie do mnie trafić.

kwpolska   5 #15 27.06.2013 12:34

> Każdy więc może pobrać kod źródłowy zmodyfikować go w jednej z gałęzi (powstaje wtedy fork podstawowego projektu) i dopiero po akceptacji ze strony właściciela gałęzi Master taka modyfikacja może trafi do projektu

niekoniecznie, można modyfikować na gąłęzi master, a żeby nasz kod znalazł się w projekcie osoba z dostępem rw do repozytorium musi zmerge’ować nasz kod z ich w gałęzi master.

sgj   10 #16 27.06.2013 12:46

@Anonim "Mi się zawsze wydawało, że więcej jest ludzi wierzących w mit całkowicie bezpiecznych projektów open source... A przecież nawet i tam zdarzają się backdoory i dziury nie łatane od lat - co jest szczególnym ewenementem - w końcu jeśli tyle osób ma dostęp do kodu źródłowego, to jak to możliwe, że nawet w Linuxie były dziury związane z bezpieczeństwem nie łatane przez kilka lat. "


Bo jest taki mit że jak źródła są otwarte to zaraz ktoś wyłapie każdy błąd. Problem tylko jeśli projekt ma kod liczony w milionach linii...

dhor   8 #17 27.06.2013 12:50

Artykuł bardzo na czasie, na kanwie ostatnich wydarzeń z podsłuchami w produktach od MS, Google, Facebook... Różnica pomiędzy softem o zamkniętym kodzie, a softem otwartym jest taka, że w przypadku zamkniętego o tym, że jesteśmy podsłuchiwani, dowiadujemy się z TV. Przy otwartym kodzie o backdoorze, podsłuchu, czymkolwiek internet huczy już na drugi dzień po umieszczeniu programu w repozytoriach.

  #18 27.06.2013 13:08

dhor: Dobrze prawisz, newsów o lukach w Linuksie jest zaskakująco dużo. Często to daje pożywkę trollom hejtującym Linuksa i/lub otwarte oprogramowanie. A to że w windowsie jesteśmy nieświadomi potencjalnych luk i ubytków to inna sprawa. :>

bastardo   2 #19 27.06.2013 16:56

Całe to zamieszanie wynika z prostego faktu:
Zgodnie z nową świecką tradycją, najwięcej do powiedzenia mają osoby najmniej kompetentne w danym temacie.

Ostatnio to nawet panuje taka moda na bycie idiotą, więc teraz można się częściej spotkać z coraz ”ciekawszymi" tezami.

Frankfurterium   9 #20 27.06.2013 20:23

IMO trochę zbyt wielką wiarę pokładasz w paczkujących. Jeżeli nie wykryją złośliwego kodu, to są ignorantami? Nie wymagajmy, żeby paczkujący mieli widzę aktywnych developerów pakowanych projektów. Śmiem twierdzić, że w ogóle niewielki procent osobników wrzucających pakiety do repozytoriów posiada kompetencje do patrzenia na kod (ze zrozumieniem), a niewielki procent tego niewielkiego procenta przegląda wszystkie zmiany w poszczególnych wersjach.

G.Gn7Ex   5 #21 27.06.2013 22:22

Jeśli w otwartym oprogramowaniu pojawi się błąd/luka/złośliwy kod itp - to zawsze istnieje możliwość poprawienia błędu, usunięcia złośliwego kodu, itp. niezależnie od tego, czy oficjalny autor/producent rozwija/wspiera czy nie.

W przypadku zamkniętego oprogramowania - jedyną rzeczą jaką użytkownik może zrobić to zdać się na łaskę producenta, inaczej zaś - zrezygnować z tego programu.

GregKoval   8 #22 28.06.2013 00:04

@Frankfurterium

Czy ja wiem czy wymagam aż tyle od paczkujących, albo w późniejszym etapie testerów wersji Beta? Podkreślam tylko w tym miejscu wartości wynikające z istnienia dużej ilości dystrybucji i ich forków, która w pewnym sensie bardziej gwarantuje pojawienie się większej liczby takich bardziej kumatych osób mogących wyłapać błędy, niż w jednej zunitaryzowanej dystrybucji. Ważny jest także motyw edukacyjny nauczania kompilacji, który często właśnie z funkcji paczkującego pcha osobę w dalsze rejony zainteresowania się kodem. No i oczywisty fakt współpracy paczkujących z deweloperami i paczkującymi innych dystrybucji, który sprzyja szerzeniu informacji o wykrytych zagrożeniach. W takim przypadku jest to bardziej wydajny sposób kontroli źródeł niż jedna czy dwie osoby przygotowujące instalkę programu zamkniętego.

M@ster   16 #23 28.06.2013 01:02

Tak co do bezpieczeństwa, przeglądasz kod każdego programu który ściągasz? Nie? To w zasadzie w tej kwestii jest to dla Ciebie jak "closed source" - bo opierasz się na zaufaniu do tych którzy kod nadzorują. W dodatku są oni bardziej narażeni na sytuację w której coś przeoczą bo jako że coś jest open source to każdy może zaproponować zmianę i coś przemycić.

Oczywiście jeśli mamy do czynienia z jakimś mikro programem stworzonym przez kogoś mało znanego to ma to sens bo jesteśmy w stanie ogarnąć kod sami.

Nie jestem jakimś zwolennikiem/przeciwnikiem open/closed source, ale zawsze mnie bawi jak ktoś mówi że kod bezpieczny bo każdy może go zweryfikować - to weryfikuj sobie kod pingwina, powiedz kiedy skończysz ;)))

Autor edytował komentarz.
emig   4 #24 28.06.2013 02:46

@M@ster

Oprogramowanie jest takim samym towarem jak nie przymierzając kiełbasa.

Zgodnie z przepisami każdy producent kiełbasy winien przedstawić skład produkowanego wyrobu.
Uczciwy producent poinformuje Cię, że zakupiona przez ciebie kiełbasa zawiera 20% mięsa zidentyfikowanego gatunku i inne dziwności które czynią ja tak "smaczną i pożywną".
Nieuczciwy producent napisze na etykietce co mu się żywnie podoba a do środka wsadzi zdechłą świnie , kota , konia , pulpę drzewną i sól z ulicy.

Po czyjej stoisz stronie ? Producenta czy konsumenta ? Ważniejsza jest dla Ciebie "wolność gospodarcza" czy twoje zdrowie ? Nie uważasz, że poczynania producentów kiełbasy winny być jakoś kontrolowane ?

Całkiem duża grupa ludzi metodą prób i błędów poszukuje luk bezpieczeństwa w produktach firm komercyjnych (o ukrytym kodzie) i znajduje je, co jest zadaniem równie skomplikowanym jak laboratoryjna analiza żywności.

Jednakże, w przypadku oprogramowania mamy do czynienia z unikalną okazją kiedy proces analizy produktu może być bardzo uproszczony i przyśpieszony jeśli mamy do wglądu kod źródłowy. (Tak jakby w fabryczce kiełbasy umieścilibyśmy nieprzekupnego inspektora sprawdzającego uważnie ,co i kiedy do kiełbaski jest dodawane. Jako konsument w/w kiełbasy każdy z nas byłby bardzo zadowolony gdyby taka sytuacja miała miejsce , prawda ? )

A chętnych do przeszukania kodu w oprogramowaniu jest całkiem dużo i z wiedzą na dodatek (jeśli znajdują exploity bez znajomości kodu to mając kod do wglądu to już "bułka" z masłem ;-)). Zarówno entuzjaści jaki organizacje "non profit"
W takiej sytuacji producent oprogramowania 5 razy by się zastanowił czy wsadzić do programu "ukryte funkcje" aby nie dostać "złej prasy" czy pozwu do sądu. I mówię tutaj o "uczciwych" producentach.

Czy w takim przypadku nie sądzisz jednak, że możliwość wglądu w źródła oprogramowania przynosi jakąś korzyść ?

Autor edytował komentarz.
GregKoval   8 #25 28.06.2013 03:19

@M@ster

Uzupełniając tylko wypowiedź @emiga, pragnę dodać, że na całej linii dystrybucji takiego oprogramowania stoi dość pokaźna grupa ludzi, którzy w zasadzie nie mają żadnych wspólnych interesów z twórcą programu, aby taki fakt ukrywać. Dodatkowo sami są często użytkownikami podobnego zestawu oprogramowania co i ja, więc to nie zysk na mnie jest ich interesem tylko fakt, żeby nikt im nie spieprzył systemu. Ty akurat atakujesz ostatni etap dystrybucji tak jakby ten szkodliwy kod miał jakiekolwiek szanse w ogóle trafić do początkującego użytkownika z pominięciem całej masy programistów stojących na jego drodze i przygotowujących system.

Tak nie wykluczam tego w 100% ale na pewno uważam, że taka gra warta jest ryzyka i kompromitacji. Więc na pewno w takim przypadku nie postawie znaku równości w twierdzeniu, że otwarcie kodu tak samo naraża go na niebezpieczeństwo jak chroni przed nim.

command-dos   17 #26 28.06.2013 05:59

@emig - lepszego porównania nie potrafiłbym wymyślić :) brawo, tak obrazowo i dobitnie to pokazałeś, że sprawę zakuma, że tak powiem, zwykły zjadacz chleba - mistrzostwo.

M@ster   16 #27 28.06.2013 07:48

@emig
Producent żywności nie może sobie pisać co chce bo jest to prawnie ustalone. W przypadku softu nie ma tego typu regulacji. Także to porównanie mimo że fajne to nieco naciągane. Nie mniej rozumiem co chciałem przekazać. Tak jak mówiłem, nie twierdzę że to źle że kod jest otwarty, tylko śmieszą mnie Ci którzy jako główny wyznacznik bezpieczeństwa uważają otwartość kodu pod argumentem "że każdy może go sobie przejrzeć" podczas gdy sami tego nie robią a opierają się na innych. Posługując się analogią do żywności, to tak jakby ktoś Ci mówił że te parówki są dobre bo Kondrad je reklamuje podczas gdy skład masz wypisany na na opakowaniu :)

GregKoval   8 #28 28.06.2013 12:23

>>"W przypadku softu nie ma tego typu regulacji. "

Są! Jest to licencja, która wymusza na deweloperze dostarczenie działającego softu, a w przypadku wadliwego działania - poprawek. Dotyczy to też przekroczenia warunków bezpiecznego używania programu.

>>" Ci którzy jako główny wyznacznik bezpieczeństwa uważają otwartość kodu"

Nigdzie tego nie napisałem. Cały artykuł opisuje za to bardzo złożony mechanizm bezpieczeństwa, którego funkcjonowanie nie byłoby możliwe bez otwarcia kodu. Ty za to z uporem maniaka opisujesz tylko jego ostatni etap, jakby taki wadliwy program miał szansę tam w ogóle trafić. Nigdzie nie zaprzeczam, że to możliwe, że coś przejdzie sito selekcji, tylko że jest tak mała szansa, że dla producenta wirusów, czy innego badziewia się nie opłaca.

emig   4 #29 29.06.2013 02:47

@M@ster

..Producent żywności nie może sobie pisać co chce bo jest to prawnie ustalone..

Tak w "idealnym świecie w bardzo , bardzo odległej galaktyce na planecie X" - Gazet (Portali informacyjnych) nie czytasz ?.

Znalazłeś w markecie kiełbaskę o składzie : padło wieprzowo-wołowe z solą drogową techniczną ?
A takie kiełbaski znaleziono mimo troszkę innej deklaracji producenta na etykietce ;-)
Ewidentnie producent był nieuczciwy i prokuratura go ściga.

Kupując dowolny program jesteś jakoś informowany o funkcjach tego programu ?
(Jeśli twierdzisz że nie, na jakiej podstawie dokonujesz więc wyboru ?)
Czy w reklamie, opisie technicznym programów producentów zamieszanych w PRISM pojawiła się informacja o współdzieleniu Twoich prywatnych zasobów z NSA , czy kto tam poprosił lub zapłacił ?

A jednak , ktoś sypnął i okazało się, że ścierwo w produkcie "uczciwych producentów" się znalazło - znaczy się dla mnie "uczciwymi producentami" już nie są. (bez względu na pobudki ani wyroki jakichś amerykańskich "sądów kapturowych" )

Idąc dalej, mając do czynienia z "zamkniętym oprogramowaniem" które pod płaszczykiem "tajemnicy handlowej" ukrywa mniejsze lub większe świństwa (znowu analogia kiełbasiana) - zaczynam jednak
preferować oprogramowanie "open" w którym jak historia pokazuję ukrycie czegokolwiek jest dużo trudniejsze (patrz historyjka o rzekomych backdorach w BSD - sprawdzili (audyt), nie ma). Swoją drogą to ciekawe, który z gigantów "uczciwego oprogramowania" tego FUD-a sponsorował ;-) . Jak przekonasz mnie, że w produktach komercyjnych firm nie ma jeszcze gorszych świństw jeśli TECHNICZNIE taki audyt jest niemożliwy ? Właśnie z powodu zamkniętego kodu ?

Autor edytował komentarz.
emig   4 #30 29.06.2013 03:03

@M@ster

Gwoli uzupełnienia nie jestem fanatyczny ekstremistą "otwartości" w stylu Stallmana (aczkolwiek niektóre z jego esejów są moim zdaniem całkiem rozsądne) i nie oczekuję "otwarcia kodów wszystkiego i wszędzie".

Jednakże jako "konsument" oprogramowania mile bym widział instytucję w stylu Urzędu Ochrony Konsumentów które w przypadku wątpliwości co do uczciwości producenta oprogramowania miała by wgląd w jego kody. Jak na razie jest to chyba jedyny rynek gdzie producent jest niemal całkowicie bezkarny.

kriters64   7 #31 01.07.2013 10:10

Analogia do tego wpisu jest taka, załóżmy że wrzucam tutaj i teraz dla was komentujących dwa programy, jeden otwarty i drugi zamknięty, do sprawdzenia pod względem zawartego w nim złośliwego kodu, i co się dzieje? w przypadku zamkniętego nic się nie dzieje po za wróżeniem z fusów że producent jest uczciwy lub nie, ale w przypadku tego otwartego to już inna sprawa, bo wyobrażam sobie, że z taką samą pasją jak komentowanie za i przeciw, będziecie szukać i udowadniać sobie że wszystko jest w porządku lub nie do ostatniej linijki kodu i to pod lupą:) a to może wyjść programowi tylko na dobre, choć będzie to trwało dłużej.
Ale najciekawsze będzie to, że dwie zdawało by się przeciwne strony, zaczną z sobą współpracować by wykonać powierzone zadanie oceny bezpieczeństwa programu:)

matrix012345   4 #33 03.07.2013 12:14

Cały czas dyskutujecie tylko na temat możliwości wstawienia backdoora, ale jest jeszcze kwestia bugów, czyli błędów popełnionych nieumyślnie. Jeśli bug trafi do gotowej wersji programu, i zostanie z nią zainstalowany na komputerze użytkownika, to dopóki nie zostanie wykryty przez hakera jest niegroźny. W OpenSource łatwiej bugi wykryć ludziom, którzy chcą je naprawić, ale też łatwiej wykryć tym, którzy mają złe zamiary. W zamkniętym oprogramowaniu trudniej wykryć lukę jednym i drugim, więc luki te może nie zostaną tak szybko załatane, ale nie stanowią aż tak wielkiego zagrożenia.

GregKoval   8 #34 03.07.2013 14:31

@kriters64

To nie zupełnie tak. Podajesz przykład, który w świecie Open Sourse jest dość rzadki tzn. bezpośrednie dostarczenie towaru klientowi. Jak widać po ostatnich działaniach Canonical taka sytuacja jest jednak ostro krytykowana przez deweloperów Open Source. Jeśli chcą oni wziąć odpowiedzialność za otwarty kod to musi być do niego dostęp (nieograniczany) już na etapie deweloperskim, który pozwoliłby innym deweloperom bez przeszkód dołączyć do pracy nad danym kodem, lub wykorzystać go w innych projektach. Jesli patrzysz więc przez pryzmat bezpieczeństwa otwartych źródeł to najpierw patrzysz ilu niezależnych (nie z jednej firmy) deweloperów nad nim pracuje, bo wtedy masz pewność, że taka kontrola będzie się jeszcze bardziej wzmacniać dzięki różnorodności dystrybucji zainteresowanych programem. Nie można więc zauważyć, że użytkownicy faworyzują oprogramowanie związane ze środowiskami graficznymi, gdyż może ono już na początkowym etapie zainteresować pewną grupę deweloperów.

@matrix012345

Mylisz się. W rzeczywistości zamknięcie źródeł nie oznacza zamknięcia fizycznego dostępu do źródeł, tylko ochronę praw autorskich. W rzeczywistości nie jest trudno uzyskać dostęp do kodu źródłowego zamkniętego programu dzięki inżynierii wstecznej. Korzystają z tego m.in. twórcy cracków do gier, którzy kastrują kod źródłowy z zabezpieczeń i na nowo kompilują plik exe. Oczywiście to nielegalna operacja zważywszy na licencję programu i w efekcie osoba, która chce przejrzeć kod w celu znalezienia błędów robi to nielegalnie, co zapewne zniechęca wiele osób (był to jeden z powodów stworzenia Wolnego Oprogramowania przez Stallmana).

W przypadku Open Source łatwiej więc wykryć lukę, bo deweloperom bardziej się to opłaca, choćby z powodu uzyskania prawa dysponowania kodem i uczestnictwa w ruchu ludzi, którzy mają podobny cel do nich. W tym przypadku także ciężko o osoby szkodzące, bo im się to nie opłaca zważywszy na łatwość wykrycia szkodliwego kodu i fakt, że deweloper takiego kodu musi brać udział w dystrybucji takiego oprogramowania, aby trafiło ono do jak najszerszego grona odbiorców. W przypadku zamkniętych źródeł jest to o wiele łatwiejsze zważywszy na to, że najczęściej atakowi ulegają programy najlepiej rozreklamowane np. gry, bo deweloper trojana ma dzięki temu większe szanse znalezienia naiwnych.

Ale wracając do błędów, o których wspomniałeś. W przypadku zamkniętych źródeł sytuacja ma się tak. Tworzony jest program, który po przejściu testów zostaje poprawiony i wydany. Następne dwa etapy w przypadku Open Source zostają pominięte, bo ani paczkujący, ani dystrybutor (sprzedawca) nie maja uprawnień do kontroli jakości. Następnym etapem jest więc już tylko użytkownik, który musi mieć interes, aby program poprawić. Nie muszę mówić, że sporo osób na tym etapie przesyłających błędy dla tego typu oprogramowania to zwolennicy open source, którzy zawodowo chcą wiedzieć jak program działa ewentualnie utrzeć nosa Wielkiej Korporacji. Tylko jaki w tym interes ma użytkownik, któremu rzuca się już na wstępie kłody pod nogi w postaci restrykcyjnych licencji i utrudnianiu dostępu do źródeł?

I wracając do bezpieczeństwa - wspomniane przeze mnie pominięcie dwóch etapów produkcji, czyli paczkowania i dystrybucji, przez testerów wcale nie ogranicza w tym przypadku osób, którzy chcą zaszkodzić. Nadal mają oni dostęp do kodu, co umożliwia im nielegalną dystrybucję spreparowanego kodu. Wiele firm ogranicza tę wadę stosując zasadę "zaufanych źródeł", problem w tym, że nie jest to scentralizowane i nie przyzwyczaja użytkowników do korzystania tylko z jednego pewnego źródła i nadal mają oni tendencję ściągania z całej sieci.

wojtex   9 #35 09.07.2013 16:22

"W rzeczywistości nie jest trudno uzyskać dostęp do kodu źródłowego zamkniętego programu dzięki inżynierii wstecznej. Korzystają z tego m.in. twórcy cracków do gier, którzy kastrują kod źródłowy z zabezpieczeń i na nowo kompilują plik exe."

Taka dekompilacja do kodu źródłowego jest możliwa, ale tylko w przypadku takich języków jak C#, Java... W większości przypadków crackerzy manipulują instrukcjami ASM-a, bo to jest jedyne wyjście.