przystajnik

Kate i KWrite nie dla roota

Chyba nikogo nie trzeba przekonywać o tym, że uruchamianie graficznych narzędzi jako użytkownik root jest niefrasobliwe. Jednak stając przed konieczności edytowania pliku z prawami roota zwykle ignorujemy to zalecenie. I dlatego Martin Gräßlin postanowił przypomnieć o tym niuansie w dość kategoryczny sposób. Zgłoszone przez niego poprawki do edytorów tekstowych Kate i KWrite powodują, że nie uruchomimy ich jako root.

Tyle hałasu o zwykły edytor

Przesłanki stojące za taką zmianą wydają się być słuszne. Zamiast ciągle przypominać o tej zasadzie, Martin wprowadził do kodu warunek sprawdzający z jakimi uprawnieniami próbujemy użytkować programu. Jeżeli będzie to root, to Kate i KWrite odmówią współpracy, edukując jednak nas o praktyczności wykorzystania sudoedit. Dzięki niemu program którym będziemy edytowali plik tekstowy zostanie uruchomiony z prawami naszego użytkownika. Zmiany zostaną wprowadzone dopiero po zamknięciu edytora (sudoedit pracuje na lokalnej kopii pliku, po zamknięciu naszego programu kopiuje ten plik na właściwe miejsce i z odpowiednimi uprawnieniami).

Jak Martin argumentuje taki krok? Głównie tym, że nawet twórcy bibliotek Qt nie chcą wziąć odpowiedzialności za uruchomiony z prawami roota tak rozległy kod jakim jest Qt. Na dodatek uruchamiany w otoczeniu X11, które bezpieczeństwem nie grzeszy. Sam program korzystający z Qt, po starcie ma do czynienia również z xcb, Xlib, OpenGL, xkbcommon, itp. Wywołanie aplikacji z wykorzystaniem Setuid jest najgorszym z możliwych pomysłów. Na poparcie swoich słów przytacza swój proof of concept, gdy zaszył w Dolphinie prosty atak na naszą maszynę. Wystarczyło odpalić Dolphina jako root, by otworzony został terminal z prawami roota, gdzie „wirus” wpisywał swoje polecenia.

Zmian należy oczekiwać w najbliższym wydaniu środowiska KDE Plasma 5. 

Post navigation

21 comments for “Kate i KWrite nie dla roota

  1. Name
    22 lutego, 2017 at 9:35

    Bardzo praktyczne edytory. Z jedną jednakże wadą – nie działa (albo nie jest to zaimplementowane) automatyczne dopasowanie wcięć podczas wklejania kodu ze schowka.

  2. Jarek W
    22 lutego, 2017 at 10:40

    Offtopic: Jeszcze przez 9 dni można nabyć WARHAMMER TOTAL WAR za 12 dolarów na humble bumble włączając miesięczną subskrypcje. Pięknie śmiga na linux Mint 18.1 mimo że krzyczy o niezgodności wersji 🙂

  3. Dobrecki
    22 lutego, 2017 at 11:17

    A to ciekawe. Dla mnie root to root. Się otwiera terminal, się robi co trzeba i się zamyka roota a potem i terminal. Pracować stale na roocie na ubuntowych dystrybucjach nie ma specjalnego sensu, bo by to niewygodne chyba było? O bezpieczeństwie nie wspominając.

    Ale, ale, mi to polecenie sudoedit otwiera edytor Nano. Tak ma być na stałe, czy może da się to jakoś przestawić? Bo awaryjnie Nano jest bezkonkurencyjny, ale na codzień nie nawykłem do takich wynalazków i ciężej mi w Nano ogarnąć to co muszę edytować.

  4. użytkownik
    22 lutego, 2017 at 12:10

    Aby zmienić edytor który otwiera sudoedit, trzeba ustawić zmienną VISUAL w .bashrc lub .zshrc. Polecenie `VISUAL=gedit sudoedit /etc/hosts` otworzy ci plik hosts za pomocą gedita.

  5. pavbaranov
    22 lutego, 2017 at 19:19

    Nie chodzi o to, by pracować na roocie w GUI. Chodzi o wywołanie programu w sposób sudo/kdesu program. Zwykle to dawało możliwość odpalenia takiego programu z uprawnieniami root. Teraz nie. Zresztą już od dłuższego czasu.
    Polecenie z konsoli, to np. kate sudoedit coś.

  6. pavbaranov
    22 lutego, 2017 at 19:20

    Hmm… co ma gedit do blokady w kate/kwrite? Reszta – masz rację.

  7. Inter
    22 lutego, 2017 at 19:20

    Kurcze, ja zazwyczaj jak coś robię jako root to w trybie graficznym. Odpalam thunara przez gksu i edytuję w graficznym edytorze pliki roota. Myślicie że coś źle robię? A co z takim Synaptic’iem który przecież też otrzymuje uprawnienia roota w trybie graficznym? Nie używać?

  8. pavbaranov
    22 lutego, 2017 at 19:22

    Cóż… brak możliowści uruchamiania programów z KDE na prawach roota jest widoczny od kilku miesięcy. Prostym rozwiązaniem okazało się np. zainstalowanie paczki dbus-x11 w miejsce dbus (tak jest np. w Manjaro). Jeśli ktoś ma zainstalowaną taką paczkę, to uruchomi kate/kwrite, czy cokolwiek i nic mu nie da blokada wprowadzona do kate/kwrite.
    Chroniąc się przed atakiem, należałoby zatem w Manjaro (co najmniej) przywrócić dbus do oryginalnej postaci.

  9. Jan Zoń
    22 lutego, 2017 at 20:20

    Mogę się mylić, ale wydaje mi się, że poprawki (jeżeli są dobrze napisane) mogą spowodować niemożność uruchomienia tychże programów, bo żeby sprawdzić czy aplikacja jest uruchomiona jako root, są dużo prostsze rozwiązania niż korzystanie z dbus
    http://stackoverflow.com/users/366332/vanni-totaro przykład detekcji, kto uruchomił aplikację

    EDIT: Tak właśnie zrobiono: https://github.com/KDE/kate/commit/9adcebd3c2e476c8a32e9b455cc99f46b0e12a7e#diff-7ff7b7918bc1deff4f3b463832a69185

  10. pavbaranov
    22 lutego, 2017 at 21:01

    Masz rację – pomyliły mi się 2 rzeczy. Swoją drogą, niebawem sprawdzę. Musi mi się tylko chcieć zbudować.

  11. KaCzKa
    22 lutego, 2017 at 21:18

    Oni są jak PiS, wiedzą lepiej jak ja chcę pracować. PiS wie lepiej ode mnie, że nie wolno mi zarabiać mniej, a oni wiedzą, że nie z roota. A co kogo obchodzi z czego ja pracuję, może mój system w ogóle nie musi być bezpieczny? Może nie jest to serwer trzęsący światem, tylko stary komputer do odtwarzania mp3?

    Nie można dać się zwariować.

  12. 22 lutego, 2017 at 21:22

    Chyba chodziło o wyjaśnienie składni polecenia. 😛

  13. 22 lutego, 2017 at 21:24

    Jezus Maria, facet wstawił dyrektywy procesora tak chamsko w kod, fuj.

  14. 22 lutego, 2017 at 21:53

    🙂

  15. Jan Zoń
    23 lutego, 2017 at 0:19

    Tak z ciekawości, bo już daaawno nie pisałem nic w C++, jak się to powinno zrobić?

  16. pavbaranov
    23 lutego, 2017 at 10:53

    Krótkie sprostowanie do: „Zmian należy oczekiwać w najbliższym wydaniu środowiska KDE Plasma 5”.
    Raczej nie. Kod odpowiedzialny za to jest częścią Kate/Kwrite, a nie środowiska Plasma. Powinien zatem pojawić się wraz z którymś wydaniem KDE Applications. Obecnie trafił do master. Co ciekawe, nie trafił (przynajmniej jeszcze) do nadchodzącego 9.03. wydania 16.12.3.
    Użytkujący paczki pochodzące od Kubuntu raczej w ogóle się nie muszą o to martwić, albowiem jeśli sami ich opiekunowie nie dodadzą tej poprawki, to istnieje marna szansa, by commit wszedł również w kod wydania Kate/Kwrite sprzed roku, a taka jest aktualność (a przynajmniej jeszcze z tydzień, czy dwa temu była) paczek KDE Apps w Kubuntu.

  17. Red Shoehart
    23 lutego, 2017 at 13:41

    Przy edycji używam nano lub GEdit

  18. 23 lutego, 2017 at 19:40

    Najlepiej oddelegować to do jakichś dwóch klas (zależnych od OS hosta) i potem wybrać dobrą używając dyrektyw tylko na jednej czy dwóch liniach z typedef (ew. using) zamiast szpecić właściwy kod.

    Potem może to poprawię i wyślę PR, bo strasznie gryzie w oczy.

  19. Hepita
    25 lutego, 2017 at 16:31

    Jakbyś jeszcze wiedział gdzie można nabyć wystarczającą ilość wolnego czasu żeby zdążyć tą grę to daj znać, chętnie się dowiem 🙂

    Na Steamie jeszcze mam kilkanaście gier które czekają na przejście do końca, łącznie to wyjdzie koło 120 godzin… Od początku tego roku grałem może 10 godzin 🙂

  20. Jarek W
    26 lutego, 2017 at 11:12

    Mam dokładnie ten sam problem ale jako fan Total War i Warhammer RPG nie mogłem sobie odmówić okazji do nabycia tej gry. Inna sprawa że na moim sprzęcie plansza potrafi się wczytywać nawet 5 minut co delikatnie mówiąc pozostawia niesmak…. 🙂

  21. Binko
    27 lutego, 2017 at 8:37

    Heh, ja w ostatnim roku pograłem w CSa może z 8 godzin… 😉

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »