On Tue, 2017-01-10 at 17:28 +0100, Laurent Bigonville wrote: > We need to balance the user friendlessness and the security. I think having something like a keyscript, which needs to be manually enabled by root, is friendly enough, isn't it? It's the e.g. the same as with libpam-krb5 - that doesn't just happen unconditionally but at least requires installation of that extra package.
> So the only question here should be: does it introduce a security > risk or not. Well not necessarily in the sense of a concrete hole/bug - I'm rather talking about an increased attack surface. > And any software running as root can extract the key I think if the > luks > partition is already open. Not sure about that,... probably... but maybe not under things like SELiux where even root can be restricted. IIRC, at least normal cryptsetup binary still requires a valid key[file] when doing operations like dumping the master key, even if the device is already mapped... or do I remember wrong? > No, the user needs to explicitly enable the autologin. hmm that's IMO already unfortunate... I think only root should be able to do such thing. > Isn't that true for any pam service as the pam module code is run in > the > process context? In which sense? pam is rather small, less code - less attack surface. > Note that only the gdm-session-worker process is running as root, > gnome-shell and the rest is running as Debian-gdm user and thus > doesn't > have access to the root user's kernel keyring. Sure, but still a bigger attack surface... one never knows by which update such sensitive information is e.g. passed on via IPC... > a keyscript might be a solution but it would requires manual setup > from > the enduser. But this isn't too much, is it? And apart from that, running a "fully encrypted" system (and desiring to single-user-auto-login with that) IMO only makes sense if the owner of the system keeps something like a USB stick and boots from it for many attack scenarios. The notable exception is random theft of the device. For any attack, where the owner is specifically targeted, the attacker would rather simply exchange the (unencrypted) kernel on the harddisk with a rogue version - which is why one needs to boot from USB (and always have that with oneself) in order to circumvent this (more or less). This setup however, requires anyway manual steps by the user/admin. > Note also that the decrypt_keyctl script is also using the kernel > keyring to store the keys, so for a security POV it's the same IMHO Sure, but it's still something and admin needs to enable. btw: One could also think about all this possibly allowing some where obscure attacks. Imagine a system where the a valid local user (who tries to attack dm- crypt) has no physical access to the storage devices. He also has no access to the dm-crypt device i.e. he cannot even try to manually set up/guess the dm-crypt key. Now when he's the one (an not root) who controls that exporting of the dm-crypt key respectively it's use in auto-login respectively whether auto-login is performed for his user acc... one can imagine that this can be used to guess&confirm the passphrase - simply by changing the user password and trying whether auto-login succeeds or not. Sure, this is likely not a practicable attack, but it kinda shows that such things may have tremendous security impact in special setups - and I'm rather scared about attack vectors I cannot imagine ;-) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
