Le 10/01/17 à 14:37, Christoph Anton Mitterer a écrit :
On Tue, 2017-01-10 at 10:26 +0100, Laurent Bigonville wrote:
Well we need this to be integrated in cryptsetup if we want this to
work.
Especially in the security-relevant context it's IMO always
questionable whether everything should work automagically out-of-the-
box.
We need to balance the user friendlessness and the security.
So the only question here should be: does it introduce a security risk
or not.
And any software running as root can extract the key I think if the luks
partition is already open.
Do you have any specific concerns about enabling this automatically?
Anything in mind that might break?
Basically three:
- From what you wrote it wasn't clear to me, whether the auto-login
would happen per default, i.e. without the sysadmin (and not just a
user) enabling it, or not.
Many people (especially on not-just-single-user-desktop) may likely
not want such auto-login.
No, the user needs to explicitly enable the autologin. If the autologin
is enabled, the pam_gdm module will be called and try to retrieve the
password for the kernel keyring and use it to try to unlock the
gnome-keyring. And anyway even if gdm was enabling auto-login by
default, this is not a concern for cryptsetup.
- Security-wise it's particularly bad to made such sensitive material
as the key accessible to such a big piece of software-bloat.
Looking at gdm3 it has quite an amount of direct and indirect
dependencies including such which seem to communicate with the
internet (e.g. gdm3 built on top of gnome shell, which uses gnome-
online-accounts.
Such crucial things as the dm-crypt keys/passphrase should IMO be
used with as little as possible code.
- The whole "utopia" code has shown at least once that it may have
tremendous security flaws, I vaguely remember some hole in some of
devicekit/udisk/polkit, which lead to exporting the dm-crypt keys to
ever user (may be #576687, which I recall here... or something else).
Isn't that true for any pam service as the pam module code is run in the
process context?
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.
Instead of unconditionally adding the key to the keyring, why not just
including a keyscript in the package, which allows users to do just
that?
Maybe one can combine this with the already existing decrypt_keyctl.
a keyscript might be a solution but it would requires manual setup from
the enduser.
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
