In these 2days of "hands on tails" we explored how tails is done in more
detail, how it (does not) fit our usecases and what we can do to make it
better. Our goal is to make freepto a (as small as possible) "patchset"
on tails. This will make us able to keep the pace that a
security-oriented distro needs, collaborating with the broader tails
community and then releasing freepto applying our patches on it. Yes, I
am oversimplifying, but you get the idea.
The first part of the minutes is devoted to briefly explain our
exploration results. The second is for proposal we want to do to tails
community, since we believe that they improve each other. Follows a bit
more notes about the hacking days.
Exploration results
===================
* Greeter & password. In tails, user password is chosen at each boot. We
find that if a user has a "home persistence", she should suppose that
her password is persisting, even if technically this is totally
unrelated, and not something that belongs to $HOME. We want to make it
the default that the user password (or her decision not to have one)
is persisted. We also want to keep it possible to change at boot time
(for example, because it has been forgotten, or because she wants to
disable/enable it). We want to do it with as few changes to the
greeter as possible. Especially, without rediscussing the UX with
tails too much.
* The network configuration is different from ours, but not very
invasive. We might quite easily change it, since it's enforced just
through iptables. The only problem that we found is that resolvconf
has some hacks we cannot understand, so it doesn't take any nameserver
from DHCP. We need to further investigate this.
* Persistence is handled differently: one has to choose exactly what
needs to be persisted. This doesn't fit our "quick bootstrap" UX idea,
so we decided that a "persist all /home/amnesia" could be a good
solution: making the whole system persist was not really needed for
any practical use case. The only point about system persistence is
making packages persistent, which Tails persistence setup already
includes support for. However, we found this support to be less than
optimal, because it requires some skill. We have some idea to improve
it, and will improve later, and submit to tails because they probably
fit their use case, too.
* The UnsafeBrowser is too safe for us :P We don't like how difficult it
is for a user to download a file into her home, or to upload a file
from her Documents directory. While we'd want to keep some isolation
measures, we want to improve on those usecase. Some idea below.
* Migration to icedove is already considered by tails. Since our threat
model is definitely different, this might be easier for us. We found
it important not to change MUA, so we really want to provide icedove.
Build system
============
We considered that it was better to start from a jessie-based tails to
avoid having to re-do the migration soon. However, we are uncertain
about the stability, the testedness and the ETA of this, so we might
switch back to "fork" a wheezy-based tails instead.
We found it difficult to build feature/jessie branch. Actually, we
hadn't managed to successfully build one, while we were able to build
the current "stable" branch. We don't know if this is because our build
system isn't correctly setup or if there are some bugs we aren't aware
of.
UX ideas and other proposal we have for tails projects
======================================================
greeter
-------
Password handling
~~~~~~~~~~~~~~~~~
Our UX would be this:
* if there is no persistence, anything is like tails
* when you create persistence, the shadow passowrd is saved into persistence
* if you provide persistence password, then:
** if you say "no" to more options, the password is loaded from persistence
** if you say "yes" to more options, the password is overridden with
what you write into the "more options/password" form.
To do this, we need to be able to get the value of the "more options"
button into a hook, or a subsequent script. Not just the field contained
in the more options form, but also whether the more options button was
triggered or not!
Password form
~~~~~~~~~~~~~
We found that the password form could be clearer if it was composed of
YES/NO part to decide whether to provide a password and a separate form
which is showed/enabled only when the togglebutton is set to "yes". This
will make it more explicit than saying that a blank password corresponds
to "password disabled".
tails-persistence-setup
-----------------------
We want to replace the "persistence presets" currently provided by tails
with some other. Most of all we want to provide a new preset "home" that
make /home/amnesia persistent, and which is enabled by default. When
this is persistent, many other presets are bogus (persisting bookmarks
is irrelevant if the whole home is persisted), so we want to remove
them for better usability.
To accomplish this we wrote some patches that make the preset part
completely pluggable. So the whole package would be split in a
persistence-setup "main package" plus two other packages that could be
persistence-setup-presets-tails and persistence-setup-presets-freepto.
The patch is still a bit rough, but it will probably be published soon.
We haven't figured out how to package it (is jessie needed?).
packages persistence
--------------------
At the moment, package persistence is done as explained In
https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html#index14h2
This means that a user must write a text file containing one package
name per line manually.
Our idea is to have a apt hook that when a user installs a package
interactively propose her to make it persistent (that is, to append its
name into that text file).
Some notes
============
Unsafe Browser
--------------
Our main usecase is to make it easy for the user to read file (like to
upload it) or to download it.
This could be done limiting its permission to "read" on every file in home,
(excluding .*) and permitting to write only to $XDG_DOWNLOAD_DIR.
AppArmor or lxc came to mind.
resolvconf
----------
resolvconf seems just to drop the nameservers provided by dhcp. It KNOWS
of them, because its IP is found in some (don't remember which) file in
/run/resolvconf/**
There is a point when these entries are dropped, but we cannot find it.
build errors
------------
We found many different errors, usually involving the fetch of apparmor
profiles. Sometimes we got 502 Could not store data (an apt-cacher-ng
error). Next time we tried, 'Hash sum mismatch' happened.
We needed to change the
config/chroot_local-hooks/19-install-tor-browser-AppArmor-profile
in this way:
- apt-get source torbrowser-launcher/testing
+ apt-get source torbrowser-launcher
we supposed that the "testing" field was a leftover from wheezy times,
but we are not really sure that this change improves the situation.
Things that we don't care of
===========================
We found some software that we don't think is needed for our usecase.
i2p and electrum are between those. If they are easy to remove, that
would make freepto "more specific" to what we need, but otherwise it's
not a problem.
Happy hacking!
--
boyska
