Hlavní navigace

Vlákno názorů k článku Kernel lockdown: nová vlastnost ochrání jádro i před rootem od klokan - Lepší uzamčení jádra, než bylo dosud, je jasně...

  • Článek je starý, nové názory již nelze přidávat.
  • 22. 10. 2019 2:35

    klokan

    Lepší uzamčení jádra, než bylo dosud, je jasně potřeba, ale tohle mi připadá jako řešení typu "všechno, nebo nic". Lépe použitelné by mi připadalo, kdyby některé operace byly povolené pouze pro binárky, u nichž by se kontroloval digitální podpis. Třeba to bude možné v rámci tohoto frameworku implementovat?

    22. 10. 2019, 02:36 editováno autorem komentáře

  • 22. 10. 2019 7:00

    Vít Šesták

    Já toto vnímám jako první krok. Navíc jsou věci, které nemají smysl nastavit samostatně. Pokud může root nahrát libovolný (nepodepsaný) kernelový modul, může si dělat co chce a ostatní opatření půjde obejít. Na první pohled mi tedy režim integrity přijde jako minimum, které dává smysl. Režim confidentiality jde dál.

    Povolit některé operace pouze podepsaným binárkám – to by mohl být další krok, nicméně:

    * Aby to bylo smysluplné, je potřeba například zakázat rootovi i debugování těchto binárek. Takových věcí může být i více. V první řadě je důležité si všechny uvědomit.
    * Na takové binárky budou větší nároky než na ty se SUID bitem. U SUID bitu se musíme popasovat s upraveným $PATH nebo $LD_PRELOAD (mimo jiné). Tady bychom se nejspíš museli poprat i s upravenýma binárkama knihovem. Nebo vše slinkovat staticky.
    * Nakolik je tato vlastnost z kategorie „by se mohlo někomu hodit“ a nakolik to má přímo i nějaké využití?

  • 22. 10. 2019 8:11

    MartinX

    V AIXe je bezpecnostny problem "root moze vsetko" rieseny formou Trusted AIX.

    Uzivatel root je "vypnuty" a na administraciu sa pouzivaju 3 role, ktore su priradene 3 roznym uzivatelom/ad­ministratorom - ISSO(Information System security officer), SA(system administrator) a SO(system officer). Na vacsinu citlivych veci je potrebna spolupraca minimalne dvoch administratorov, napriklad ISSO nastavi parameter v konfiguracii a nasledne SO musi rebootnut system, pripadne SA vytvori uzivatela a ISSO mu nastavi heslo a role/autorizacie.
    Sucastou je aj pouzivanie RBAC (role based access control - to, kto moze citat, zapisovat alebo spustit subor, zavisi od jeho nastavenej role a nie od samotnych prav suboru) a podpisane binarky a konfiguracne subory. Subory, uzivatelia, tlaciarne, komunikacne a pod. rozhrania mozu mat pridelene "security labels" (uzivatel s maximalne povolenym pristupom "secret" sa nedostane k suboru s labelom "top secret" ani ak je jeho vlastnikom).

    Vzhladom ku komplikovanosti celeho systemu a nutnosti komplikovane nastavit bezpecnostne opravnenia, role a pod. prakticky pre kazdu pouzivanu aplikaciu, sa to snad pouziva len v armade, nevidel som Trusted AIX implementovany ani v bankovom prostredi (a to som spolupracoval snad so vsetkymi bankami na Slovensku, kde sa pouziva AIX).

  • 22. 10. 2019 8:37

    klokan

    Jedno z možných řešení by bylo definovat novou roli "nadroot". Nadroot by jako jediný měl přístup k jaderným rozhraním, ale mohl by spouštět jenom podepsané binárky (včetně knihoven), případně by mohl obecně otevírat jenom podepsané soubory (tj. včetně firmwarových blobů, konfigurací atd). Pro normálního roota by jeho procesy byly nepřístupné pro trasování i jinou interakci, tak jako jsou root procesy nepřístupné běžným uživatelům.

  • 22. 10. 2019 9:15

    Vít Šesták

    Ano, šlo by to řešit takto. Má to být již v první verzi? Nemyslím si. Toto (stejně jako režim confidentiality) jde za hranice MVP. Takovéto věci patří spíše až do dalších verzí.