On 25/02/2014 14:06, intrigeri wrote:
> 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.
thanks a lot for 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
yes, there is no precise design document. We should really write that.
> 1. There's a copy (or fork?) of
> config/includes.chroot/lib/live/boot/9990-misc-helpers.sh in your
I think it's just a copy
> 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 :)
Probably removing it is enough
> 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 :)
yep, this is horrible. We started improving this situation for 0.1.2,
but the firefox profile is far from clean.
The main difficulty we found was knowing how to set some preference in a
clean way. Some can be done using prefs.js, but it doesn't seem like the
only important file.
We never even tried to fix icedove configuration.
> 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.
correct, thanks
> 4. I could find no source packages on http://deb.freepto.mx/freepto/
uh, I never truly understood debian packages: why should we put source
packages on the repository?
> 5. I've found quite some shell scripts with very little error
> checking, if at all; maybe use "set -e" in this case?
can you give us an example?
> 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.
yes, that's a real mess.
> 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.
Mh, are you talking about
https://github.com/boyska/freepto-buildtools/blob/master/fabric/fabfile.py
? It's just a fabfile that will install all you need to compile freepto.
The goal was to also install utility scripts and configure utilities,
but this other things never got implemented
> 8. No Adblock Plus filters are configured => each user will add their
> own => makes each user easier to distinguish from the others.
This is a bug
https://github.com/AvANa-BBS/freepto-lb/issues/113
> 9. The default web browser seems to be configured to use Google's
> phishing detection service; is this on purpose?
We never truly made a decision about whether or not to use this kind of
services. A clear threat model will probably help.
> 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.
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?
see 9.
> 12. I suggest installing spice-vdagent and the qxl xorg video driver,
> for better user experience when run in a libvirt/qemu environment.
will consider, but my experience with qemu is really good at the moment.
> 13. You might want to mount /proc with the hidepid=2 option, to make
> some kinds of privilege escalaction attacks a bit harder.
cool
> 14. Any particular reason to run a full-blown MTA (Exim)?
nope
> 15. Any particular reason to run MiniSSDPd?
It is recommended by transmission, but I don't think it is really useful.
BTW, is there a simple way to not install recommends for just some packages?
I considered patching livebuild somehow, but then I got lazy ;)
> 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.
me neither.
> 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?
there is a plan to force password change on persistence creation
> 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.
good suggestion.
> 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?
yes
> 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.
good suggestion.
> 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
it should
https://github.com/vinc3nt/TORtp/blob/master/files/tortp#L100
but seems to me that some lines below that are buggy somehow. Will check
again.
> traffic, nor to whitelist connections to RFC1918. Not sure that's
whitelisting is missing, correct
> on purpose. I don't remember if it deals with IPv6, either.
It does not deal with IPv6
> 22.
ehi, it was a long mail, enough for now. If someone else wants to
continue...
intrigeri, thanks again for such a really useful review
--
boyska
gpg --recv-keys 0x58289ca9
