> On Jun 15, 2015, at 7:55 PM, spencerone@??? wrote:
>
>> Just to be clear, I believe this topic is about whether unencrypted
>> partitions on the internal hard disk of a laptop should be made
>> available while Tails is running from USB.
>
> I thought you meant local storage as in Tails' local storage, not the host machine's local storage.
>
> For the record, I did resolved the other issue with reasonable suggestions :)
>
> But yes, the host machine's local volumes should not auto-mount, as it is quite unpleasant to see stuff. However, even if volumes mounted after boot appear automatically, how best can people gain access to the host machine's volumes as desired?
>
> You suggest an admin-only function to discover and mount these volumes, how are you envisioning that would work?
I’m thinking that the person who begins the process of booting Tails from a USB drive can be presumed to have physical control of the machine at that time, and that one way or another, anyone with physical control of the machine can gain access to the machine’s unencrypted internal storage devices— whether through Tails or some other live USB distribution.
So it’s reasonable to give this person the choice between allowing Tails to access these internal drives at boot time, and the natural way to express that choice is to enter an admin password. I think that’s better than adding yet another boot-time question, anyway.
Without setting an admin password, there will be no internal-drive access. Even if an admin password is specified at boot time, it must still be re-entered post-boot when asking to see or mount the internal drives.
(As an aside at this point, unmounting a mounted internal drive should probably also require the admin password because otherwise there are some obvious denial-of-service risks, though I can see weaker arguments not to require it. And once unmounted, re-mounting a drive should of course require re-entering the admin password.)
At this point, that user (which I will call “the authorized user” here) could pass control of the machine to someone else (“the guest user”), either physically or via remote access, without relinquishing the authority to control access to the internal drives.
If the guest user gains full physical access to the machine, that user could reboot to gain access to the internal drives, but even here the authorized user retains the ability to confirm that this was NOT done by verifying that the authorized user’s previously selected admin password remains in effect.
A user with remote access would not be able to gain admin control by rebooting, so that isn’t a concern in that scenario.
That’s my thinking so far, anyway. Other inputs welcome.
Best,
. png
