Hi,
I've had a look at the code in current Git HEAD, and tested Freepto
0.1.2 a bit. Here are some comments. I'll let you evaluate which ones
are serious and which ones are minor/wishlist, depending on your
threat model. I'm sorry for the brain dump, and if you prefer me to
create a bunch of tickets somewhere, I can also do this.
0. What I've found to be the hardest thing when looking at Freepto was
the lack of design goals clearly documented in a language I can
read. I warmly encourage you to write this down somewhere, even in
a concise form to start with (i.e. there's probably no need to go
as far as
https://tails.boum.org/contribute/design/ right now):
what the attacker you assume can do, what they cannot do, what
you're trying to protect. I've found that having such a document
makes it incredibly easier, e.g. for us to reason on "would this
change be safe?", for others to audit our stuff, etc.
1. There's a copy (or fork?) of
config/includes.chroot/lib/live/boot/9990-misc-helpers.sh in your
source tree. Note that this code was primarily written by Tails
developers, and upstream'd so that it could be shared by similar
projects who might need it; if you are improving it, it would be
awesome that you shared your improvements, possibly by making the
upstream code flexible enough to handle your usecase :)
2. There are plenty of binary files in Git in the default Iceweasel
and Icedove profiles: that's pretty hard to audit, and makes it
a pain to track changes in Git. We've managed to stop doing so in
Tails a few years ago, so if you want to get rid of that and find
it difficult, or need advises on specific problems, feel free to
have a look at the Tails source tree, or to ask me :)
3. I suggest setting up APT pinning to ensure only the packages you
want are fetched from deb-multimedia.org, instead of any arbitrary
one they might arbitrarily add to their repository some day.
4. I could find no source packages on
http://deb.freepto.mx/freepto/.
5. I've found quite some shell scripts with very little error
checking, if at all; maybe use "set -e" in this case?
6. There's some config duplication between freepto-config.sh and
auto/config. I suspect that one day or another, someone change will
modify one of these and forget the other.
7. It is unclear what the fabric thing is for exactly, and how to use
it (e.g. is dotdeb.org really needed to set up a Freepto build
environment?), but I might have missed the relevant documentation.
8. No Adblock Plus filters are configured => each user will add their
own => makes each user easier to distinguish from the others.
9. The default web browser seems to be configured to use Google's
phishing detection service; is this on purpose?
10. The default web browser's homepage allows easy detection of
Freepto users by a network attacker; but perhaps defending against
this is not part of Freepto's threat model.
11. Perhaps the default web browser's search engine could default to
Startpage or DuckDuckGo instead of Google?
12. I suggest installing spice-vdagent and the qxl xorg video driver,
for better user experience when run in a libvirt/qemu environment.
13. You might want to mount /proc with the hidepid=2 option, to make
some kinds of privilege escalaction attacks a bit harder.
14. Any particular reason to run a full-blown MTA (Exim)?
15. Any particular reason to run MiniSSDPd?
16. It's nice to see how little RAM is used by default. Congrats!
No idea what the drawbacks of using XFCE (compared to GNOME) are.
In particular, I'm not sure how good XFCE's support for
accessibility tools is.
17. Having a default sudo password makes it a bit too easy, maybe, to
go from "arbitrary code execution in Firefox 17" to "persistent
rootkit installed". Any plans to disable it by default, or to
force the user (e.g. in case they have persistence enabled) to
change it?
18. The passwords changer does not exit after successfully changing
the user password. The resulting UX is confusing: I wasn't sure if
it had really worked at all.
19. I find a bit confusing the amount of available ways to connect to
the network (iodine, OpenVPN, Tor, not counting the "VPN over
obfsproxy idea"), but perhaps this merely reflects the fact that
no clear threat model and design goals for Freepto exist at
this point?
20. I recommend using http.debian.net instead of cdn.debian.net for
the Jessie sources.list snippet. The former is way more reliable,
and is very likely to entirely obsolete the latter soon. Note,
though, that both work pretty badly when the Tor DNS resolver is
being used (e.g. after running the tortp script): you get tons of
hashsum mismatches, caused by a hashsum file being fetched from
one mirror, while one of the corresponding files is fetched from
another mirror, and those two mirrors not being
perfectly synchronized.
21. I only skimmed over it two days ago, and I'm currently offline so
I cannot check, but iirc tortp does not seem to neither block UDP
traffic, nor to whitelist connections to RFC1918. Not sure that's
on purpose. I don't remember if it deals with IPv6, either.
Sorry if I'm entirely wrong :)
22. Regarding transparent proxying through Tor, we have stopped doing
that a while ago in Tails. I'm not sure if this applies to
Freepto too, but transparent proxying had two drawbacks for us:
1. it grants access to the network to applications bound to any
network interface (e.g. eth0 or ppp0), so if the application leaks
(e.g. in application layer packets) the local IP address it knows
about, it may be leaking the IP address on the LAN (which might be
identifying sometimes, and at least allows linking activities
together), or worse (in the case of ppp0) the public IP address on
the Internet. 2. It somewhat lets the user believe that any
application can be used safely with Tor, without special
configuration, which is clearly untrue.
23. Using persistence-media=removable-usb, you'll soon enough be
affected by the same problem as Tails caused by vendors such as
Sandisk now shipping USB sticks with the removable flag set (in
accordance to the USB standard, but mainly to be allowed a fancy
Windows 8 logo): https://labs.riseup.net/code/issues/6397 We have
a plan to deal with that, and perhaps we could collaborate to add
the missing bits to live-boot, and upstream it?
24. I see you disable TCP timestamps. We're thinking of doing the same
in Tails. Any drawback of doing so you would be aware of?
25. Does anything prevent live-* to use a cleartext swap partition
found on an internal hard drive?
26. Whenever you want to consolidate the disk images you build, and
ship a single multilingual one, you might be interested in the
Tails Greeter: https://git-tails.immerda.ch/greeter/ (the version
adapted for Wheezy, with the code cleaned up a bit, lives in the
wheezy branch); I guess it wouldn't be too hard to make optional
the bits you don't need, and add some flexibility to add your own
stuff. Note that the UI is clearly suboptimal at this point, and
me have plans for a major revamp:
https://tails.boum.org/blueprint/tails-greeter:_revamp_UI/ (we
also have a ticket about it in Redmine, but I don't seem able to
find its ID while being offline). A human-computer interaction
expert will help us. I would personally be delighted if we could
collaborate on this project.
27. Maybe install bash-completion?
28. Regarding AppArmor support for union filesystems, if one of you
wants to be in the loop of the discussion we're having with an
upstream AppArmor developer who's working on it, please email me
your OpenPGP public key (with a trust path, ideally).
29. I'm part of the people who are currently bootstrapping two Debian
teams that might interest you:
https://wiki.debian.org/AppArmor
https://wiki.debian.org/Teams/OTR
Note that one may help in very diverse ways, e.g. by testing
stuff, or doing bug triaging. No need to be an experienced Debian
maintainer to give us a hand :)
30. I'd like to increase the amount of collaboration between the Tails
and Freepto project. I've subscribed to the Freepto mailing-list,
and I now sometimes idle on your IRC channel. You're most welcome
to subscribe to the tails-dev mailing list
(https://mailman.boum.org/listinfo/tails-dev), and/or join the
#tails-dev IRC channel (OFTC). There's also #tails, but the
signal/noise ratio is quite lower. Note that most Tails developers
don't use IRC so much, so basically everything is discussed and
decided over email, and on Redmine.
31. If there's work you do that you would like to upstream in Debian,
and in case you need help / mentoring / sponsoring, feel free to
ask me. But I'm sure you already know plenty of other Debian
developers who are eager to help :)
See you soon, ad keep up with the good work! :)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
