Forum Debian Users Gang

Takie menadżery okien korzystają tylko z Xorg, chcesz bezpieczny system wybierz coś co wspiera Wayland.

ilin napisał(-a):

Bez paranoi z tym bezpieczeństwem.
Sam użytkownik narobi sobie więcej szkód niż potencjalny haker. :)

To raczej nie paranoja tylko doświadczenie.

Ciekawi mnie to, że kiedy okazało się, że Xorg idzie na śmietnik historii, to natychmiast się zaczęło wielkie ciśnienie na SystemD.
Moim zdaniem są pewne siły, które chcą mieć  wjazd do każdego kompa na świecie, a im większy i bardziej skomplikowany program, tym łatwiej coś w nim ukryć.

PS:
Chociaż na Xorga i jego problemy też jest mały sposobik:
https://gitlab.com/morfikov/debian-files/blob/maste … r.d/xorg-xorg
xD

Ostatnio edytowany przez Jacekalex (2020-01-06 17:10:23)

Mógłbym się z tym zgodzić jeśli dotyczyło by to administratora jakiegoś servera.
Tu zaś mowa o początkującym użytkowniku linuksa.

Co wy macie w tych kompach ze tak portkami trzęsiecie. :)

Ja się zgadzam z ilin. Jeśli ktoś nie jest Jamesem Bondem i nie przetrzymuje na kompie informacji o tym kto naprawdę zabił Kennedy'ego, to nie ma co wariować i zabezpieczać kompa lepiej niż serwery NASA. Wystarczy trochę rozsądku w codziennym użytkowaniu, które system powinien ułatwiać, a nie utrudniać.

Ostatnio edytowany przez blind (2020-01-06 18:34:58)

xfce5 napisał(-a):

Teraz exploity na Linuxa muszą wejść do systemu przez dziury w SystemD albo Xorga, ale Xorg też już idzie do betonowego sarkofagu, żaden kompozytor obrazu używający protokołu wayland już nie będzie pracował z uprawnieniami roota...

Ale przecie Xserver też jest w stanie działać z uprawnieniami użytkownika — niektóre DM wspierają to bez problemu, a poza tym zawsze pozostaje startx z konta zwykłego usera po zalogowaniu się na TTY.

xfce5 napisał(-a):

Dlatego ciężka kasa z NSA/Red_Hata idzie na to, żeby SystemD połknął całą przestrzeń roota, czyli PAM, Consolekit, Policykit, Udeva, Sysloga, DBUSa, INETD i Cgroup.

Tzn. dlaczego ta kasa idzie na systemd twoim zdaniem? xD

Obecnie mamy nieco inne realia niż 20 lat temu, dlatego struktura systemu operacyjnego się zmienia, np. mamy kompa podłączonego do sieci... System bez obsługi sieci, firewalla czy też synchronizacji czasu jest pozbawiony sensu. Podobnie też ma się sprawa z obsługą procesów, która nie tylko polega na uruchamianiu/zatrzymywania konkretnych usług podczas startu systemu (i później w czasie jego pracy) ale też w grę wchodzą mechanizmy bezpieczeństwa polegające na choćby limitowaniu procesom dostępu do zasobów sprzętowych maszyny. Idąc dalej, z racji podłączenia systemów na stałe do sieci, trzeba się zatroszczyć o ograniczenie procesom dostępu do konkretnych plików w systemie, tak by te procesy nawet jak wymkną się spod kontroli, to by nie narobiły szkód (jest AA czy SELinux ale dlaczego nie miałby się tym zając systemd?). Podobnie sprawa ma się z FW, gdzie filtrowanie pakietów na podstawie portu/adresu jest już ździebko bez sensu (gdy w grę wchodzi, np. OUTPUT), bo obecnie potrzebny jest firewall procesowy na bazie cgroups i do tego zmierzają prace w systemd (ja mam to ręcznie zaimplementowane ale powinna być w standardzie możliwość określenia czy dana aplikacja i jej procesy mogą korzystać z sieci, itp.). Jak sobie popatrzysz na całość systemd, to zobaczysz, że oni chcą wszystkie aspekty związane z zarządzaniem i działaniem procesów ogarnąć w jednym miejscu i o to właśnie chodzi. Te wszystkie wyżej wymienione rzeczy to jest niezbędne minimum, które każdy system musi mieć by można było z niego w miarę bezpiecznie i komfortowo korzystać. W przypadku systemd, konfiguracja poszczególnych usług sprowadza się do edycji jednego pliku tekstowego... no może dwóch... Po co zatem utrzymywać xxx różnych projektów, które będą realizować to samo co teraz realizuje systemd OOTB i jeszcze ponosić koszt związany z kompatybilnością tych wszystkich projektów i ich dev'ów...? xD

xfce5 napisał(-a):

Przy okazji robi się taki gigantyczny kolos, że kod SystemD też się niedługo wymknie spod kontroli, i jeden Bóg będzie widział, co w tym kodzie siedzi, podobnie jak obecnie w Xorgu.

Te wszystkie xxx usług realizujących to samo co systemd ma o wiele więcej linijek kodu... xD

A poza tym, audyt kodu aplikacji tekstowych jest o wiele prostszy niż np. audyt kodu graficznych aplikacji — to dlatego wayland nie daje możliwości uruchamiania graficznych appek jako root. Na tym polu również potrzebna jest gruntowna zmiana podejścia w projektowaniu aplikacji. Np. po co uruchamiać graficzny edytor tekstowy jako root i narażać system na problemy (miliony linijek kodu qt/gtk też będzie wykonywany jako root), skoro można przepisać appkę tak by tylko operacja odczytu/zapisu danego pliku systemowego prosiła o stosowne uprawnienia. Póki co jest bardzo niewiele takich aplikacji, np. dlatego synaptic'a wywalili z Debiana stable, bo on jest niereformowalny i pod wayland działać natywnie nigdy nie będzie.

Reasumując — potrzebne jest nowe oprogramowanie przystosowane do realiów otaczającej nas wirtualnej rzeczywistości. xD