[tahoe-dev] Secure OS for running Tahoe?

Randall Mason clashthebunny at gmail.com
Mon Mar 4 09:18:12 UTC 2013

Sorry to resurrect an old thread.

TL;DR: A BSD or a Linux with Tahoe-LAFS in the package manager would
be better than something too exotic or something less exotic.  And
don't use the system for anything more than necessary, no matter how
much you like Monopoly.  If you find updates too hard to do, you need
to find something easier.

On Sun, Feb 24, 2013 at 2:24 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
> Simon Forman <forman.simon at gmail.com> writes:
>> Forgive me if this is the wrong place to ask this or if it's terribly
>> naive, but could I get some recommendations for secure OSs to run
>> Tahoe on?  I know there's OpenBSD, are they still near the top of the
>> heap?  What about OKL4?
> OpenBSD claims security as its first principle, but it's not clear that
> it's significantly if any better than the other BSDs.

OpenBSD has been audited thououghly.  That means that one person's
eyes have checked OpenBSD for every problem that person could think
of.  Given the other things that have come from OpenBSD like OpenSSL
and OpenSSH, we are forever grateful for this initial push into
securing commodity operating systems.  I would agree that other BSDs
(and operating systems in general) have benefited from this great
work.  OpenBSD and NetBSD are still very close and fixes often flow
both directions between them.

> I am a user and developer of NetBSD, and I think it's a good choice for
> tahoe.
> Things to think about:
>   off by default: you should operate a system with only things that you
>   actually need running.  Windows, most Linux distributions and Mac all
>   have issues here (at least FC did when I looked a year or so ago).  A
>   default NetBSD installation will not be running any services.  I
>   expect OpenBSD to be similar, and probably FreeBSD.

Not even a firewall can protect you from problems in services that run
by default if the firewall is opened up.  Then think about if the
firewall also contained a security issue...  The corollary to this is
just because you have an emotional attachment to various programs,
don't install them if you don't need them.  I used to install postfix
on all my systems even if they didn't need email because I liked the
idea of deleting sendmail.  This would turn on an off by default
service and I was worse off because of it.

>   responsive to security advisories, and ease of updating

I totally agree, you really need to look for this.  The world would be
a different place if Microsoft had half the zero-days that they did or
if security updates were easy to install.  If security vulnerabilities
happen every week, and then those fixes usually break mission critical
things, it doesn't matter how much you want to update, you're not
going to.

>   not being a standard target.  This is a bit controversial, but
>   running a system that isn't run by 90% helps against standard
>   attacks by script kiddies.  It will not necessarily help against a
>   high-resource attacker that's after you specifically.  Being on other
>   than Windows, and perhaps other than Mac or Linux helps here.  Also
>   being on a CPU other than i386 or amd64.

Security through obscurity doesn't do anything, but security AND
obscurity is even better than security without obscurity.  The
question then becomes where is the sweet spot where you can have
enough security even though you are obscure.  Linux is almost too
popular for me these days.  I'm starting to look towards something a
little more obscure.  Plan9 would be an example of too obscure for me.
 I don't know if anybody would ever try to exploit a plan9 security
vulnerability, but I also have no idea if anybody would try to fix a
plan9 security vulnerability that was being exploited.  ARM is nice
and obscure and updated, but PowerPC is no longer updated enough.
There is a sweet spot.

>   stable branch with good software engineering discipline.   Sometimes
>   when there's an advisory, you have to update quickly.  With NetBSD,
>   there is a stable branch for a major release, and it's really actually
>   stable - updating along it, rebuilding, installing, rebooting is a
>   sane thing to do.

This was always why I fell off the BSD train.  I don't know NetBSD,
but OpenBSD was too painful for me to get updating.  I would spend
hours trying to get anoncvs working, compiling my new kernel,
rebooting, compiling my new userspace, rebooting and would rarely
remember how to do it the next time it was needed.  Do you have any
advice on an easy way to update?  With modern CPUs I can see being
able to build world quick enough that I would always initiate a whole
build ever time there was an update to the stable branch of my
release, but I'm still a little gun shy when it comes to the *BSD
update process.

Ubuntu and Fedora Desktop on the other hand supports KSplice,
rebootles updates for most kernel vulnerabilities.
[KSplice](http://www.ksplice.com/pricing).  You can apt-get update to
a secure kernel version without a reboot needed.  This feels like a
case where updating is actually easy enough that people will never
become scared of it.  This doesn't help the issues that Ubuntu (and
maybe Fedora) suffers from which is the silly on by default mentality.
 If you do go with Ubuntu, make sure you know how to disable services
that you don't need and use the machine for as little other things as
possible.  It's so easy to think "hmm, there's the game of Monopoly
available on my distro, I'll install it".  From then on monopd is on
by default and you just killed the security of your machine.

Every system is a trade off of security and usability.  If you don't
know the strengths and weaknesses of your system, then you are
vulnerable for one reason or another.  Do not lull yourself into
complacence thinking that apt-get update solved all your problems.  Do
not lull yourself into complacense thinking that BSD is secure by
default so I don't need to maintain it.

>   minimal system: if you are trying for security really seriously,
>   you'll want a system with just enough code to do what you want, but
>   not more.

Wait, you think a monopoly board game server is not minimal?  Oh,
yeah, Linux is bloat-ware.

>   package management.  There are surely packages for tahoe in major
>   linux distributions.   Tahoe and dependencies are up to date in
>   pkgsrc, used on NetBSD.

I use MacPorts on the Apple computers in my fold.  I hate it.  Before
every update I have to backup etc and diff-restore it manually when
new versions of stuff clobber my old config files.  Having a sane set
of ports and packages that are regularly updated and then are easy to
install is such a big win on a system.  Make sure you go with an OS
that will help you do this.  Everything from the kernel to Tahoe need
to be easily updated because the weakest link in the chain is the one
that may break.  Even if Windows were the most secure OS on the
planet, they don't have a way to update: Python, twisted, foolscap,
cryptocpp, and then Tahoe.  Make sure that Tahoe is updated whenever
you update other things.  Make sure that you are warned about insecure
config file defaults in old versions.  If you have everything updated
to the latest version of the binaries, but encryption is set to off in
your VPN and SSH accepts root logins without a password, you are worse
off than MacPorts where you have to reconfigure everything every time.

One thing personally that I would say is this:  Make sure you go with
something that is not just a research project.  Research is for
pushing forward the state of the art in security or discovering new
ways of securing a system.  Until the current model is proven broken,
stick with something mainstream.  There are smart enough people
working on *BSD and Linux that you will end up with better security in
the long run because of the long term support that you will receive
from the communities.  Once the person who ran the security lab at the
University moves on to new or better things, once the government
contract runs out and nobody's paying for updates, you fall back on
the community.  If the community is not there, you will be in a far
worse place than going with mainstream community supported operating

More information about the tahoe-dev mailing list