[Freedombox-discuss] Drop exmachina, use sudo instead - at least short term (Was: Kerberos and remctl instead of exmachina?)

[Simo]

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

>  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.

>  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).

> -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.

> -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.

> 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