Hi,
> . png:
> From a UX perspective, I am curious what the reasoning is behind the
> policy of associating access to local storage devices with the entry
> of an arbitrary admin password.
>
For me, if someone stumbled upon my Tails, I would much prefer that they
did not have the "key", i.e., passphrase, to unlock the Encrypted
Persistent Storage partition.
But your inquiry is interesting. Are you suggesting that a different
kind of "key" would be more appropriate? Or maybe that a "key" is a
band-aid to the much larger problem of the wrong people having access to
the EPS partition, a unintended outcome of their display, and simply
isn't enough?
FIX
>
> In reality, there is no particular connection there. We can presume
> someone somewhere has the legal or moral authority to access the
> internal drives, but we have no basis to conclude that the current
> user is or is not authorized.
>
> This gives us two failure modes from one policy: A) an authorized user
> fails to gain access because he or she did not enter an admin
> password; B) an unauthorized user gains access by entering an admin
> password.
>
> Because the policy connects unrelated concepts, it can also mislead
> users. Someone might boot Tails without an admin password, not see the
> local drives, and assume that because Tails is a security-oriented OS,
> it never shows internal drives. Or someone might assume that Tails is
> like other Linux live distros that always give access to internal
> drives based on booting once with an admin password.
>
I think that, by the time people get this far, clear documentation on
what to expect should be sufficient enough to prevent this kind of
confusion.
>
> I think I’d prefer that we adopt a policy of not displaying the
> presence of (or auto-mounting) internal drives regardless of whether
> an admin password is entered at boot time.
>
> If a password has been entered, we should provide an admin-only
> function, whether in the GUI or on the command line, or both, that
> allows users to discover and mount these drives.
>
An adversary who gains access via the administrative passphrase
automatically has access to this admin-only function, right? However,
since the EPS partition passphrase and the administrative passphrase are
different, what you might be suggesting is a log in passphrase to access
Tails, followed by an EPS partition passphrase to access storage.
Maybe requiring people to set up administrative privileges to have
access to their EPS partition would address your concerns.
Can you expand on how your envisioning people discover the EPS
partitions? Maybe Tails uses gaming as an encryption layer?
We were thinking about displaying feedback upon input of a successful
EPS partition passphrase, does this fit into your threat model as an
added concern?
>
> If no password has been entered, this function should not be operable.
>
Are you suggesting adding an additional step to access the EPS
partition? I see the added layer of security, but with it comes an
added layer of complication, especially for our non-technical people.
Maybe there can be a specific type of flash storage combo that allows
for optimal security, e.g., a micro/nano USB stick w/ removable SD card
for added/expandable/modular storage. With this the EPS partition could
be physically separate from the OS.
>
> This solution avoids associating unrelated concepts and largely
> eliminates the potential for confusion.
>
Maybe. I find the confusion is with having two types of passphrases. I
would more willingly head towards having no passphrase protection and
allow people to establish log in and storage passphrases as desired.
Then I would probably head towards having one administrative password at
log in and allow people to establish storage passphrases as desired.
And just for fun, attached is a sample of what the EPS partition
interface could look like.
Wordlife,
Spencer
