-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrik Hagara:
> On 07/24/2017 04:40 PM, Rusty Bird wrote:
> > I was wondering about RW->RO downgrades too (didn't realize you
> > were already working on this part...), and came up with the
> > following tweak: Currently, the unseal script will mount the
> > device, do its work, and unmount. But it could be rearranged to
> > mount, copy the sealed secrets to /tmp, immediately unmount, do its
> > work, and at the end, check if the user removed the device. If
> > that's the case, the unseal script can create a file in /run to
> > skip -seal.service via "ConditionPathExists=/run/...".
> >
> > This would prevent the easy downgrade, and it seems pretty
> > natural, UX-wise, to remove the device early if you don't want to
> > reseal. Probably much less code, too?
>
> Not sure about how natural it would feel... I'd say the best UX for
> removal of AEM media would be to _wait_ for the user to decide, ie.
> print a message and wait either until the device is removed or the
> user decides not to do so via a key press (_not_ a timeout).
Definitely no timeout! But AFAICT an _additional_ key press isn't
needed either, because there are already some suitable sequence points
in (a slightly rearranged) -unseal for both schemes, static text and
2FA. Here's a drawing of the proposed -unseal sequence:
static: showing secret pressed Enter to hide secret
\ /
11111111111111111111 222222222 3333333333333333333
/ | \
2FA: showing OTP | keyfile pw entered
|
prompting for keyfile pw
phase 1: mount; copy sealed secrets to /tmp; unmount; check freshness
phase 2: noticeable use of secret; it's safe to remove the device
phase 3: inform -seal.service if sealing should be skipped; finish
This only covers the case where unsealing and the freshness check was
successful. But if not, and yet the user still wants to continue
booting with an RO AEM device for some reason, then we can simply rely
on the "Failed to seal ..." error message in -seal. (Which would only
have to be tweaked to require an Enter key press to continue booting,
so that it can't be missed.)
> Explicit is better than implicit, as the Python saying goes.
That's a solid guideline for code. But if I understand it right, it
can be problematic for UIs:
- - If dialog help messages explicitly cover all possible scenarios,
they quickly turn into this massive, fatiguing wall of text that has
to be read on every boot... IMO each idea to be conveyed in these
messages, and each word used to phrase it, should be treated as
costly (= taking time to read and comprehend, maybe even confusing
some users). Like Dijkstra's "lines [of code] spent", but for text.
- - If menus require an explicit choice between every possible option,
that's less efficient than defaulting to the most likely option (and
allowing the user to switch to the other options). For example,
imagine a version of Firefox that doesn't focus the address/search
bar on startup, but shows a series of Doom-style menu screens:
+-------------------+ +---------------+ +----------------------+
| | | | | |
| FIREFOX MAIN MENU | | OPEN A PAGE | | OPEN A PAGE ONLINE |
| | | | | |
| * Open a page | > | * online | > | from URL |
| Settings | > | from file | > | * via search engine |
| (...) | | | | |
| Quit | | | | |
| | | | | |
+-------------------+ +---------------+ +----------------------+
... and on and on. ;) I feel like the normal case should be
optimized to take as few steps as possible.
> >> And while we're at it, why not also extend the boot device label
> >> into a PCR -- what if the attacker covertly changed the label and
> >> the user then used this AEM media? There's risk of DoS attack by
> >> filling up the NVRAM freshness token area, or worse, overwriting
> >> other AEM media's freshness token hash (thus preventing it from
> >> being used).
> >
> > Booting from an attacker-modified AEM device is dangerous anyway,
> > e.g. there could be exploits against the ext4 filesystem driver.
>
> Yes, but while the ext4 exploits are theoretical, the DoS I outlined
> would be guaranteed to work.
True.
> > But when extending a PCR with the label is only one or two lines
> > of code, why not indeed. :)
> >
> >> Changes pushed
> >
> > Thanks! I'll try them out later this week.
>
> No rush, I'm still churning out small fixes.
>
> After a code-prettifying pass though, I'd be interested in some code
> review again. :)
Sure! It can wait until you think it's ready for review.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJZd311XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfH2AP/2AJD+0gykgRmugSeKoTVBdm
TORsvNrs4trY+rjAEkso+8oagzHmGnaoRevh8LFIshCfIZnNvp1R+/CF8o2iyBlp
9FvQgCAXbMbtDcthorrG51ILPk2apshn2pbQlVf/YJmV2cJEdWKnGuIIxqzla5vq
rvudNrLMXEHBCT2ODurSgM24dxTe6Sr2K25gaxOM9XLE1OeCcncdLKxGrr6lzpbV
V7ZYnc7OKrJEG0Xa8nzR4Ut7v67DloNXzxHwDwfbK4/KjKIDQzhAJcvDnEzfzkcd
uzAaxWrQ5qXs+1K1XTQmVYfSalhOrmpRwcXfsQR6p0UL0RlEPci2cSkdp3kowq5L
in/ZP2aGPzmrF0RWlaJKXIBK56NDGm0Df/uTSiCJ4e6GlHQ6kxUXaPxDNmqKKW/L
l0PAonI9zJWOKXDjjr10fPjcDW+C/0jCsjsv3SEaa7vfin0kXqOSWg+eXuKUWtr+
776PK8bhws40uTzbPQ1DQ3tdRNgyX+J9BXSL8Xw6GDi2QGvJfbrT2EwLcdTYZe4t
QnyJPn3IsNlya0BNf+13s6O27H9mhYMoSPE80jGd3M/VD9ZZuyzdAS9hayqqpZeM
K5UEdfRu13CYCbIubvPiBZvP0ggU9ojiNjAAkfj8UlRp6QdqbLD0uye6C7f98DFo
yIlKP5LaZEXwWl3bOAP5
=awGI
-----END PGP SIGNATURE-----