Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2017-07-17 05:07:20

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Eskalacja uprawnień w systemd

Tak sobie przeglądałem RSS'y i na jednym z nich dostrzegłem artykuł odsyłający do [url=https://github.com/systemd/systemd/issues/6237]tego wątku na GH[/url]. W zasadzie to sprawa jest bardzo prosta, tj. jak w systemie jest użytkownik, którego nazwa zaczyna się od cyferki (ten 0day), to wtedy usługa systemd, która ma takiego użytkownika określonego (user=0day) zostanie wykonana z uprawnieniami root. Generalnie to ludzie się czepiają systemd, że to niby ich błąd, a ci mówią, że nie ich. No i w zasadzie jak się popatrzy na te narzędzia umożliwiające tworzenie użytkowników (useradd/adduser), to widać pewną niekonsekwencję, gdzie jedno z tych narzędzi zezwala na dodanie użytkownika zaczynającego się od cyferki, a drugie nie zezwala na to i to ze względu czysto praktycznych, bo nazwy użytkowników mają przypisane również numerki ID.

Co sądzicie o tym błędzie i gdzie według was leży problem? Czy narzędzia powinny zezwalać na tworzenie nazw użytkowników, które zaczynają się od cyferek, czy coś w systemd jest do poprawy?

Offline

 

#2  2017-07-17 05:34:45

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Eskalacja uprawnień w systemd

Teoretycznie useradd nie pozwala na nazwę usera  zaczynającą się od cyfry,w praktyce każda eskalacja uprawnień jest groźna,bona każdą kiedyś się znajdzie sposób.
Dwa czy trzy takie niewinne błędy, i mamy pełną kompromitację systemu, żeby wspomnieć niewinną lukę w sudo, która się ujawnila w momencie,kiedy w Ubuntu i MacOS dali userom możliwość nastawiania zegara.

Ot dwie pozornie niewinne sprawy i mamy rezultat:
http://www.h-online.com/security/news/item/Security-vulnerability-in-sudo-allows-privilege-escalation-1816387.html

Zupełnie jak dwa malutkie pęknięcia w konstrukcji zapory wodnej.

Chociaż w konktekście SystemD ja podejrzewam raczej długie ręce Red-Hata, które dbają
o to, żeby był popyt na płatny support do SELinuxa, albo i wpływy NSA, które też lubi czasem zajrzeć tu czy tam, i muszą mieć różne tajne drzwiczki do różnych OSów.
Widać to trochę w determinacji, z jaką SystemD zajmuje przestrzeń roota,połykając różne narzędzia od udeva, poprzez consolekit  do dbusa.

Historia  Truecrypta czy Grsecurity pokazuje, że jak kogoś służby nie lubią, tego sponsorzy też omijają szerokim łukiem.

Pozdro

Ostatnio edytowany przez Jacekalex (2017-07-17 05:41:44)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#3  2017-07-17 20:15:20

  yossarian - Szczawiożerca

yossarian
Szczawiożerca
Skąd: Shangri-La
Zarejestrowany: 2011-04-25

Re: Eskalacja uprawnień w systemd

Problem jest taki, że systemd wymusza (często siłowo i bezwzględnie) pewną standaryzację/ujednolicenie procedur w miejsce odwiecznej linuksowej dowolności.
I potem na styku tych różnych „światów” pojawiają się tego typu błędy, do których wtedy ciężko znaleźć jednoznacznych winnych bo wcześniej nikt nie zwracał uwagi na różne rozbieżności lub nawet błędy. Za to każda ze stron okopuje się na swoich stanowisku, a błędy dalej wiszą bo oba te środowiska są zbyt narcystyczne.
Takie przepychanki będą trwały jeszcze kilka lat, aż jedna ze stron narzuci swoją wizję tej drugiej. Albo pojawi się trzecia — zupełnie nowa.

Chyba najśmieszniejszy był „błąd” w poleceniu [tt]halt[/tt] (poruszany też na DUG) — ci wredni deweloperzy od systemd „popsuli” wyłączanie komputera poleceniem halt:

Not a bug but expected behaviour [0]. halt is *not* supposed to turn of
the machine.
It was actually a bug in sysvinit that it did that.
If you want to poweroff the machine, use poweroff.[/quote]
:D

@Jacekalex:
A ty dalej te swoje nawiedzone wizje — oczywiście bez żadnych argumentów i dowodów poza swoimi urojeniami. Nie ma sensu tego komentować.
Red Hat ma praktycznie decydujący wpływ na wszystko w Linuksie i gdyby tylko chciał to by se umieścił pińcet backdoorów w dowolnym miejscu dowolnej dystrybucji, których byś nawet nie zauważył.

z jaką SystemD zajmuje przestrzeń roota,połykając różne narzędzia od udeva, poprzez consolekit  do dbusa.[/quote]
widocznie zapomniałeś dopisać, że autorzy tych narzędzi je albo porzucili i zastąpili nowszymi projektami (consolekit-logind) lub dalej kontynuują ich rozwój wg swojej wizji (udev, dbus itp.).
Rozwiązanie masz bardzo proste — stwórz swoje narzędzia lub opłać deweloperów, który będą spełniać twoje zachcianki.

Od zawsze zasada jest jedna — decydują ci, którzy tworzą kod lub finansują deweloperów.
Internetowymi krzykaczami nikt się nie przejmuje. Karawana jedzie dalej.

Offline

 

#4  2017-07-18 04:34:01

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Eskalacja uprawnień w systemd

Można by wykorzystać sytuację i nagłośnić sprawę jaki to linux jest niebezpieczny. xD Może w końcu by wypracowali jakiś standard dotyczący użytkowników i grup w systemie, bo to naprawdę jest śmiech na sali, że dwa różne narzędzia w tej samej dystrybucji mają inną politykę tworzenia użytkowników. xD

Offline

 

#5  2017-07-18 04:45:56

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Eskalacja uprawnień w systemd

Red Hat ma praktycznie decydujący wpływ na wszystko w Linuksie i gdyby tylko chciał to by se umieścił pińcet backdoorów w dowolnym miejscu dowolnej dystrybucji, których byś nawet nie zauważył.[/quote]
I tu się mylisz, RH złapany na umieszczeniu 1 backdoora to byłoby praktycznie samobójstwo.
Do tego ma bardzo duży, ale nie "praktycznie decydujący" wpływ, gdyby taki miał, to Grsecurity&Pax czy Apparmor by nigdy nie powstały.
Masz pod tym względem strasznie nieaktualne informacje, największe wpływy w świecie Linuxa od czasu powstania Androida ma Google, więcej od RH do powiedzenia mają też Intel, Samsung czy FB.

RH jako jedyna ze sponsorów Linuxa jest genetycznie zrośnięta z NSA, oprócz tego ma też własne biznesowe interesy.
Dlatego backdoorów umieszczać nie może, ale Xorg działający z uprawnieniami roota,czy taki potwór jak SystemD zawsze otwiera pewne możliwości działania, chociaż nie ma w nim żadnego backdoora, są tylko drobne podatności.

Potem tylko wyciekają backdoory z różnych Mukhabaratów  i się wtedy przy okazji różnych ciekawych rzeczy dowiadujemy, jak przy sławnej implementacji Ipsec w OpenBSD czy Heartbleed w OpenSSL.

Pozdro

Ostatnio edytowany przez Jacekalex (2017-07-18 04:46:38)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#6  2017-07-18 08:42:06

  yossarian - Szczawiożerca

yossarian
Szczawiożerca
Skąd: Shangri-La
Zarejestrowany: 2011-04-25

Re: Eskalacja uprawnień w systemd

I tu się mylisz, RH złapany na umieszczeniu 1 backdoora to byłoby praktycznie samobójstwo.[/quote]

ma też własne biznesowe interesy.[/quote]
Dlatego więc montują backdoory/luki bo wspaniałomyślnie chcą popełnić spektakularne samobójstwo :D

Masz pod tym względem strasznie nieaktualne informacje, największe wpływy w świecie Linuxa od czasu powstania Androida ma Google, więcej od RH do powiedzenia mają też Intel, Samsung czy FB.[/quote]
Poza jądrem masz jeszcze cały stos graficzny (m. in. Xorg, a szczególnie Wayland) wraz ze sterownikami graficznymi i ich implementacją, główne środowisko graficzne w większości dystrybucji linuksowych, masa kluczowych bibliotek i narzędzi — Glibc, GTK, GCC, OpenJDK, NetworkManager, OpenStack, SELinux, KVM, PolicyKit, udisk, upower i setki innych…
Rzeczywiście, Google i Facebook mogą więcej :)

Grsecurity&Pax czy Apparmor by nigdy nie powstały.[/quote]
Powstały bo komuś się chciało je stworzyć zamiast trollować w internetach.
Poza tym ekipie od Grsecurity widocznie trochę się już znudziło.

Chciałbym tylko przypomnieć, że to nie jest wątek [i]Humor[/i] ;)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)

[ Generated in 0.020 seconds, 12 queries executed ]

Informacje debugowania

Time (s) Query
0.00019 SET CHARSET latin2
0.00008 SET NAMES latin2
0.00173 SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.144.103.20' WHERE u.id=1
0.00262 REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.144.103.20', 1732692002)
0.00106 SELECT * FROM punbb_online WHERE logged<1732691702
0.00242 DELETE FROM punbb_online WHERE ident='54.36.148.83'
0.00147 SELECT topic_id FROM punbb_posts WHERE id=312611
0.00010 SELECT id FROM punbb_posts WHERE topic_id=29745 ORDER BY posted
0.00096 SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29745 AND t.moved_to IS NULL
0.00018 SELECT search_for, replace_with FROM punbb_censoring
0.00326 SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29745 ORDER BY p.id LIMIT 0,25
0.00181 UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29745
Total query time: 0.01588 s