[Freedombox-discuss] Policy questions

Jonas Smedegaard dr at jones.dk
Sun May 8 09:00:35 UTC 2011


On 11-05-08 at 10:10am, Rob van der Hoeven wrote:
> On Sun, 2011-05-08 at 06:52 +0800, Sandy Harris wrote:
> > Rob van der Hoeven <robvanderhoeven at ziggo.nl> wrote:
> > 
> > >> A standard tactic for security is isolation of services.
> > >> ...
> > >>
> > >> Clearly we cannot expect to use a separate machine
> > >> for each FB service, but we need some strategy that
> > >> limits the damage if any one service turns out to have
> > >> a security flaw. Some list posts suggest using virtual
> > >> machines, and that is one plausible solution, though
> > >> costly.
> > >
> > > Hi Sandy,
> > >
> > > I am the one that suggested virtual machines, and i am using them at
> > > this moment. ...
> > >
> > > In my opinion building a FreedomBox without using VM technology is very
> > > dangerous.
> > 
> > To me, the question seems more complex and still open. It is
> > clear that we need strong security, and therefore a carefully
> > designed strategy for isolation. It is not clear to me that VM
> > techniques are the way to go.
> > 
> > There are plenty of other candidates. The OS provides
> > mechanisms intended to do what we need, process
> > isolation, chroot, file permissions and so on. There are
> > extensions like SE-LInux and GRsecurity that give
> > more.
> > 
> 
> You are right. A competent sysadmin can build a secure system without
> using virtualization. I don't think that an average FreedomBox user can
> manage the more advanced security features that you mention. So, must
> they become dependent on FreedomBox security experts every time they
> want to install a new service that connects to the internet? That's no
> freedom to me. In my design i use VM's as sandboxes. Users are free to
> install whatever they want inside a VM. 

Sure, users are free to whatever with their FreedomBoxes - it is Free 
Software.

But the FreedomBox is a *subset* of Debian with additional constraints 
especially on user-friendliness.  I do not consider "aptitude install 
whatever your heart desire" as especially user-friendly.

I envision that we decide on some pieces in Debian, work with the 
maintainers of those pieces to make them possible to not only be 
installed in the "aptitude install, tinker with configfiles until happy" 
fashion that we are used to, but also supports hooking up with a 
dead-simple design which we invent - or (hopefully) discover that others 
have invented and convince someome to package and maintain in Debian.

So I expect the "dead-simple" interface of FreedomBox to only be able to 
add/remove - or enable/disable if there are so few that it makes sense 
to inlude them all as part of the "core" - those services which are sane 
for the device - which means both user-friendly and considered secure.


> > There may also be problems with the VM method.
> > Random numbers are one. More-or-less all crypto
> > depends on those. random(4) depends on the
> > driver having access to things like mouse clicks
> > and disk interrupts. I doubt that it will work well
> > on a headless server with solid state disk, let
> > alone in a VM.
> > 
> > This is just one problem that seems obvious.
> > Has anyone done a security audit on one of
> > the VM methods? Without that, should it be
> > trusted?
> 
> Maybe the cloud companies have done some research on that? You have a 
> valid question here. I'm very interested how secure the virtualization 
> i use (LXC) is.

You expect cloud companies to have done research in running 
virtualization on crippled hardware without dedicated RNG or even CPU 
virtualization support?


> > > Not all the software running on the FreedomBox will be mature
> > > and i expect a lot of serurity/stability issues.
> > 
> > I tend to think only mature software should be used.
> > There are other places for development and experiments.
> > The box needs to be very solid.
> 
> One of the goals of the FreedomBox is to decentralize popular social
> networking services. The software to do so is still in development or
> does not exists. In order to develop the software FreedomBoxes are
> needed. Are you going to wait until Diaspora is mature in order to let
> it run on the FreedomBox?

I am going to bet on alternatives to Diaspora not building everything 
from scratch, e.g. Buddycloud - approached as an XMPP extension with 
multiple implementations.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110508/e2b0dc47/attachment.pgp>


More information about the Freedombox-discuss mailing list