Red Hat Bugzilla – Bug 459116
anaconda needs to restrict certain encrypted device combinations
Last modified: 2013-01-10 02:56:45 EST
<halfline> pjones: so mganisin noticed something in #fedora-qa just now
<pjones> ... and it is?
<halfline> pjones: plymouth ask-for-password is getting called twice in /init
<halfline> once for / and once for swap
<halfline> this sort causes a problem
<pjones> are they on separate encrypted devices?
<halfline> i'm guessing so
<halfline> the problem is we don't have any way to differentiate the two until / is mounted
<halfline> and we can load pango, fonts, translations, etc
<pjones> ok... so firstly, they really shouldn't be getting set up that way.
<pjones> but yeah, that's a problem.
<halfline> so do we need to add some logic in anaconda to not allow that?
<pjones> probably, yeah.
<halfline> okay, i'll file a bug
<pjones> thanks. assign to dlehman?
It is not clear to me what the problem is here. Are you saying we should only allow users to encrypt one block device? Only root? Only swap?
It doesn't make sense for swap and / to ever have different passwords so that should be enforced in the UI.
Likewise (and this will probably take mkinitrd and/or plymouth changes) we should only ever ask for one password from initrd.
can ask for more after the root fs is mounted and we've switched root of course.
We want to avoid shipping fonts, font rendering libraries, translations etc in the initrd. This means we can only ever ask for one password via a lock icon and entry (no text).
If we had more than one password to ask for, we'd have to label them.
(and again it doesn't make sense to have a swap password different than / password)
Different passphrases for root and swap might not be convenient for us from a certain perspective, but do we really want to make it impossible for the user to set distinct passphrases for each encrypted block device? Seems like an arbitrary limitation to me. For one thing, the devices could have been created at different times.
Showing text in the initrd isn't really feasible, there isn't a good use case for them being different.
We shouldn't crash if the user does it out of band, of course, but anaconda shouldn't allow it either.
Maybe this particular case isn't best example for 'required/proposed' restrictions in installer. I see 2 different issues.
First, simple question. Is current behavior correct if system is asking more times for same passphrase for every particular encrypted block device during boot? It's more or less decision from security point of view and I don't see any significant relation to Anaconda.
Now let's identify the reasonable use cases. With relation to described issue I don't see any use case for swap encrypted with any concrete passphrase, it doesn't contain any persistent data (except of suspend-to-disk state, but it is completely different issue), random password should be enough in cases, when swap is encrypted separately.
So, posibility to set password for swap partition should be in my opinion restricted during installation and random password should be always used.
However, I see many other cases, which should be restricted during installation. There is no need for example to encrypt swap if it is logical volume of already encrypted volume group, double encryption could have impact to performance.
Swap should be always automaticaly encrypted, if encrypted block devices are used. Otherwise encryption doesn't make sense, swap could contain confidential data after shutdown.
For same reason, there is no use case for volume groups with combination of encrypted and plain physical volumes.
All claimed cases are allowed by Anaconda in Fedora 9 and none of these represent secure option. I believe Anaconda installer should guide a user to create working and secure layout.
Note the reason swap needs to be unlocked from the initrd is resume from hibernate. Otherwise it could just be unlocked from rc.sysinit after / is mounted.
see bug 459191 for the "same passphrase more than one time" question
This has been handled as well as possible for the time being.
Anaconda now uses one passphrase for all newly created encrypted block devices and also offers to add the same passphrase to any pre-existing encrypted block devices. This does not change the fact that plymouth needs to be able to handle other cases since users can configure things however they want manually.