Hi,
sorry for the delay…
linux-service:
> More and more business customers ask to disable usb on their notebooks
> for security, so we have no option other than work with grub and iso.
Got it, thanks. Please disregard my question about "blocked USB ports"
on the other, private discussion. I assume they also ask you to disable
any micro SD slot the laptops might have, right?
I understand that if we supported installing Tails on the hard drive,
this would satisfy your needs. We're very close to removing one
major blocker for this (incidentally, thanks to the USB image project).
I'm not sure how much initial work and maintenance it would take
to fully support this use case. I would be happy to take a look
if we knew this work could be funded ;)
> We working with iso's:
> menuentry "tails" {
> set isofile="/iso/tails.iso"
> loopback loop $isofile
> set root=(loop)
> linux (loop)/live/vmlinuz boot=live iso-scan/filename=${isofile}
> findiso=${isofile} apparmor=1 nopersistence noprompt timezone=Etc/UTC
> block.events_dfl_poll_msecs=1000 splash noautologin module=Tails
> slab_nomerge slub_debug=FZP mce=0 vsyscall=none page_poison=1
> union=aufs quiet toram
> initrd (loop)/live/initrd.img
> }
I see that you're removing live-media=removable, as expected. As said
before, this implies full trust in the internal hard drive, which is
something the users might not be expecting when using Tails. I'm not
sure how best this should be dealt with. I think this needs a little
bit of UX design.
> We have created a bash script with gksu or pkexec for the user for
> updating their tails iso :
> #!/bin/bash
> cd /iso
> gksu -- bash -c 'xterm -e "rm tails.iso; wget
> http://95.211.190.99/astick1804/tails.iso"'
This upgrade method is significantly weaker than the initial
installation and upgrade paths we document and support:
- Due to the use of cleartext HTTP and no verification, it's
vulnerable to an active MitM attacker.
- No verification is done, while all our supported installation and
upgrade methods verify at the very least checksums served over
HTTPS from our own website (which is trusted in our thread model).
Do you make this clear to your users in any way?
I'm worried they could be assuming "it's Tails, thus it's safe"
while running code that does not meet our standards. This could
harm them and the Tails "brand".
Instead of trying to communicate about this weakness to users, I think
the best way is to:
- Either let them follow the Tails official documentation for
downloading, which gives you verification for free. It works at
least in Chrome and Firefox. And them have them use your script for
installing the upgrade.
- Or add verification to your upgrade script. The best way to do that
will change soon and the corresponding design doc will be updated
on our website on Jan 29. Meanwhile, check out this file, that's
used by our "Tails Verification" browser extension to verify the
ISO image downloaded from untrusted sources:
https://tails.boum.org/install/v2/Tails/amd64/stable/latest.json
> We have also a script for updating grub's 40_custom.
Good :)
> I am donating to tails per sold computer.
Thanks!
Finally, I'm still interested in your answers to these questions of
mine:
> Op 31/10/18 om 11:06 schreef intrigeri:
>> - Do you communicate to your clients, somehow, that the way you're
>> installing this Tails system is unsupported by the Tails project
>> and the resulting system may behave differently than a "real" Tails?
>>
>> - The Tails user experience relies more and more on our opt-in
>> persistence feature. While we still support read-only Tails, be
>> aware that you're shipping a flavour of Tails with a restricted
>> feature set. It would be nice to communicate this to your users
>> and point them to our doc about installing a full-blown Tails :)
Cheers,
--
intrigeri
