[Freedombox-discuss] Drop exmachina, use sudo instead - at least short term (Was: Kerberos and remctl instead of exmachina?)
Caleb
enlightened.despot at gmail.com
Sun Sep 8 06:16:59 UTC 2013
On Sat, Sep 7, 2013 at 6:18 PM, Simo <s at ssimo.org> wrote:
> On Sat, 2013-09-07 at 09:40 -0700, Caleb wrote:
> > I'm a huge fan of the concept of a secure, universally accessible
> > domain-as-an-appliance built from FOSS, but I've encountered the
> > following challenges that I believe we'd need to solve to make such a
> > thing dead user-friendly:
> >
> > -We'd need a bullet-proof method of determining the IP address of
> > Freedombox when attempting remote access. I gather that's the basic
> > purpose of the Santiago port, but it's not clear to me this is a
> > solved problem. Third-party services like DynDNS seem contrary to the
> > spirit of the Freedombox. IPv6-in-IPv4 services like Hurricane
> > Electric usually offer fixed address blocks, but requiring a user to
> > sign up for such a service seems to be diverging from the goal of
> > user-friendliness.
>
> A STUN server may be of use here, but it is still third party.
>
> > -Kerberos relies on fully qualified domain names to canonicalize
> > service principals (see
> >
> http://web.mit.edu/kerberos/krb5-devel/doc/admin/princ_dns.html#service-principal-canonicalization)
> and it's better if reverse name resolution works as well.
>
> No, reverse resolution is bad and should never be relied upon,
> especially for security and even more so for kerberos:
> http://ssimo.org/blog/id_015.html
>
I should clarify: I meant "better" in the sense that it requires less
configuration. Specifically, setting "rdns = false" in krb5.conf wouldn't
be necessary.
I'm not sure reverse lookup is necessarily a security vulnerability: it
seems trivial to detect spoofed reverse lookups by comparing the reverse
and forward lookups for consistency, and refusing to proceed if an
inconsistency is detected. As you say in your blog post, though, getting
reverse lookup working correctly can be a huge nuisance, probably moreso
than a customized Kerberos client configuration.
>
> > So remote access requires domain name resolution of some kind.
> > Solving the previous challenge would help here: if we can find the
> > Freedombox, we could query it for a source of domain names without
> > requiring a publicly resolvable fully-qualified domain name.
> >
> > -The user experience for joining a host to a Kerberos realm is not
> > clean. At minimum, one most add a host principal to the Kerberos
> > database, securely transport the host principal keytab to the host,
> > then enable access for that host in name services (e.g. LDAP).
>
> I have some experience about making this process easy for admins as I am
> one of the founders of http://www.freeipa.org and it isn't hard in
> absolute to come up with something simple, but it will require a clear
> definition of what are the operations you want to allow, what is the
> 'friendly' workflow you need, what is the system you want to use, and
> finally if all that is still as secure as it needs to be.
>
I think the ideal flow would be something like:
1) User installs Freedombox client utilities on their computer (there's a
trust issue here, of course--how do they know they've got a genuine copy of
the client utilities? Separate discussion, though)
2) User executes "freedombox join" or clicks a "Join Realm" button in a GUI
3) Join utility locates available realms
4) If multiple realms are available, the user selects the realm they wish
to join
5) Join utility negotiates a unique hostname for the joining host. User
specifies the hostname if they desire, otherwise a default is generated
6) Join utility registers host (adds host principal to Kerberos database,
configures name resolution services if needed, etc)
7) Join utility securely transfers host keytab and encryption data (GPG
keys, TLS certificates, etc) to host
8) Join utility installs keytab, keys, and certificates in appropriate
system locations
> Adding the principal and enabling access isn't too difficult, but
> > securely transferring the keytab probably means some sort of
> > sneakernet technique (e.g. a USB flashdrive).
>
> Encrypting in a public gpg key provided by the user/client is simple
> enough, or even just offer and TLS secured service to provide you the
> keytab (HTTPS/LDAP+starttls/anonymous PKINIT + GSSAPI channel, etc...)
> (FreeIPA provides a command that uses LDAP+GSSAPI to secure the channel
> when retrieving the keytab and HTTPS when retrieving X509 certs).
>
The GPG key technique seems like an excellent solution. Come to think of
it, any mechanism where the joining host sends a public key with which to
encrypt the response should work. Also, it seems possible to generate a
single-use public/private key pair for maximum security. If generating a
single-use public/private key pair is feasible, the user wouldn't need to
provide a key, which is a usability win.
>
>
> > -Remote access must handle connectivity outages (e.g. your cellular
> > network connection drops or you leave WiFi coverage) gracefully. This
> > means lots of name caching, and file synchronization if you want
> > remote file access ala Dropbox. This is probably the stickiest problem
> > because it involves careful client-side service management. Also, name
> > caching is brittle if not done correctly.
>
> What's the point of caching names if you can't reach the network ?
> Anyone there are mature name caching daemons like dnsmasq, I would say
> name caching is mostly a solved issue.
>
Another clarification: I'm talking of usernames and group information here,
not domain names. I'm assuming that user management would be centralized,
with user accounts defined in an LDAP directory or such instead of existing
on a local system.
>
> > -Support for Kerberos on mobile OSes is spotty at best. I'm trying to
> > improve that (see https://github.com/cqcallaw/kerberos-app)
> >
> >
> > Also of interest is a guide I wrote on the Ubuntu wiki about this
> > concept: https://help.ubuntu.com/community/SingleSignOn I'm using the
> > concepts articulated in that guide for local and remote access, and I
> > can report it is definitely _not_ dead user-friendly, particularly for
> > remote access.
>
> The FreeIPA project does 90% of the manual stuff you describe in your
> guide automatically, we are looking for help porting it to Debian, if
> someone is interested in helping out, the issues are mainly a ton of
> dependencies (packaging) for our PKI, and then routing out some
> Fedoraisms in the installation tools.
>
> Of particular note if you are interested in disconnected cases is the
> SSSD project (available in Debian/Ubuntu) which handles offline
> authentication and other stuff neatly and robustly.
>
I wasn't aware of either of these projects, but I'll definitely check them
out! Thanks for information.
>
> > Yet. :)
> >
> >
> >
> >
> >
> > On Fri, Sep 6, 2013 at 11:53 PM, Petter Reinholdtsen <pere at hungry.com>
> > wrote:
> > [Jonas Smedegaard]
> > > Let me try rephrase: Why use a mechanism more complex than
> > e.g. sudo to
> > > govern crossing boundaries of access rights?
> >
> > Because I believe it is a good idea to be able to authenticate
> > into
> > ones own freedombox without having to send the password over
> > the net
> > (even encrypted). The scenario I have in mind is a linux,
> > windows or
> > mac box hooked up to ones own Kerberos/AD domain, which can
> > log into
> > freedombox using Kerberos, and which can get a Kerberos ticket
> > also
> > when away from home.
> >
> > > If Kerberos is used only to issue tickets automatically
> > based on
> > > user-id, then I see no benefit of that mechanism.
> >
> > I agree.
> >
> > > If Kerberos is used also for authenticating human users of
> > > FreedomBox, how do you then imagine making that dead
> > user-friendly?
> >
> > For this to work, I believe the Freedombox had to become a AD
> > domain
> > controller, thus allowing any windows machine to "join the
> > domain" of
> > the Freedombox and the browser to log into plinth using the
> > Kerberos
> > ticket.
> >
> > But after looking at plinth/exmachina a bit more, I believe
> > the best
> > way forward right now is to drop exmachina completely and
> > rewrite
> > plinth to use sudo. Instead of talking to exmachina, it
> > should call
> > 'sudo /some/privileged/helper/script' we write to handle the
> > operations plinth need, and ask it to do the privileged
> > operations.
> > This would allow us to get something working very quickly.
> > For
> > package installation, I suspect aptdaemon is a good way to get
> > everything we need (including debconf interactions), using the
> > dbus.
> >
> > Any objections to dropping exmachina? I suspect 200 lines of
> > python
> > and 3-4 hours should be enough to do the rewrite.
> >
> > --
> > Happy hacking
> > Petter Reinholdtsen
> >
> > _______________________________________________
> > Freedombox-discuss mailing list
> > Freedombox-discuss at lists.alioth.debian.org
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
> >
> >
> > _______________________________________________
> > Freedombox-discuss mailing list
> > Freedombox-discuss at lists.alioth.debian.org
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130907/ec35f815/attachment-0001.html>
More information about the Freedombox-discuss
mailing list