[Freepto] Initial comments

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Dla: freepto
Temat: [Freepto] Initial comments
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