[Freedombox-discuss] 2012.1209 Update, Nick Daly

[Nick Daly]

Hi folks, I had some spare time today and decided to write out where
things are with FreedomBuddy right now.  I've been helping Bdale with
Freedom Maker and the weekly images for a while, but until those get
sorted, I'm moving back to the FBuddy work.  In order to get my thoughts
straight, I wrote out this outstanding TODO list.  If anybody has any
input, feel free to speak up or take a TODO off the list.

----

FreedomBuddy's fallen down a weirdly fractal hole: each remaining task
creates another three, through some strange expression of the 80/20
rule.  So, here are the pieces I know of and what remains to be done.

The next goal is Field Testing.

Table of Contents
=================
1 Field Testing
    1.1 Peer Review
2 HTTP Connection Proxying
    2.1 HTTPS Certificate Validation
3 Multiple Connector Support
    3.1 Command Line Client
        3.1.1 ExMachina


1 Field Testing
~~~~~~~~~~~~~~~~

   The primary goal right now is to get the system into a field-testable
   state, so that it can be tested before it's made generally available.

1.1 Peer Review :security:
==========================

    Before being released for testing, FBuddy needs to be peer reviewed.
    First, though, it needs to be complete enough to be worth the peer
    reviewers' time.

    Any of the other features could be listed under this point.
    Currently, we can remotely configure OpenVPN over HTTP.

2 HTTP Connection Proxying
~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Proxying needs to be completed.  This will allow us to send
   connections through Tor and/or other HTTP proxies.  This is in
   progress in freedombuddy/src/connections/https/controller.py (line
   121), but there're some errors I haven't figured out yet...  Version
   skew, maybe?  I need to test on a fully Wheezy system instead of my
   development, Squeeze, system.

2.1 HTTPS Certificate Validation :security:
===========================================

    The standard Python library doesn't implement any HTTPS certificate
    validation.  HTTPS certificates are ignored.  This means that any
    system designed to bridge the gap between HTTPS and GPG (possibly
    relying on certificate pinning).

    This isn't, strictly, necessary: we're sending GPG-validated
    messages and don't also need to rely on SSL.

3 Multiple Connector Support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   I originally supposed I could wrap some best-practice libraries and
   have connectors for multiple protocols.  That quickly proved
   impossible, as nearly every library for every protocol wants to
   control IO and assumes that it's the only running library.  Almost
   every protocol's library blocks, which means it's generally
   impossible to listen across multiple protocols at once.  So, I need
   to use non-blocking libraries (or roll my own through, i.e.,
   Twisted).

   This is why there isn't a GNUnet listener yet.

3.1 Command Line Client
========================

    Building a command line client would make scripting really easy.
    Rather than reimplementing the wheel, I could just use an existing
    interprocess-communication library.

    I chose to use [BNewbold]'s [ExMachina] system, which is designed to
    enforce process separation between an insecure front-end and the
    nearly-root-level commands that are run.  EM acts as the admin
    account, performing system-wide modification tasks.


    [BNewbold]: bnewbold at robocracy.org
    [ExMachina]: https://github.com/bnewbold/exmachina

3.1.1 ExMachina
----------------

     During a code review of EM, I found a few issues.  Bryan is working
     on these, as far as I know.

* Write Limiting (EM socket file permissions) :security:

  Anyone can write to the socket.

* Client/Server Authentication Issues :security:

  Clients aren't required to authenticate to send the server
  instructions.  Clients who fail authentication kill the server.

* Password Storage Issues :security:

  Passwords aren't hashed in the server and are stored in plain text.

* Socket Replacement (EM socket directory permissions)

  EM sockets are stored in /tmp/: anyone who wanted to could overwite
  the socket with a new socket, killing communication between servers
  and clients.

  EM sockets should be stored in their own directory, with owner-only
  write permissions: only the EM user could change socket files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20121209/09a0d4c2/attachment.pgp>