Názory k článku
systemd-homed pro práci s domovskými adresáři

Zajimalo by me, jestli to bude umet dynamicky vytvaret home adresare uzivatelum, ktery se prihlasujou pomoci ssh certifikatu. (tj. ze je na serveru jeden CA klic a tim podepisuju klice userum)

systemd-homed mi dává smysl, poměrně pěkně řeší šifrování (a nemyslím vtip s přenosným domovským adresářem na flashce, který zřejmě nikdo nebude používat - a nebo by alespoň neměl).

To čeho se bojím je implementace, zejména oprávnění k souborům, nedořešené integraci do takových "maličkostí" jako sshd. Dost jsem se začal bát Lennartových slov jako "tohle nikdo nepoužívá" u věcí, které občas používám a dávají mi (aktuálně, neříkám že nejdou řešit jinak) smysl.

Např. všude je zakázáno přihlášení roota skrz ssh. Řekněme, že se potřebuji do počítače přihlásit skrz ssh v momentě kdy je uzamčený (tedy /home/%user% je nepřístupný) a pro takovýhle případ bych si měl zařídit speciální non-systemd-homed účet s ssh klíčem? Takže zbytečný účet navíc, po přihlášení se budu muset navýšit oprávnění, přihlásit se jako daný uživatel a teprve poté můžu použít ssh? To zní nepromyšleně... a nebo se prostě zapnu přihlašování heslem skrz ssh.. Yay!

Přijde mi, že pro BFU to nebude mít žádný dopad, ale slušně to uživateli systemd-homed ořeže některou funkcionalitu, která by mohla být zahrnuta do návrhu.

To je snadno řešeno správnou konfigurací sshd. Máte-li šifrovaný home a odemkne se až po Vašem přihlášení, je samozřejmě nutné veřejný klíč, pomocí kterého Vás systém autentifikuje, umístit jinam. Se systemd nebo jinou implementací to nijak nesouvisí, je to přece obecný problém. K tomuto slouží AuthorizedKeys­File v sshd_config(5). Hodnota na mnou spravovaných serverech je .ssh/authorized_ke­ys /var/db/auth/au­thorized_keys - tedy tradiční chování a fallback na centrálně spravovaný keyfile.

Na přednášce na DevConfu zrovna tohle zmiňoval jako jednu z největších bolestí homed, včetně možných řešení (a toho, že ideální by byla přímo podpora v openssh, se kterou ovšem zatím vývojáři openssh nepočítají). Rozhodně netvrdil že to nikdo nepoužívá :)

Slajdy (sice z jineho eventu):
https://cfp.all-systems-go.io/media/homed-asg2019.pdf

systemd má za cíl se stát základem pro distra od začátku a z velké části jím už je. V tomto smyslu se nejvíc dá přirovnat k projektu GNU, který taky sám není distrem, ale poskytuje velkou část infrastruktury, na které je možné distro založit.

Na první pohled se to zdá jako dobrý nápad, tedy minimálně pro "většinové" použití které v té prezentaci zmiňuje - osobní/rodinný notebook. Zároveň to ale u tohoto konkrétního případu nedává až tak moc smysl protože to toho tolik nepřináší.

Jen doufám, že se mýlím v tom jak jsem pochopil to fungování. Pokud jsem to pochopil naopak správně tak tam vidím dva zásadní problémy:
1) LUKS šifrovaný přímo heslem uživatele. Tedy ne klíč k disku šifrovaný heslem+certifi­kátem+... To by znamenalo, že pokaždé by bylo nutné použít heslo a cokoliv jiného by mohlo být jen další faktor.

2) Podepsaný pouze JSON a pouze jeho část. Co víc že podepsané jsou pouze části "regular", "privileged" a "perMachine". Zbytek je nepodepsaný a to včetně části "binding" a tedy i lokálního uid. Takže když budu mít přístup k tomu souboru domácího adresáře (třeba na flashce), tak by mě docela zajímalo co by se dělo pokud bych si v tom souboru upravil v bindingu uid=0 a gid=0. Udělá to ze mě roota? Podepsané a validní to bude pořád...

S druhým problémem souvisí i nepodepsaný image disku. Pokud důvodem toho podpisu je aby uživatel nepřipojil nedůvěryhodný image který by mohl nabořit kernel, tak mi stačí znát heslo uživatele a mít jeho domácí složku a můžu přece nahradit samotný obraz a hlavičku nechat - můžu si připojit co budu chtít i když na to nemusím mít jinak práva.

Pak tam vidím ještě jednu vlastnost. Jelikož "perMachine" je podepsané, tak pokud budu mít centrální systém pro správu uživatelů (KRB/LDAP apod.) tak na lokálním stroji nemůžu bez přístupu k privátnímu klíči serveru měnit alokace prostředků uživateli. Nevím jak to vidí ostatní, ale podle mě by ty bloky týkající se bindingu a jednotlivých strojů měli být v jejich části stromu podepsaný také a to buďto pomocí serveru/CA nebo tím strojem kterého se to týká.

U toho obrazu disku je to trochu rozporuplné - nepodepsaný je bezpečnostní riziko, podepsaný se zase nebude chovat úplně jak by člověk chtěl pokud bude poškozený při výpadku apod.