Tails

#2 Updated by Gaff 2018-06-08 04:39:27

Hi,

Do comments on Rejected bugs get read?

The threat-model here is that at attacker steals your computer while it’s in operation - or (more prosaically?) you fall asleep while using tails. Locking the screen is the first line of defence against this, but it would definitely be far safer for the system to power down after being locked for x minutes. (Ideally something like blueproximity should be too - but lets make that a separate issue).

It shouldn’t be too tricky to implement either - a script that listens to gbus lock / unlock events and after x minutes shuts down the computer wouldn’t be too hard to write. If I were to write such a thing could it be added to tails?

Thanks!

#3 Updated by cypherpunks 2018-06-08 06:19:24

goupille wrote:
> from what I understand this use case is covered by the new screenlocker feature

I believe your understanding is incorrect. This is only true assuming a very limited attacker. The screenlocker is not at all difficult to bypass given physical access to a machine with no time limit.

Gaff wrote:
> Do comments on Rejected bugs get read?

Adding a comment to a ticket bumps it, so yes, they can be read.

> It shouldn’t be too tricky to implement either - a script that listens to gbus lock / unlock events and after x minutes shuts down the computer wouldn’t be too hard to write. If I were to write such a thing could it be added to tails?

That is true, and I agree with this idea. A simple setting to automatically shut down after X minutes of inactivity would be easy to implement (I imagine systemd can be made to shut the system down rather than suspend it after a certain amount of time has elapsed) and easy for users to understand and utilize. I would like to see this ticket re-opened.

#4 Updated by Gaff 2018-06-08 06:47:41

cypherpunks wrote:
> That is true, and I agree with this idea. A simple setting to automatically shut down after X minutes of inactivity would be easy to implement (I imagine systemd can be made to shut the system down rather than suspend it after a certain amount of time has elapsed) and easy for users to understand and utilize. I would like to see this ticket re-opened.

I’ve been digging around for a while. I agree that it would be way better to use standard gnome / systemd to do this but there’s a few issues:

• The gnome / gdm default action is to blank & lock the screen - which you can change to suspend or hibernate and probably to powerdown. However in tails’s case you probably do want to lock + blank a few minutes before powering down. This two-stage suspend is nonstandard for gnome.
• As far as I’m aware Xwindow’s idle timer is reset from user input even on the lock screen. This means a determined attacker could continuously provide user input to the lock screen until they could hack into it! :o

I’d love to be corrected - but given the two points above it might be better to create a custom script that listens for the lock events and fires a shutdown event.

#5 Updated by intrigeri 2018-06-10 10:16:14

> Do comments on Rejected bugs get read?

Occasionally. Very few (I believe: 2) people read all comments on Redmine.

#6 Updated by intrigeri 2018-06-10 10:17:34

This feature would break a number of use cases e.g. uploading big files overnight.

#7 Updated by Gaff 2018-06-10 10:26:09

intrigeri wrote:
> This feature would break a number of use cases e.g. uploading big files overnight.

True. Then again leaving tails unattended overnight implies other risks. (I mention blueproximity as a possible solution to this too, though out of scope for this ticket)

Would be simple enough to make this configurable. I’d argue that on-by-default is safest, but whichever.

#8 Updated by Gaff 2018-06-10 23:49:36

I’ve written a script to handle this: https://gist.github.com/Gaff/fab083771d316c783370c8582d0ab5f2

Any suggestions on how best to make it configurable?

#12 Updated by intrigeri 2018-06-14 14:51:07

Gaff wrote:
> I’ve written a script to handle this: https://gist.github.com/Gaff/fab083771d316c783370c8582d0ab5f2
>
> Any suggestions on how best to make it configurable?

At least as a first step I would say ship this script in /usr/local/bin and an example .desktop somewhere (but not anywhere that GNOME looks into). Then interested users can:

• either run it by hand when they feel the need for it (and not when they do need Tails to be running for a long while without interaction)
• or use the dotfiles persistence feature on ~/.config/autostart/ to add the new .desktop file there, if they want this script to run automatically during every session startup

And to be clear I don’t think we should add this as a supported feature (with doc and commitment to keep it working), but rather as “let’s be nice to those few users who want this, without spending too much time on it ourselves”.

#13 Updated by Gaff 2018-06-14 17:09:08

intrigeri wrote:
> At least as a first step I would say ship this script in /usr/local/bin and an example .desktop somewhere (but not anywhere that GNOME looks into). Then interested users can:
>
> * either run it by hand when they feel the need for it (and not when they do need Tails to be running for a long while without interaction)
> * or use the dotfiles persistence feature on ~/.config/autostart/ to add the new .desktop file there, if they want this script to run automatically during every session startup

OK - well in that case it’s good to go. Where’s a good place for the sample .desktop? The wiki somewhere?

> And to be clear I don’t think we should add this as a supported feature (with doc and commitment to keep it working), but rather as “let’s be nice to those few users who want this, without spending too much time on it ourselves”.

Well okay. Though if one were to go by the threat model doc Tails should guard against users who could be raided at any time. Given that the longer your machine is on, the bigger the window is to be raided - it follows that a feature like this ought to be included by default. Having said that I can see that switching this on might surprise existing users and so it needs to be brought in gently.

#15 Updated by intrigeri 2018-06-14 17:44:44

> OK - well in that case it’s good to go. Where’s a good place for the sample .desktop? The wiki somewhere?

Maybe config/chroot_local-includes/usr/share/doc/tails/examples.

>> And to be clear I don’t think we should add this as a supported feature (with doc and commitment to keep it working), but rather as “let’s be nice to those few users who want this, without spending too much time on it ourselves”.

> Well okay. Though if one were to go by the threat model doc Tails should guard against users who could be raided at any time. Given that the longer your machine is on, the bigger the window is to be raided - it follows that a feature like this ought to be included by default.

Well, if we learn that more people are interested into this we can reconsider.

> Having said that I can see that switching this on might surprise existing users and so it needs to be brought in gently.

:)

#16 Updated by sajolida 2018-06-23 18:39:39

I agree with intrigeri and I don’t think that this should:

• Be on by default
• Add cluster as a very visible option (Tails Greeter or such)

So, as a start, I suggest adding it as a short command line script that would be documented in /doc/first_steps/shutdown.

Maybe having to execute something like this to activate the deadman switch:

shutdown_if_idle 30

To shutdown automatically after 30 min.

Additionally, it would be good to have a way of knowing how popular this feature is without tons of work. As a way of knowing if it’s worth making it more visible and easier to use.

#17 Updated by Gaff 2018-06-25 06:24:16

sajolida wrote:
> Additionally, it would be good to have a way of knowing how popular this feature is without tons of work. As a way of knowing if it’s worth making it more visible and easier to use.

Any suggestions on how to measure this?

The real problem here is that users possibly won’t know they need this feature until they get hacked / arrested.

#18 Updated by sajolida 2018-07-05 18:40:18

> The real problem here is that users possibly won’t know they need this feature until they get hacked / arrested.

This feature can lead to people loosing data so I really don’t want to
have it enabled by default. I want people to learn that this feature
exist, weigh the pros and cons in their particular scenario, and enable
it knowingly.

> Any suggestions on how to measure this?

We sometimes use the technical information included in WhisperBack
reports to extract quantitative data. I did that on Feature #15265 for example.
The command line script I suggested in my previous comment could drop a
line in the logs for example.

Once we’ll have a prototype feature and a documentation page about it we
could compare the hits on this page to other pages.

Another approach is to understand better what our users do with Tails
and who they are, as a way of understanding, for example how critical it
is to support “leaving your Tails unattended for a defined period of
time”. But this is not something we can measure directly and might go
more through interviews, personas, surveys, etc.

• https://tails.boum.org/blueprint/interviews/
• https://tails.boum.org/blueprint/personas/
• https://tails.boum.org/blueprint/user_survey/