[Server-devel] Fwd: /etc/xs-sigchecks-enabled

[Douglas Bagnall]

The background to this discussion is the xs-sigchecks-enabled flag was
introduced so packages like xs-rsync could function without relying on
infrastructure that didn't exist at the time.

This email is just moving talk to the list; I'll reply to myself shortly.


---------- Forwarded message ----------
From: Martin Langhoff <martin at laptop.org>
Date: 2008/11/6
Subject: Re: /etc/xs-sigchecks-enabled
To: Douglas Bagnall <douglas at paradise.net.nz>


Hi Douglas,

On Wed, Nov 5, 2008 at 1:59 AM, Douglas Bagnall <douglas at paradise.net.nz> wrote:
> This is bugging me a little, because more and more is starting to hang
> off it, with xs-tools importing keys and the sotp passwords and so on.

good to think it through...

> I would like something that meant "we're not checking keys so you
> can't do that", but after considering what effect it has in other
> situations, I've treated the flag to mean "we're not checking keys so
> you can do anything!".

You are right that for sotp it backfires in a bad way. Don't think I
was aware of this before you mentioned it...

> So, for the xs-tools usbmount script, it would be nice to treat it as
> a 'not checking, so not allowing' flag.  There is a little bit of a
> bootstrapping problem there: if you're not allowing unsigned imports,
> you can't get a key in to sign other keys to allow imports.  We've
> talked about this before: either there's a magical moment of trust
> that lets the first key in whatever, or there is a preinstalled OLPC
> key.  In the present interpretation of the flag, there is a magical
> era of trust.  (If we have a preinstalled key it would need to be in
> /etc/pki/olpc/XS-trusted-keys).
>
> Ah, sorry for the ramble: What I'm getting at is: should the absence
> of /etc/xs-sigchecks-enabled mean 'always trust usb input' or 'do what
> seems sensible with usb input'?

No, no ramble but good thinking -- and I'd say we should move this to
the server-devel list.

My take on this is that it means 'do what seems sensible with usb
input' -- in that sense it's a "xs-security-on" flag, rather than
pointing to a particular mechanism. (maybe worthy of a rename before
0.5 is released?)

As you say, there's a magical moment of trust at install time. Some
teams might use anaconda to touch the file, pilots might login and
touch the file manually (but that's unlikely). Not having the file
there means you're on a less safe configuration, apt only for small
pilots where a sysadmin controls the machine closely (physical
security, etc).

cheers,




m
--
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff