[pkg-cryptsetup-devel] Bug#850756: cryptsetup: Please save password to kernel keyring

[Christoph Anton Mitterer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20170110/8fdb4f11/attachment.bin>