Продолжение размышлений о "
Reinventing Home Directories" by Lennart Poettering, см. слинкованный пост.
lennart-poettering via
Reddit:
Well. Homed is intended primarily for client machines, i.e. laptops and thus machines you typically ssh from a lot more than ssh to if you follow what i mean. With systemd-homed access to the home directory is simply impossible unless the luks keyphrase (aka "user password") is specified (i.e. tje user logged in) since the data store is after all fully encrypted unless the user logs in. Thats a good thing btw: the user's data should be protected from the system unless the user is actually logged in. Now, ssh public key auth doesnt deal with passwords hence just using ssh pk auth means we couldnt unlock the luks volume simply because we have no keyphrase to unlock things with. So the PAM module that unlocks homed volumes actually enquires the client for the password explicitly if this happens. Unfortunately this is not sufficient for this to work with openssh since its pam hook-up doesnt support asking questions via pam after authentication.
Несколько тезисов на полях о новом systemd-homed:
- является опциональным решением для управления домашней директорей пользователей, и предназначено для десктопных пользователей линукса, преимущественно на ноутбуках или рабочих станциях, но не для серверов;
- не позволяет получить доступ к домашней директории, пока не будет введен LUKS-пароль; таким образом, доступ к пользовательским данным защищен от самой системы (сегодня FDE [full disk encryption] или LUKS обеспечивает безопасность только для data on rest);
- препятствует удаленному SSH-доступу (подразумевается, что homed не будет использоваться на системах, где нужен удаленный доступ), однако остается возможность добавить системного stub-юзера, затычку, через которого будет воможно войти в систему удаленно по SSH, и уже через него авторизоваться в своего локального пользователя (в таком случае пользовательские креденшелы останутся в системной памяти, но именно так оно работает сегодня, так что жаловаться не на что);
- обеспечивает более высокий уровень безопасности засчет изоляции домашнего окружения от системы и тесной интеграции 2fa/аппаратных ключей для авторизации; опциально домашний раздел блокируется при лок-скрине (
go-luks-suspend на стероидах);
- пользовательский файл .credentials подписывается ключем и недоступен для изменений, а его поля расширяемы;
- дает отличную переносимость домашней директории между машинами, потенциально существенно облегчит сетевую инфраструктуру для тонких клиентов;
- бекап домашней директории станет гораздо легче;
- да, это не unix-way, но современный мир диктует новые решения;
-
существует проблема безопасности маунта домашних директорий как loopback блочных устройств —
poettering: Yes this is a problem. To address this systemd-homed is careful to validate the user record enclosed in the volume first (which includes checking its signature against the keyring of accepted record signers) and checks whether the provided user password can unlock it. Only after this validation and that the fs actually matches the record we will mount it. Thus as long as the employer trusts its employees enough things should be reasonably safe. (To make this happen the user record is embedded into the LUKS2 header metadata so that we can use it before mounting the fs); ну, посмотрим 🤷♂️;
Список не полный и, вероятно, не очень точный в деталях — не стоит на меня ссылаться. Буду обновлять по мере появления новых интересных деталей, и пока телеграм позволит редактировать пост [
upd. достигнут лимит на длину поста, сорян].
