<div dir="ltr"><div><div>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:<br><br>-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.<br>
-Kerberos relies on fully qualified domain names to canonicalize service principals (see <a href="http://web.mit.edu/kerberos/krb5-devel/doc/admin/princ_dns.html#service-principal-canonicalization">http://web.mit.edu/kerberos/krb5-devel/doc/admin/princ_dns.html#service-principal-canonicalization</a>) and it's better if reverse name resolution works as well. 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.<br>
</div><div>-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). 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).<br>
</div>-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.<br>
</div><div>-Support for Kerberos on mobile OSes is spotty at best. I'm trying to improve that (see <a href="https://github.com/cqcallaw/kerberos-app">https://github.com/cqcallaw/kerberos-app</a>)<br></div><div><br><div>
Also of interest is a guide I wrote on the Ubuntu wiki about this concept: 
<a href="https://help.ubuntu.com/community/SingleSignOn">https://help.ubuntu.com/community/SingleSignOn</a> 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.<br><br>Yet. :)<br></div></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 11:53 PM, Petter Reinholdtsen <span dir="ltr"><<a href="mailto:pere@hungry.com" target="_blank">pere@hungry.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Jonas Smedegaard]<br>
> Let me try rephrase: Why use a mechanism more complex than e.g. sudo to<br>
> govern crossing boundaries of access rights?<br>
<br>
Because I believe it is a good idea to be able to authenticate into<br>
ones own freedombox without having to send the password over the net<br>
(even encrypted).  The scenario I have in mind is a linux, windows or<br>
mac box hooked up to ones own Kerberos/AD domain, which can log into<br>
freedombox using Kerberos, and which can get a Kerberos ticket also<br>
when away from home.<br>
<br>
> If Kerberos is used only to issue tickets automatically based on<br>
> user-id, then I see no benefit of that mechanism.<br>
<br>
I agree.<br>
<br>
> If Kerberos is used also for authenticating human users of<br>
> FreedomBox, how do you then imagine making that dead user-friendly?<br>
<br>
For this to work, I believe the Freedombox had to become a AD domain<br>
controller, thus allowing any windows machine to "join the domain" of<br>
the Freedombox and the browser to log into plinth using the Kerberos<br>
ticket.<br>
<br>
But after looking at plinth/exmachina a bit more, I believe the best<br>
way forward right now is to drop exmachina completely and rewrite<br>
plinth to use sudo.  Instead of talking to exmachina, it should call<br>
'sudo /some/privileged/helper/script' we write to handle the<br>
operations plinth need, and ask it to do the privileged operations.<br>
This would allow us to get something working very quickly.  For<br>
package installation, I suspect aptdaemon is a good way to get<br>
everything we need (including debconf interactions), using the dbus.<br>
<br>
Any objections to dropping exmachina?  I suspect 200 lines of python<br>
and 3-4 hours should be enough to do the rewrite.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Happy hacking<br>
Petter Reinholdtsen<br>
<br>
_______________________________________________<br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
</font></span></blockquote></div><br></div>