W rzeczywistości wszystkie systemy operacyjne mają swoje wady, które hakerzy będą próbować wykorzystać. Dotyczy to także systemów Linux i MAC, uznawanych przez większość za bezpieczniejsze – twierdzi specjalista ds. bezpieczeństwa w Kaspersky Lab.
David Jacoby, starszy specjalista ds. bezpieczeństwa w Kaspersky Lab zadaje kłam twierdzeniom o zwiększonym poziomie bezpieczeństwa systemów Linux i MAC OS – Uprzedzenia, że niektóre systemy operacyjne są bezpieczniejsze niż inne są błędne – twierdzi. “Nie ma znaczenia czego używamy, zagrożeni jesteśmy wszyscy” – tym hasłem poczęstował uczestników konferencji prasowej w Monachium.
“Nie ma czegoś takiego jak bezpieczny system operacyjny”
Jacoby szczególnie przyjrzał się aspektom bezpieczeństwa w Linuksie. Jedną z istotnych kwestii, jak twierdził, jest błędne założenie o ultra-bezpieczeństwie tego systemu i pozostawienie go samemu sobie (bez update-ów i upgradów). Jacoby nie przedstawił konkretnych zarzutów pod adresem Linuxa, skupił się za to na często opisywanym przez firmę Kaspersky ataku “drive-by download”.
Pozostała część wystąpienia skupiła się przede wszystkim na zaprezentowaniu najlepszego jego zdaniem remedium na wszystkie security-bolączki jakim są produkty wiadomej firmy.
Żródło: itnews.com.au
Atak “drive-by download” w skrócie polega na zakażeniu webaplikacji złośliwym kodem powodującym nieświadome i nipotwierdzone ściągnięcie złośliwego kodu (expolita) przez użytkownika odwiedzającego stronę . Około 80% światowych serwerów www (http) działa pod kontrolą systemów unixo-podobnych więc statystycznie to właśnie one padają najczęściej ofiarą tego typy ataków. Retoryka podobna do stwierdzenia, że najczęstszą przyczyną utonięć jest woda…
1) To jest news? Chyba z blogiem ci się pomyliło.
2) Ataki na aplikacje webowe to nie atak na system operacyjny, na którym serwer webowy działa.
Jest 80% uniksowych systemów, bo jako systemy są znacznie bezpieczniejsze.
A jak ktoś już zrobi kod portalu, to już inna sprawa. To, że ktoś napisał kod strony www podatny na np. sql-injection nie oznacza kompromitacji systemu operacyjnego, a raczej kompromitację programisty.
3) Jest coś takiego jak bezpieczny system operacyjny.
Jest to system przemyślany, dobrze zaprojektowany i nastawiony na bezpieczeństwo. Takie właśnie są systemy oparte na unixie jak BSD czy Linux.
Takie podejście jest zupełnie inne niż w microsofcie, gdzie windows powstał na szybko i cały czas ciągnie za sobą ogon błędów projektowych, i w którym wygoda użytkowania wymaga kompromisu dla bezpieczeństwa, z czym zresztą microsoft się nie kryje (choć i się nie rozgłasza, bo to dość kompromitująca informacja, szczególnie w świecie systemów serwerowych).
Dokładnie, zakopać to… :>
W przypadku uniksow bez problemu mozna wymienic kilka bledow projektowych, ktore obnizaja bezpieczenstwo – chociazby suid. Potrafisz wymienic kilka bledow projektowych w Windows?
runas vs. sudo — tej samej klasy co suid. Tyle, że to jest pierdółka. Największy błąd to linia nie-NT i zaszłości.
Well, sudo wykorzystuje suida. I pare dziur w nim bylo. Runas jest sensownie zaprojektowany, i bledow w nim sobie nie przypominam. Suid, patrzac historycznie, byl jedna z najczestszych przyczyn eksploitowalnych dziur, wiec nie, to nie jest pierdolka.
Linia nie-NT to przeszlosc. Zaszlosci jakiestam są, ale w uniksach sa wieksze.
Tak. Ustaw sobie suid, a potem narzekaj, że ty nie wiedziałeś, co robisz. SUID nie jest błędem projektowym, gdyż pozwala innym użytkownikom wykonać nasz program na naszych prawach. Gdzie tutaj widzisz obniżenie bezpieczeństwa. Nie chcesz – nie korzystaj. To tyle w temacie.
Część programów nieco nadużywa możliwości, jakie daje suid.
Ale jeśli jakiś program tak działa, to po prostu spoczywa na nim większa odpowiedzialność za jakość swojego kodu. I to tyle „wad”.
Czepianie się suida to trochę tak, jakby czepiać się kernela, że pracuje w trybie uprzywilejowanym, więc może coś namieszać. Ale taka jest po prostu jego rola i kod musi być odpowiednio bezpieczny i dobry, by nie namieszał.
Może tr*sz ma po prostu złe doświadczenia z bsd i niską jakością jego kodu, który w połączeniu z suid staje się niebezpieczny…
Na Linuksie to wszystko dobrze działa, więc nie ma się czego czepiać.
W większości dystrybucjach właściwie tylko jedna binarka ma suid – sudo. Może jeszcze su i ewentualnie op.
Ludzie! Zróbcie chociaż mały risercz zanim zaczniecie wypisywać głupoty.
Choćby głupi
pingma ustawiony SUID…PS. A główny problem SUID polega na tym, że CAŁY program łącznie ze wszystkimi bibliotekami działa na podwyższonych uprawnieniach z powodu zwykle jednej funkcji, która owych przywilejów potrzebuje. Naprawdę, można wymyślić lepsze rozwiązanie tego problemu.
To trochę jak usługi sieciowe w uniksach nie-tak-dawno-temu. Jako że porty < 1024 mógł, ze względów "bezpieczeństwa", otwierać tylko root, usługi sieciowe działały z uprawnieniami roota. Słowem, cały taki np. Apache działał jako root, tylko dlatego, żeby się zbindować do portu 80.
Ciekawostka na koniec:
przemek2@jaunty:~$ ls -l /usr/bin/pulseaudio
-rwsr-xr-x 1 root root 70844 2009-11-11 10:55 /usr/bin/pulseaudio
To tyle na temat SUID. Zrobiło się zbyt groźnie.
Ale to nie jest błąd Linuxa, który te problemy potrafi rozwiązać np. Posix capabilities. Ew. problem dystrybucji i tego jak się tego używa. Poza tym wcale nie twierdzę, że Linux nie został napisany 'na szybko byle działało’ i że nie ciągnie się za nim pewne wymogi kompatybilności wstecznej, choć pewnie w mniejszym stopniu niż za NT.
@el.pescado: Niezupelnie. Glowny problem z suidem polega na tym, ze caly program lacznie z bibliotekami wykonuje sie na podniesionych przywilejach _w srodowisku, ktorego znaczną część kontroluje proces uruchamiajacy go_. Kluczowe podkreslilem. W cyfrach wyglada to tak, ze gdzies tak (na oko) połowy dziur w uniksowatych na przestrzeni ostatnich dwoch dekad nie byloby, gdyby nie mechanizm suid.
@bla: POSIX capabilities takie, jak zaimplementowane w Linuksie, sa bezuzyteczne, bo wiekszosc z nich mozna latwo przelozyc na pelnego roota. Gdyby je zaimplementowac tak, jak w Solarisie, byloby znacznie lepiej, chociaz nie idealnie – ale nikt tego nie zrobil.
oscenzura wycięła, więc raz jeszcze:
@Sławek, @oO: douczcie się wreszczie drogie dzieciaczki, bo tylko osoby o nikłych rozumkach nie przyjmują do wiadomości faktów tłuczonych raz po raz – żeby się nie powtarzać: http://serwer22962.lh.pl/internet-explorer-9-beta-wydany/#comment-5328792
@bla: a potrafisz powiedzieć, kiedy te capabilities zostały w Linuksie poprawnie zaimplementowane, tzn. dokładniej część filesystem caps? Bo bez tego to tak jakby …nie działa, więc trzeba jasno to przyznać: powszechność SUID w Linuksie jest spowodowana BŁEDEM PROJEKTOWYM, który dopiero niedawno został skorygowany, lecz wciąż nie jest definitywnie usunięty.
@trasz: a konkretnie to jak przekłada się na pełnego roota? Masz jakiegoś linka, czy też opierasz się na archaicznej implementacji?
@gotar: Jakis czas tych capabilities nie widzialem (po co przygladac sie czemus, co przez dekade od powstania nie dzialalo?), ale ogolnie wygladalo to tak, ze majac na przyklad CAP_DAC_READ (bodajze) mozna bylo otworzyc dowolnego device’a, z oczywistym skutkiem. Calkiem dobry artykul opisujacy problem byl na blogu jednego z gosci, ktorzy implementowali to (poprawnie) w Solarisie.
Tak na marginesie – czesc filesystemowa to taki sobie ficzer. W sensie, nie zgadzam sie, ze jest niezbedna (capabilities rownie dobrze program moze zrzucac samodzielnie) i nie jestem pewien, czy jest dobrym pomyslem (o tym, ktore capabilities mozna zrzucic, wie autor, a nie admin, wiec przerzucanie tego z kodu do jakichs rozszerzonych atrybutow moze byc nie teges).
@trasz: capabilities zrzucane samodzielnie działają od dawna, więc zdecyduj się – czy część fs nie jest taka znowu zbędna, czy też 'jakiś czas’, który nie widziałeś, to jest jednak 'bardzo długi czas’ i piszesz o archaizmach.
Dobrze – mając CAP_DAC_OVERRIDE (o tym piszesz) załóżmy nawet, że masz możliwość łatwej eskalacji uprawnień przez urządzenia blokowe. A jak wykorzystasz CAP_NET_BIND_SERVICE czy CAP_KILL? A może CAP_NET_ADMIN czy CAP_NET_RAW? Ale jeśli dasz linka do tego bloga chętnie poczytam.
Co do samej części fs: to co piszesz odnosi się do narzędzi typu ping czy usług bindujących się do niskich portów, zupełnie natomiast pomija pozostałe aspekty, jak zastosowania sudo (tj. tego samego SUID-a). W jaki niby sposób nie mając części fs mogę pozwolić komukolwiek na użycie tcpdumpa czy ipset? Nadając procesowi jego shella!? To wtedy będzie miał od razu dostęp do ip czy iptables – a tego nie chcę (tak samo jak w sudo, któremu wprost się podaje listę binarek). To są programy, które w żaden sposób nigdy nie zrzucą uprawnień samodzielnie, bo ani same o nich nie wiedzą, ani autor wiedzieć nie musi – z jego punktu widzenia program wymaga roota czy tam dostępu do jakichś plików. Zatem jeśli nie w xattr, to gdzie chcesz trzymać listę uprawnień? W pliku dostępnym przez wrapper (sudo)?
Krótko mówiąc – coś mi się zdaje, że kompletnie nie rozumiesz jak to działa i do czego służy. Tu nie ma żadnego 'kodu’ do przerzucania, tutaj właśnie admin wie, na co komu chce pozwolić.
I wracając do tego CAP_DAC_OVERRIDE – jeśli założę na mcedit, który nie otwiera plików większych niż ileśtam MB, to w zupełności wystarczy, aby wszystkie moje partycje systemowe (z /etc oraz obsługujące SUID i dev) były większe. I w ten właśnie sposób dzięki części fs upadła Twoja teoria na temat błędnej implementacji – musisz zaktualizować swoją wiedzę, albo w skrócie po prostu przyjmij: część fs jest NIEZBĘDNA do prawidłowego funkcjonowania POSIX capabilities.
Chyba że się mylę i przekonasz mnie jakimś dokumentem, jak to jest zrobione lepiej w Solarisie czy BSD.
@gotar: Tak, capabilities zrzucane samodzielnie dzialaja od dawna, ale nie rozwiazuje to podstawowego problemu, jakim jest mozliwosc uzycia sporej czesci z nich do przejecia pelnego roota.
Co do kolejnych – majac mozliwosc bindowania sie do portow mozna wyludzic haslo (tak, wiem, klucz hosta albo certyfikaty, ale uzytkownicy zazwyczaj sa glupi i to ignoruja). Zauwaz jednak, ze nie napisalem, ze _wszystkie_ capabilities sa zrypane.
Co do czesci fs – wiem, o co ci chodzi, ale to pomysl tak zly, ze az boli. W ten sposob masz rozsiane po systemie plikow „cosie”, ktore podnosza uprawnienia, w sposob trudny do ogarniecia (bo rozsiany po filesystemie) i latwy do przeoczenia (suida zauwazyc nietrudno; jakis xattr – gorzej). W dodatku posypie sie to przy pierwszym lepszym upgradzie pakietu, chyba ze zaimplementujesz w managerze pakietow jakis workaround. Prawidlowo jest w druga strone – podniesienie uprawnien wymaga suida, a binarka przy starcie zrzuca sobie wszystko, co nie jest jej potrzebne.
Krotko mowiac – rozumiem, jak to dziala. To bardzo glupi pomysl.
Ogolnie – na temat problemu z eskalacja poszukaj bloga, na ktorym autor opisal capabilities w Solarisie 10. Na temat „wybiorczego suida”… Szczerze mowiac nie widzialem zadnej polemiki z tym wynalazkiem. Nie wiem, czy mialaby w ogole sens – idiotycznosc zalozen rzuca sie w oczy, a jesli sie nie rzuci, to rozpisanie sie tez nic nie da.
@trasz: no wreszcie się doczekałem na odpowiedź – no to jeszcze jeden fakt o CAP_DAC_OVERRIDE, o którym wcześniej zapomniałem: otóż gdy ostatnio go używałem, nie zezwalał mi na dostęp do urządzeń blokowych. W ten sposób padł jedyny przykład eskalacji, jaki podałeś.
„Co do kolejnych – majac mozliwosc bindowania sie do portow mozna wyludzic haslo”
No proszę… jak komuś daję dostęp do tcpdumpa to zdaję sobie sprawę, że może podsłuchać transmisję, tak samo jak możliwość pisania do /etc/shadow oznacza możliwość zmiany dowolnego hasła.
„W ten sposob masz rozsiane po systemie plikow “cosie”, ktore podnosza uprawnienia,”
A nie tak samo przypadkiem wyglądają SELinuksowe labele?
„w sposob trudny do ogarniecia”
Od tego jest package manager.
„latwy do przeoczenia (suida zauwazyc nietrudno; jakis xattr – gorzej)”
Nawet domyślnie ls dużo bardziej wyróżnia xattr niż +s.
„W dodatku posypie sie to przy pierwszym lepszym upgradzie pakietu, chyba ze zaimplementujesz w managerze pakietow jakis workaround.”
http://serwer22962.lh.pl/mandriva-sforkowana-do-mageia/#comment-5331622
http://serwer22962.lh.pl/internet-explorer-9-beta-wydany/#comment-5328812
„prawidlowo jest w druga strone – podniesienie uprawnien wymaga suida, a binarka przy starcie zrzuca sobie wszystko, co nie jest jej potrzebne.”
OMG, czy ja widzę to co widzę!? Teraz będziesz twierdził, że SUID jest prawidłowym rozwiązaniem? I że prawidłowo to mam dać +s na tcpdumpa, bo przecież tcpdump będzie potrafił zrzucić uprawnienia!? Buahahah…
„Krotko mowiac – rozumiem, jak to dziala. To bardzo glupi pomysl.”
Chyba nie rozumiesz – xattr na pliku to nie wszystko, wywołujący proces też musi mieć odpowiednie uprawnienia. W ten sposób mogę:
1. stworzyć grupę użytkowników, którym daję CAP_NET_BIND_SERVICE,
2. oznaczyć właściwe programy przez NET_BIND_SERVICE.
tak, aby to działało wyłącznie w takiej właśnie parze. Ty oczywiście mówisz w kółko o rozdzielności:
1. procesy uprawnione do robienia czegość (bez części fs),
2. 'wybiórczy suid’ dla każdego użytkownika.
„Ogolnie – na temat problemu z eskalacja poszukaj bloga, na ktorym autor opisal capabilities w Solarisie 10.”
Szukałem, nie znalazłem. Obawiam się, czy ten blog przypadkiem nie znajduje się wyłącznie w Twojej głowie jako stworzony ad hoc argument.
„Na temat “wybiorczego suida”… Szczerze mowiac nie widzialem zadnej polemiki z tym wynalazkiem. Nie wiem, czy mialaby w ogole sens”
Oczywiście, że nie, bo to TAK NIE DZIAŁA.
„idiotycznosc zalozen rzuca sie w oczy, a jesli sie nie rzuci, to rozpisanie sie tez nic nie da.”
Idiotyczne jest pisanie o założeniach czegoś, czego się nie widziało przez dekadę na oczy.
Jeszcze jedno:
„capabilities zrzucane samodzielnie dzialaja od dawna, ale nie rozwiazuje to podstawowego problemu, jakim jest mozliwosc uzycia sporej czesci z nich do przejecia pelnego roota”
„Prawidlowo jest w druga strone – podniesienie uprawnien wymaga suida, a binarka przy starcie zrzuca sobie wszystko, co nie jest jej potrzebne”
chyba już ci się kompletnie myli wszystko – skoro nie tylko teraz nie krytykujesz „odwrotnego” działania SUID: http://serwer22962.lh.pl/najbezpieczniejszy-system-operacyjny/#comment-5339872 ale i w jednym komentarzu w połowie przeczysz temu, co napisałeś na początku.
Proszę bardzo:
– autorun
– domyślne ukrywanie rozszerzeń plików
– brak zarządzania uprawnieniami do używania napędów fdd, cd-rom, pendrive, nie chodzi mi o możliwość ich wyłączenia
– domyślne konto z uprawnieniami administracyjnymi
Autorun to nie jest blad projektowy – to funkcjonalnosc, ktora bez problemu mozna wylaczyc. (Inna sprawa, ze powinna byc wylaczona by default.) Analogicznie ukrywanie rozszerzen plikow (no halo, czy ja ci do bledow w uniksach zaliczam sposob wyswietlania listy plikow przez, dajmy na to, Firefoksa?) Zarzadzanie uprawnieniami do napedow oczywiscie jest. Konto z uprawnieniami administracyjnymi to kwestia decyzji administratora i nie ma nic wspolnego ani z architektura systemu, ani nawet z implementacja.
Jeszcze raz: potrafisz podac kilka bledow _projektowych_ Windows, ktore obnizaja bezpieczenstwo? Poniewaz suid juz byl, dorzuce kolejny – brak separacji uprawnien w X11, co powoduje, ze dowolny zly program moze udawac wygaszacz ekranu i ukrasc ci haslo.
„Jest coś takiego jak bezpieczny system operacyjny.”
Muszę Cię zmartwić, bo nie masz racji.
„windows powstał na szybko”
Ciekawa teza, choć też nieprawdziwa.
Wszyscy jesteśmy bardzo ciekawi jak nazywa się ten bezpieczny system operacyjny.
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
Tak sobie moge wspomniec, ze w systemach spelniajacych wyzsze kryteria kodu Linuksa nie ma ani linijki, a kod z BSD bywa – chociazby PF. 🙂
Bezpiecznym systemem operacyjnym może być taki, który sam sobie napiszesz i którego tylko Ty będziesz używał. Przy dodatkowym warunku, że nie popełnisz błędów 🙂 Zalety: Nikt nie uruchomi na nim żadnego złośliwego kodu, nie będzie znał interfejsów, nie zrobi nic. Wady: całe mnóstwo 🙂
Poza tym „specjalista” ds. bezpieczeństwa z Kaspersky Lab zawsze stwierdzi, że lepiej używać windowsa, a Linuksa to zupełnie nie warto.
Bo gdyby wszyscy używali odpornego na wirusy Linuksa, to jego firma by zbankrutowała, a on straciłby pracę.
Trzeba być naiwnym, żeby wierzyć człowiekowi mającemu interes w stworzeniu odpowiadającej mu „prawdy”.
Dokładnie. Antywirusy na Linuksa istnieją, tylko rozpoznają jedynie zagrożenie Widnowsowe. Gdyby Linux był zagrożony, to firmy antywirusowe by się chwaliły, że ich linuksowe antywirusy rozpoznają linuksowe zagrożenie.
Obecnie, to są to mrzonki.
No tak, o tym też warto wspomnieć, że „linuksowe” antywirusy istnieją.
Ale pracują na linuksowych routerach/serwerach skanując zawartość wchodzącą do sieci i przekazywaną do komputerów z windowsem.
Bo jeszcze ktoś da się nabrać, że linuksowe antywirusy są dla Linuksa.
„błędne założenie o ultra-bezpieczeństwie tego systemu [Linuksa] i pozostawienie go samemu sobie (bez update-ów i upgradów)”
Lol. Niezły specjalista 😉 Żałosne…
Dokładnie. To tak, jakby napisać: 100% maszyn z Windows nie ma updatów, a to jest głównym problemem braku bezpieczeństwa. (Mimo wszystko, to na tej maszynie z updatami musimy zainstalować jakoś antywirusa). Windows po prostu nie był projektowany, jako system bezpieczny. Narodziło to mnóstwo firm zarabiających na tym. Jakoś przed powstaniem DOS-a antywirusów nie było. Istniały trojany i różne zabawki akademickie, ale wirusów nie było. Powstał DOS i już włosi wynaleźli pierwszego komputerowego wirusa.
Zdecydowana nieprawda.
Wirusy zaczęły się rozwijać i pojawiać sporo wcześniej niż DOS. Tak czy siak rzeczywiście DOS nie był projektowany z myślą o bezpieczeństwie i tu nie ma wątpliwości. Niestety jak widać po kilkudziesięciu latach i ta są osoby, które maja problemy ze zrozumieniem, że Windows w obecnej postaci ma raczej z DOSem niewiele wspólnego. Z resztą linia NT nigdy nie miała…
Pierwsze wirusy powstały w 1986 roku. Czyli jednak nie przed pojawieniem się DOSa.
Co za brednie! Marketing …
No nie wiem, nie wiem. Dystrybucje są pełne dziur. Wystarczy spojrzeć na ostatnie problemy Ubuntu. Linux(kernel) nie różni się specjalnie założeniami od jądra windows. To, że gnu/linux uważany jest za twardszy wynika głównie z profilu przeciętnego użytkownika. Pomiędzy developerem a użytkownikiem powstaje przepaść.
Bzdury pleciesz i FUD siejesz.
Windows był zaprojektowany jako sito. Szczególnie seria 9x/Me, ale NT nadal ciągnie za sobą ogon wymuszonej kompatybilności i skopiowanych rozwiązań, które niestety się przyjęły.
Linux ma dobre podstawy. Nawet najwięszy troll tr*sz umie wymienić tylko jeden problem architektury unixowej: suid. Który tak na prawdę wcale problemem nie jest.
Więc nawet nie ma co porównywać windowsa do Linuksa…
Twoje klamstwa i pobredzania robia sie nudne. Wezmy powyzszy komentarz – nie zawiera ani jednego stwierdzenia, ktore byloby zgodne z prawda.
s/MAC/Mac/
s/update-ów/update’ów/
s/upgradów/upgrade’ów/
s/expolita/exploita/
s/nipotwierdzone/niepotwierdzone/
s/unixo-podobnych/unixopodobnych/
s/tego typy/tego typu/
s/ultra-bezpieczeństwie/ultrabezpieczeństwie/
Interpunkcja do niczego, podobnie słowotwórstwo (webaplikacja? security-bolączki?)
A tego nie ma w oryginale – skąd autor to wziął?
„Pozostała część wystąpienia skupiła się przede wszystkim na zaprezentowaniu najlepszego jego zdaniem remedium na wszystkie security-bolączki jakim są produkty wiadomej firmy.”
Gdyby ten pan wygłosił jeszcze, że z powodu tego wszystkiego firma, w której pracuje wypuści jakiś tam soft na linuksa – byłby to jakiś news. Teraz jest to tekst reklamowy.
Nie wypuści, bo na Linuksie nie potrzeba takich drogich i zbędnych programów.
Za to chcą zniechęcić do przesiadki na Linuksa, żeby użytkownicy cały czas mieli problemy z kiepskim windowsem i wirusami, a oni dzięki temu nadal mieli klientów.
Firmy zajmujące się oprogramowaniem antywirusowym powstały jako odpowiedź na problem, który się pojawił. Jeśli ten problem zostanie rozwiązany, to te firmy powinny zniknąć. Ale do tego oni nie chcą dopuścić, więc zrobią wszytko, aby utrzymać istnienie problemu, który daje im pracę.
Ot, zwyczajny „rozwój” i przeznaczanie mocy przerobowych w kapitaliźmie. Zamiast budować wolą niszczyć, bo to akurat daje większe pieniądze.
@oO
„Ot, zwyczajny “rozwój” i przeznaczanie mocy przerobowych w kapitaliźmie. Zamiast budować wolą niszczyć, bo to akurat daje większe pieniądze.”
Brednie. Ty komunisto!
Po prostu coś, co w kapitaliźmie korporacje osiągają dużym wysiłkiem i stosowaniem brudnych praktyk, to w komuniźmie państwowe kołchozy miały to zapewnione ze strony państwa. Chodzi o uzależnienie konsumentów od swoich usług.
Swoją drogą to w bardzo wielu krajach prawo idzie właśnie w stronę podobną do komunizmu – ludzie nie interesują się danych segmentem rynku lub firmy posiadające swój kapitał na terenie naszego kraju są nie rentowne, to państwo stara się im zapewnić rentowność(patrz na nielegalność różnych rzeczy w USA – kupujesz coś z zagranicznych koncerów, to jesteś zły i ścigany przez prawo; tak samo jest z zabezpieczeniami regionalnymi).
Innymi słowy: obecny kapitalizm niewiele się różni od komunizmu – wszystko poprzez interwencjonizm państwa nie tam gdzie trzeba(nie po to, by chronić konsumentów przed złymi korporacjami z naszego kraju, ale po to, by chronić nasze firmy przed zalewem lepszego towaru z za granicy).
Już wiem, co robili niemieccy naukowcy po zakończeniu drugiej wojny światowej – pomagali zbudować amerykańską gospodarkę. Chociaż w zasadzie, to w USA powstał nizizm(dochodziło nawet do chęci zakazywania posiadania dzieci rodzinom niespełniających odpowiednich reguł – nakaz aborcji). Niemcy tę całą ideologię przywłaszczyli sobie od amerykanów.
Zwykły marketing.
Zwykłe oszukiwanie użytkownika, że potrzebny mu jest program antywirusowy. Wystarczy usunąć z dysku pełen błędów system i problem wirusów sam się rozwiąże.
Wystarczy wyrzucić komputer za okno 😉
No autorowi chyba właśnie chodziło o zdemaskowanie zwykłego marketingu ukrytego pod wystąpieniem specjalisty.
Większy problem jest z upgrade’ami. Robię sobie maszynkę na Linuksie, stosuję Archa. Po zainstalowaniu i wstępnym skonfigurowaniu (język, klawiatura, nazwa komputera, użytkownik z małymi uprawnieniami, spoofing MAC, alsa) robię aktualizację. Pacman ściąga pakiety, instaluje po czym restartuje system.
No i po restarcie zaczyna się. WGet nie działa. Nano zachowuje się poniekąd dziwnie (brak paska i działania na większość poleceń, piękna zupa z ekranu helpa). Nie mówiąc już o innych programach (cfdisk raportuje brak dysku, podobnie jak df wyrzucający pustą stronę). Sytuacje udało się doprowadzić do porządku instalując „ręcznie” kilka bibliotek, a dochodzenie które to biblioteki trwało kilka godzin. Tylko dlaczego tego nie robi aktualizacja podczas rozpoznawania zależności?
Taka sytuacja, jeżeli występuje w innych dystrybucjach, skłania administratorów do rzadszego aktualizowania systemu. I dziwić się, że serwery mogą mieć luki?
Może zrezygnuj z tego Archa, bo po tym co piszesz to jakieś strasznie amatorskie gówno.
I nie siej FUDu na temat każdej dystrybucji Linuksa.
Na Debianie nie mam najmniejszych problemów i jeszcze NIGDY aktualizacja niczego nie popsuła.
A używam i stable i testing.
Nawet mam jedną maszynę, która ciągnie na testing od Etcha (4.0), potem upgrade do Lennego, a teraz do Squeeze. I wszystko zawsze działo.
Arch to dystrybucja typu „rolling realease” wiec zalozenie, ze cos po aktualizacji nie bedzie dzialac jest przyjete od samego poczatku. I nie wydaje mi sie, aby byl uzywany na serwerach- to jest dystrybujca typu desktop.
Dlateg nie mowilbym, ze to g*no- tworcy postawili na najnowsze wersje programow a nie maksymalna stabilnosc- choc tu tez bym nie narzekla- uzywalem go dlugo i nie mialem problemow ze stabilnoscia- desktop.
Jak ktos chce miec w miare bezpieczny update w Archu niech robi go raz w tygodniu a nie raz na kwartal i niech zainteresuje sie Arch Rollback Machine.
To nie masz racji. Ja instaluje aktualizacje, kiedy są tylko potrzebne, i nie mam jakichkolwiek problemów. Wystarczy korzystać z porządnej dystrybucji. Jedynie na Debianie sid miałem problemy, gdzie po aktualizacji Xy nie chciały wstać. Wystarczyło tylko wydać jedno polecenie w konsoli i poczekać.
Oczywiście SID w sensie przyszłego wydania. Coś mniej stabilnego niż testing.
Ja tam nie mam z Archem takich problemow. Zainstalowalem, dokonfigurowalem, zaktualizowalem i wszystko smiga.
A na innym systemie dobrze dziala?
Arch nie jest amatorskim gownem. Konkretnie, to na distrowatch jest na 9. miejscu wsrod najpopularniejszych…
Naturą Archa jest, że wpadają tam do repo bardzo nowe paczki, często nie sprawdzone dokładnie (poza core, oczywiście) i czasami różne „kfiatki” mogą się zdarzyć i każdy świadomy użytkownik Archa o tym wie. Co nie zmienia faktu, że nie miałem nigdy większych problemów (jedyne co pamiętam to wmii się nie lubiło z którąś wersją glibc i nadal nie lubi się z najnowszym dashem, ale ilu ludzi używa wmii? ;).
A Pacman jest, zaraz po Portage, najlepszym managerem oprogramowania jakiego używałem (a używałem chyba wszystkich istniejących na rynku :-).
Jak zwykle „gęby” mi pozjadały zawiasy. Za każdym razem sobie mówie, że będę o tym pamiętał i zawsze zapominam ;).
No chyba jednak nie używałeś poldka.
Coś w tym jest. Po pierwsze, wszystkie główne systemy operacyjne (Windows, Linux, Mac) prezentują podobny poziom bezpieczeństwa. Po drugie, w czasach gdy coraz więcej rzeczy wykonuje się w sieci, przy użyciu aplikacji webowych, najważniejszym ogniwem staje się przeglądarka internetowa – a te, z grubsza, są takie same na każdym systemie.
„Po pierwsze, wszystkie główne systemy operacyjne (Windows, Linux, Mac) prezentują podobny poziom bezpieczeństwa.”
Dowody? O czym ty piszesz? W MacOS X i Linuksie masz dobrze opisaną strukturę katalogów, z uwzględnieniem bibliotek, plików wykonywalnych, danych. W Windowsie tego nie masz, przez co aplikacja może wrzucić/podmienić coś w odpowiedniej lokalizacji. Ten UAC, to też śmiech na sali i się nawet do SUDO nie umywa, a wszyscy wiemy, że domyślnie użytkownik pracuje na czymś w stylu konta admina, jednak UAC(nadal nie rozwiązano problemu z uprawnieniami, tylko go przeniesiono na użytkownika z systemu).
Ty to może pierw przeczytaj coś zanim o czymś zaczniesz pisać..
Jeśli tak to dlaczego na Windows muszę mięć antywirusa, a na Linuksie nie?
Z tego samego powodu, dla którego w Polsce szczepi się ludzi przeciwko żółtaczce a przeciwko malarii już nie.
Ogólnie na Linuksa powstaje mniej oprogramowania, więc wirusów w szczególności też. Minęły już romantyczne czasy, gdy wirusy grały śmieszne melodie i pokazywały na ekranach zabawne animacje. Teraz malware tworzy się dla zysku – by okraść jak najwięcej użytkowników, albo wysłać spam z największej liczby komputerów. Trudno się dziwić, że twórcy wirusów targetują Windows. O ile w przypadku „zwykłego” oprogramowania producent może liczyć na dobry PR związany z wydaniem wersji na „alternatywne” systemy – to raczej w przypadku twórców złośliwego oprogramowania ten argument nie ma sensu.
Ostatnia rzecz. Malware nie wykorzystuje luk w oprogramowaniu – raczej luki w rozumowaniu użytkowników. A tutaj, niestety, Linux nie odstaje zbytnio od Windows, co widać po komentarzach publikowanych tutaj. Co stwierdzam z żalem.
A dlaczego ja na windows jakoś nie potrzebuję antywirusa?
Magia? A może wystarczy wiedzieć co się robi
Zgadzam się ze stwierdzeniem, że nie ma bezpiecznego systemu ponieważ nie mamy żadnej skali porównawczej. Jednak jeśli miałbym pozwolić komuś skorzystać z mojego prywatnego komputera to tylko na linuksie ponieważ taki osobnik bez znajomości hasła nie zrobi nic. Jeśli już zna hasło do konta to może oczywiście wykorzystać sudo ale to inna bajka. W przypadku Windowsa osoba taka nie musi znać hasła wystarczy wyklikać parę okien. W przypadku gdy chciałaby np. podłączyć jakiegoś pendrive może mieć na nim jakiegoś gotowego autoruna, który przeniesie zawartość tegoż pendriva do mojego systemu. I tutaj raczej nie pomoże większość antywirusów natomiast na Linuksie taka sytuacja nie ma miejsca.
Podsumowując moje brednie. Linux jest bezpieczniejszy niż Windows ale bez prawdziwej skali porównawczej, której nigdy nie będzie nie jesteśmy w stanie tego na 100% stwierdzić.
Ty dalej używasz Windows 98???
Jezeli ktos ma dostep do Twojej maszynyz Linuxem, to wchodzi w tryb singleuser i ustawia sobie haslo roota na takie jakie mu pasuje, i nie potrzbuje do tego sudo ani innych rozwiazan.
System operacyjny jest na tyle bezpieczny, na ile potrafi go zabezpieczyc jego administrator. Windows, Linux, BSD – co za roznica.
Raczej to wygląda na wpis jakiegoś bloga, a nie news.
Jeżeli ktoś chce wywołać polemikę, a nie rzeczowo informować o jakiś nowinkach, to temat jest na bloga.
Podobne informacje firmy antywirusowe publikowały niejednokrotnie.Nie mam zamiaru nic więcej pisać w tym temacie.
Kłamstwo powtórzone 1000x nie stanie się prawdą!
Kaspersky Lab i wszystko jasne.
Jak tam ich antywirusowa suita pod Linuksa? Czy aby zbyt słabo się nie sprzedaje, skoro tak wciąż trąbią o niebezpieczeństwach w tym systemie?
Chcą jako pierwsi zagarnąć nowy rynek 😉 .
@oO
„windows powstał na szybko i cały czas ciągnie za sobą ogon błędów projektowych”
O czym ty piszesz? Odpowiedz na pytanie trasza. Czytając twoje „wypowiedzi” od jakiegoś czasu widzę, że nie masz zielonego pojęcia o Windowsie. Zapewne nie będziesz w stanie na to pytanie odpowiedzieć.
Odnośnie tego co napisałeś mogę zacytować tylko jedną trafną wypowiedź… W przeciwieństwie do Windowsa Linux nie jest zaprojektowany, tylko posklejany.
Ludzie! Zróbcie chociaż mały risercz zanim zaczniecie wypisywać głupoty.
Choćby głupi
pingma ustawiony SUID.To tak jakby czytać rewelacje pracownika firmy farmaceutycznej na temat profilaktyki i zdrowego odżywiania. Delikatnie mówiąc dostrzegam tutaj pewien konflikt interesów i brak obiektywizmu 😀
Apropos SUID: ping, login, su, sudo i wiele innych.
Bez tego atrybutu trzeba by było pisać odrębne demony pracujące na odpowiednio wyższych uprawnieniach. Wątpię by pingd był w jakikolwiek sposób bezpieczniejszy od zwykłego polecenia ping. Błąd w kodzie miał by te same, albo i poważniejsze konsekwencje.
Aktualne rozwiązanie ma jedną olbrzymią zaletę: Jest dziecinnie proste.
Bylby, z bardzo prostego powodu – konsekwencji przeoczenia. Suid dziala „na odwrot” – to, co przeoczysz, chociazby zmienne srodowiskowe, zostaja i dzialaja tak, jak zwykle, czyli jak chce potencjalny atakujacy. Oddzielny demon dostawalby tylko to, co explicite bys mu przekazal; cala reszta bylaby kontrolowana przez ciebie, nie przez atakujacego.
Z tym że nawet zakładając wykorzystanie odpowiednika inetd, cała usługa była by nieporównywalnie bardziej złożona i w konsekwencji mogło by się okazać że bardziej podatna na przykład na ataki DOS.
Zmiennych środowiskowych nie obawiał bym się aż tak bardzo. O takie cukierki jak LD_PRELOAD, dba już sam system, a z resztą można sobie poradzić używając zasady ograniczonego zaufania. Pisząc demona także trzeba uważać na dane wejściowe.
To trochę trąci dyskusją o wyższości mikrokerneli nad monolitycznym systemem.
ps.
Swoją drogą, skoro już o pingu mowa, zawsze zastanawiało mnie czemu w systemie Solaris nie ma on tego atrybutu. Rezultatem jest to że administrator częściej korzysta z konta root’a. To trochę jak z tymi żółtymi karteczkami zawierającymi hasła przyklejonymi do monitora.
Nie sadze, zeby calosc byla bardziej zlozona czy podatna na cokolwiek.
Co do obaw – popatrz po prostu na track record zwiazany z suidem. Chociazby na ilosc dziur w sudo w ciagu ostatnich paru lat.
Przynajmniej w tak banalnym przypadku jak ping, ta nadmiarowość była by wręcz przesadnie duża. Trudno więc o porównanie.
W innych przypadkach odpowiedniki już mamy. „Demonicznym” zamiennikiem sudo jest np telnetd, lub sshd. Wydaje mi się że historia problemów z bezpieczeństwem jest tu porównywalna.
Potencjalnie większa ilość problemów z SUID, wynika z łatwości w użycu. Napisanie sudo wydaje się proste, napisanie telnetd wymaga już odrobiny wiedzy. W efekcie nie bierze się za to amator.
Pytanie tylko czy to jest wada?
@Red: nie porównuj pinga do telnetd czy sshd, bo popełniasz błąd podobny jak trasz w http://serwer22962.lh.pl/najbezpieczniejszy-system-operacyjny/#comment-5341362 – o ile ping potrzebuje tylko dostępu do socketu, to telnet oraz ssh muszą dać możliwość zalogowania się na dowolne konto w systemie włączając w to roota.
Prawidłowe rozwiązanie: dać pingowi prawo do otwierania socketu. To się robi przez część filesystemową capabilities.
@Red: Ciagnac twoj, mocno teoretyczny, przyklad – nadmiarowosc bylaby minimalna: odczytanie adresu IP/hostname’a ze standardowego wejscia zamiast z linii komend; reszte zrobilby inetd.
Telnetd moze byc zamiennikiem su, nie sudo. Ale to zly przyklad, bo dziur w telnetd bylo rownie niewiele, co dziur w samym su.
Co do prostoty pisania – tu sie moge troche zgodzic. Troche, bo napisanie telnetd tez jest trywialnie latwe (nie wystarczyloby po prostu wrzucic /bin/sh do inetda? Az chyba pozniej sprawdze). Ale ogolnie zgadzam sie, ze to wlasnie jest jedna z przyczyn problemu – suid bardzo ulatwia postrzelenie sie w stope przy pomocy programu, ktory wedlug autora jest bezpieczny, podczas gdy w rzeczywistosci nie jest. W przypadku demonow postrzelenie sie w stope byloby trudniejsze, z przyczyn opisanych kilka komentarzy wyzej.
/bin/sh do inetda kiedyś ludzie wrzucali by mieć backdora, więc to działa. Jedynie windowsy będą miały ograniczony dostęp ze względu na brak konwersji znaków nowej linii.
O niebezpieczeństwach SUID ROOT nie trzeba się wiele rozpisywać wystarczy zobaczyć co potrafi /bin/cat z takimi uprawnieniami.
Rzecz w tym że w mojej opinii nie deprecjonuje to samego mechanizmu. To jest cena prostoty. Sam przy innych okazjach pisałeś że im prostsze rozwiązanie tym pewniejsze.
Technika dorobiła się złej opinii, bo swojego czasu była notorycznie nadużywana. Były czasy gdy nawet perl miał suid root. Niekiedy też wyskakują takie cukierki jak instalacja OpenOffice z tym atrybutem przez któregoś producenta drukarek.
Jeszcze jedno, bit +s może być równie dobrze użyty do obniżenia uprawnień. Szkoda że mało kto o tym pamięta.
Zapomniałem dodać… To działanie „na odwrót”, to tylko złudzenie.
Ty tylko prosisz system o uruchomienie programu. To na jakich uprawnieniach będzie działał zależy już systemu.
Więc tak na prawdę, poza API, wszystko sprowadza się do tego samego.
@trasz: zgodnie z tym, co napisałeś wyżej do mnie – o filtrowanie takich rzeczy, jak zmienne środowiskowe, zadbać powinien autor, bo on wie co jest potrzebne, a co niebezpieczne (było: dropowanie capabilities). Teraz już mam nadzieję rozumiesz o co chodzi z dawaniem konkretnemu programowi konkretnego zezwolenia.
@gotar: Nie, ze wzgledu na konsekwencje przeoczenia. Autor wie, co mu jest potrzebne, ale nie moze przeoczyc cos, co powinien wyfiltrowac. W przypadku dropowania capabilities tego problemu nie ma – program moze zdropowac wszystkie (w sensie, wszystkie ogolnie, nie kazdą oddzielnie) oprocz wybranych. I, jesli nie uzywamy xattr, bedzie to bezposrednio w kodzie zrodlowym, a nie w czyms, co wymaga do dzialania interwencji innych osob, na przyklad administratora (xattr).