Re: [Freedombox-discuss] LDAP
On Fri, 2013-12-27 at 20:39 -0600, Nick Daly wrote: Simo s...@ssimo.org writes: On Fri, 2013-12-27 at 19:08 -0600, Nick Daly wrote: Time to do a lot of LDAP (or Kerberos, or...) learning. Do yourself a favor, nix their auth system and use apache modules, mediawiki has a module to understand REMOTE_USER, so should other services like that. Once you find one that understand REMOTE_USER you can defer authentication compeltely to apache and not have to learn/implement/tweak each single service in a different way. Could you clarify or point to an example of where this is used well? I am not sure what you mean, but you can bet all cases where a x509 cert is used for example, the auth is done in apache by mod_ssl or mod_nss and the application trusts the REMOTE_USER environment variable. There're lots of results, but there's also a lot of chaff in those results. Anything you want to know better ? Seems like ikiwiki's httpauth [0] respects REMOTE_USER, which seems ideal for the wiki service. Now as long as everything else does the same... Yeah, this I remembered which is why I suggested you to use REMOTE_USER, it's at the same time a very low common denominator but also very flexbile because all you need to change is the apache configuration and not each single application, too bad modern time web developers forgot about it and went full steam exclusively with form based authentication, which shouldn't be nixed to be clear. At the momoent I am actually working on an Identity provider project that will be able to delegate to the Ido the actual authentication and then using an apache module (unless you want to talk SAML directly) perform actual auth for applications and fill in REMOTE_USER and potentially other variables. Once it has some better UI I will send you a link to it. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
On Fri, 2013-12-27 at 19:08 -0600, Nick Daly wrote: Bdale Garbee bd...@gag.com writes: Jonas Smedegaard d...@jones.dk writes: Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. ...Clearly not critical path, but this is another possible task for someone out there reading who would like a modest project that could help us out in the long term. What I think we can effectively use LDAP for is to manage the information associated with identities. Users, what access rights they should have, etc, in an application-neutral way that we can potentially wrap some plinth UI goodness around eventually. It should also be possible to use these sorts of ACLs to create application-specific data-stores (among other things, to keep applications from snooping on one another's data). Keeping data separated is a related, but different, issue from the problem of separating processes (the LXC/VM issue). So, does anybody know any good LDAP-enabled services we can use? I tried to move a wiki service into Plinth (ikiwiki, via [0]), but immediately ran into the problem that ikiwiki knows nothing about authentication mechanisms other than its own. I'm checking on the ikiwiki IRC channel and their forums, but very few wiki services (other than MediaWiki, which feels like overkill) are aware of LDAP. Time to do a lot of LDAP (or Kerberos, or...) learning. Do yourself a favor, nix their auth system and use apache modules, mediawiki has a module to understand REMOTE_USER, so should other services like that. Once you find one that understand REMOTE_USER you can defer authentication compeltely to apache and not have to learn/implement/tweak each single service in a different way. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Fwd: Re: Dev: Networking Interface Config?
On Tue, 2013-12-17 at 11:39 +0100, Anders Jackson wrote: And no, NM isn't needed and should not be used on a server. The Freedom-box is more an embedded device than a Server, and if I understand it correctly, it is supposedly thought as a friendly device not just for experts. Using something like NM, would make life simpler for non expert command line lovers, so why I see to unqualified 'no' on the this list, to a legitimate question ? Can you, or Bdale, provide a reason why using NM is undesirable ? Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Perfect Forward Security (PFS) on Linux Weekly News (LWN)
On Thu, 2013-11-07 at 12:27 +0100, Jonas Smedegaard wrote: Hi, Linux Weekly News has an article on Perfect Forward Security: http://lwn.net/SubscriberLink/572926/34b86d70a0e9cda2/ It's PF Secrecy, not Security :) If you have comments/rants about the article, I recommend that you consider posting them to the comments section of that article, rather than (only) here, as a way to contribute to their fine service. It's a nice article, but doesn't really help understanding PFS, there are some additional details in the comments though. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] don't sidestep /etc as configuration storage
On Mon, 2013-11-04 at 10:27 +0100, Jonas Smedegaard wrote: Quoting Simo (2013-11-04 03:46:56) On Sun, 2013-11-03 at 18:54 +0100, Jonas Smedegaard wrote: Quoting Simo (2013-11-03 18:02:56) On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) In addition, we get a central and structured place to store configuration for at least some of the services, but that is of less importance to me. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. I am not sure what this means, package maintainers normally call adduser/addgroup or similar, how is that a problem ? LDAP is a registry. Slapd supports using its own database to configure itself, and some other applications also support storing configuration in LDAP as alternative to files below /etc. Debian packages generally store site-wide configuration as files below /etc. That means the maintainers of packages ensure that configurations work and can be smoothly upgraded across releases of those packages. It is technically possible to avoid coordinating needs for customization of configuration with package maintainers, by using another registry than files below /etc - e.g. by use of the LDAP registry. That's bad! Debian packages is all about maintenance. Sidestepping that is sidestepping the reliability of Debian. To be honest I do not have that great faith about maintenance of Debian packages, especially across releases. In my limited use I've had way too many breakages of service due to Debian's helpful policy of meddling in package configuration. The last horror story was an upgrade of a system with dovecot, I was so upset I nuked Debian and went back to CentOS. So you suggest to start a project similar to FreedomBox, based on Centos? No. Or what is your point? My point is that when(!) we choose to rely on Debian, we should do so also for configuration handling. My point is that you need your own configuration handling if you hope to have anything that a non-expert can use. The DEbian configuration management is little more than continuously prompting an expert admin on what to do when there are configuration file changes, that's not configuration management at all, that's just deferring to an expert admin. And I hope the target audience is a little bit broader than that. That means having a overall package that drags in the right dependencies and simplifies configuration decisions by abstracting away the details of low level service configuration into an interface manageable by common users, where the hard choices are predetermined. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) [Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. Beware that simply supports LDAP may not tell the full story: Some applications integrate with LDAP only by optional lookups of LDAP records, while maintaining its user data in a custom database anyway (i.e. not writing back to LDAP). If LDAP is used only for readonly user/group data, not for sharing other user data and not updated from the applications, then it might be safer to write a script exporting POSIX info to those applications needing a custom format (e.g. as a cron job or added as hooks to e.g. change of password. Ejabberd, specifically, _does_ support POSIX getent. That's the very reason I suggested to use that daemon: I have experience using it in production, because it fits my requirements of using that simple shared auth mechanism. It would help to avoid confusing identity store with authentication or authorization mechanisms. Hint for someone wanting to help: Above has to potentially low hanging fruits: * collect concrete data on which applications support which shared mechanisms for user/group management, and whether the support is readonly or read/write. Read Only is the most sensible, you do not want random apps to be able to write to an identity store, or you open up your flank for privileges escalations. * document how to make prosody use getent. the nsswitch interface (which is what you refer to with getent) is pluggable, so LDAP would fit in quite easily, there are a number of tools that provide plugins for all sort of identity stores. In addition, we get a central and structured place to store configuration for at least some of the services, but that is of less importance to me. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. I am not sure what this means, package maintainers normally call adduser/addgroup or similar, how is that a problem ? Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
On Sun, 2013-11-03 at 18:40 +0100, Jonas Smedegaard wrote: Quoting Simo (2013-11-03 18:02:56) On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) [Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. Beware that simply supports LDAP may not tell the full story: Some applications integrate with LDAP only by optional lookups of LDAP records, while maintaining its user data in a custom database anyway (i.e. not writing back to LDAP). If LDAP is used only for readonly user/group data, not for sharing other user data and not updated from the applications, then it might be safer to write a script exporting POSIX info to those applications needing a custom format (e.g. as a cron job or added as hooks to e.g. change of password. Ejabberd, specifically, _does_ support POSIX getent. That's the very reason I suggested to use that daemon: I have experience using it in production, because it fits my requirements of using that simple shared auth mechanism. It would help to avoid confusing identity store with authentication or authorization mechanisms. Please elaborate on the differences. You seemed to mix authenticating against an LDAP server and using it as an identity store. Although both functions are supported by LDAP servers it is not always the case that both are used by a system. For example many enterprise systems use an LDAP directory to hold user information but then use Kerberos for authentication and authorization is enforced on clients based on policies pushed via files or other methods. I was just cautioning that trying to lump all uses together was not productive for the discussion. Hint for someone wanting to help: Above has to potentially low hanging fruits: * collect concrete data on which applications support which shared mechanisms for user/group management, and whether the support is readonly or read/write. Read Only is the most sensible, you do not want random apps to be able to write to an identity store, or you open up your flank for privileges escalations. * document how to make prosody use getent. the nsswitch interface (which is what you refer to with getent) is pluggable, so LDAP would fit in quite easily, there are a number of tools that provide plugins for all sort of identity stores. Petter suggests that FreedomBox use LDAP. I suggest to try keep it simpler. Yes, LDAP supports nsswitch, but that does not help keep the actual software stack simpler. I tend to agree, given the freedombox is a simple standalone machine by nature, it makes little sense to use something complex like LDAP, one more thing that can break and cause issues, and I said this as a fervent LDAP proponent in the enterprise and everyday user and developer :) Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] don't sidestep /etc as configuration storage
On Sun, 2013-11-03 at 18:54 +0100, Jonas Smedegaard wrote: Quoting Simo (2013-11-03 18:02:56) On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) In addition, we get a central and structured place to store configuration for at least some of the services, but that is of less importance to me. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. I am not sure what this means, package maintainers normally call adduser/addgroup or similar, how is that a problem ? LDAP is a registry. Slapd supports using its own database to configure itself, and some other applications also support storing configuration in LDAP as alternative to files below /etc. Debian packages generally store site-wide configuration as files below /etc. That means the maintainers of packages ensure that configurations work and can be smoothly upgraded across releases of those packages. It is technically possible to avoid coordinating needs for customization of configuration with package maintainers, by using another registry than files below /etc - e.g. by use of the LDAP registry. That's bad! Debian packages is all about maintenance. Sidestepping that is sidestepping the reliability of Debian. To be honest I do not have that great faith about maintenance of Debian packages, especially across releases. In my limited use I've had way too many breakages of service due to Debian's helpful policy of meddling in package configuration. The last horror story was an upgrade of a system with dovecot, I was so upset I nuked Debian and went back to CentOS. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Dumb idea: Alternative to Tor that promotes good behavior
On Sun, 2013-10-27 at 13:26 -0400, Bill Cox wrote: What do you guys think? You are a great censor! Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Dumb idea: Alternative to Tor that promotes good behavior
On Mon, 2013-10-28 at 10:02 -0700, Jonathan Wilkes wrote: - Original Message - From: Simo s...@ssimo.org To: Bill Cox waywardg...@gmail.com Cc: freedombox-discuss@lists.alioth.debian.org Sent: Monday, October 28, 2013 8:37 AM Subject: Re: [Freedombox-discuss] Dumb idea: Alternative to Tor that promotes good behavior On Sun, 2013-10-27 at 13:26 -0400, Bill Cox wrote: What do you guys think? You are a great censor! Do you run a tor exit-node? No, I can't and probably wouldn't indeed. The more important point to take away is that Tor's current design puts an enormous responsibility on the owner/operator of the exit-node. I don't agree with Bill's approach either but I'd suspect that most people would find it very difficult to directly support basic principles of free speech when watching what tends to get requested through their own machines. I do not disagree, yet Bill's proposal is a censor's dream. My rule is simple, whenever someone says something about illegal material replace it with dissident material ... in most cases you come up with a great censorship tool, assuming it can be made to work in the first place. Now of Bill proposal I do not like neither the 'censorship' aspect, nor the 'feasibility' aspect. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox CA
On Thu, 2013-09-12 at 15:13 +0100, ke...@sd-kvm.me4.it wrote: Gnutls may be usable as an alternative to Openssl. It's already in Debian, new to me. What's wrong with OpenSSL that GNUTLS get's right ? Simo. On Thu, Sep 12, 2013 at 03:06:46PM +0100, Keith wrote: After further thought: With a CA on each freedombox we could have something like this Create a CA using (options used could be changed) openssl genrsa -des3 -out Freedombox CA.key 4096 Is there any remote change to use a different crypto library/tool than OpenSSL? I realize that the license issues preclude many of potential alternatives from inclusion in Debian. openssl req -new -x509 -days 3650 -key Freedombox CA.key -out Freedombox CA.pem Possibly replace any snakeoil keys created by Debian (Postfix uses 2048 bits, could use 4096 bits if Postfix is the MTA used). Include in Plinth an option for a freedom box to obtain ssl keys with the Freedombox CA. No interface to an external website, openssl can do this. The public key of the Freedombox CA could be published, to be imported into someone else's browser, could be a problem with multiple Freedombox CA's with the same name. Possibly a paranoid option to rotate the ssl keys on the freedom box running manually and/or as a cron job (Now doing this daily with one of my mailservers). ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox CA
On Thu, 2013-09-12 at 16:51 -0400, Daniel Kahn Gillmor wrote: On 09/12/2013 04:40 PM, Simo wrote: On Thu, 2013-09-12 at 15:13 +0100, ke...@sd-kvm.me4.it wrote: Gnutls may be usable as an alternative to Openssl. It's already in Debian, new to me. What's wrong with OpenSSL that GNUTLS get's right ? * Licensing that is not deliberately incompatible with the GPL. Well the licensing story of openssl is complex, but it is not deliberately incompatible as far as I know, the incompatibility is an accident of history. * A sane and modern library API (granted, parts of OpenSSL are have these features too; most projects are mired in the horror, though) Hard for me to parse what you mean, but it is not like GnuTLS does not have its flaws: http://www.openldap.org/lists/openldap-devel/200802/msg00072.html Afaik this remains unchanged to date. * delegation of specific tasks to other libraries, rather than kitchen-sink agglomeration. There are probably other reasons. Are you compiling a list on request because you have pet peeves ? I do not deny OpenSSL is not the best API you can get, but I thought we were discussing about the security of the library. OpenSSL has got orders of magnitude more public scrutiny than gnutls so I tend to trust OpenSSL more from this point of view. So do you have actual issues with the crypto implementation ? Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox CA
On Thu, 2013-09-12 at 13:58 -0700, cgw...@aol.com wrote: Thank god there are still people that stick to and defend the GNU Gpl I am sure I wrote more GNU GPL software than you did. If it were a matter of license incompatibility then you could also choose the NSS library (formerly from mozilla) which is used in all major browsers (so you already use it every day). It has a different but equally awful API than OpenSSL, but has received also a ton more scrutiny and certification than GnuTLS. Understand that I have nothing against GnuTLS per se, it just lacks tons of features and scrutiny that openssl and NSS already have. Simo. -Original Message- From: Freedombox-discuss [mailto:freedombox-discuss-bounces+cgw993=aol@lists.alioth.debian.org] On Behalf Of Daniel Kahn Gillmor Sent: Thursday, September 12, 2013 1:52 PM To: Simo Cc: freedombox-discuss@lists.alioth.debian.org; ke...@sd-kvm.me4.it Subject: Re: [Freedombox-discuss] Freedombox CA On 09/12/2013 04:40 PM, Simo wrote: On Thu, 2013-09-12 at 15:13 +0100, ke...@sd-kvm.me4.it wrote: Gnutls may be usable as an alternative to Openssl. It's already in Debian, new to me. What's wrong with OpenSSL that GNUTLS get's right ? * Licensing that is not deliberately incompatible with the GPL. * A sane and modern library API (granted, parts of OpenSSL are have these features too; most projects are mired in the horror, though) * delegation of specific tasks to other libraries, rather than kitchen-sink agglomeration. There are probably other reasons. --dkg ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox CA
On Thu, 2013-09-12 at 15:48 -0700, cgw...@aol.com wrote: I am sure I wrote more GNU GPL software than you did. - Ok but how does that relate to my statement that I am grateful for people that stick to the GPL? It looked to me like a way of implying unlike others that propose non-GPL libraries. It's not like OpenSSL is proprietary or anything. And I am also grateful to people that stick to the GPL, I see it especially important for applications, however in the case of crypto libraries, I personally prefer a license that has no compatibilty issues. Crypto is extremely important and difficult to get right and you want to have the maximum possible adoption of a good implementation without any possible or perceived barrier. Simo. -Original Message- From: Simo [mailto:s...@ssimo.org] Sent: Thursday, September 12, 2013 3:22 PM To: cgw...@aol.com Cc: freedombox-discuss@lists.alioth.debian.org; ke...@sd-kvm.me4.it Subject: Re: [Freedombox-discuss] Freedombox CA On Thu, 2013-09-12 at 13:58 -0700, cgw...@aol.com wrote: Thank god there are still people that stick to and defend the GNU Gpl I am sure I wrote more GNU GPL software than you did. If it were a matter of license incompatibility then you could also choose the NSS library (formerly from mozilla) which is used in all major browsers (so you already use it every day). It has a different but equally awful API than OpenSSL, but has received also a ton more scrutiny and certification than GnuTLS. Understand that I have nothing against GnuTLS per se, it just lacks tons of features and scrutiny that openssl and NSS already have. Simo. -Original Message- From: Freedombox-discuss [mailto:freedombox-discuss-bounces+cgw993=aol.com@lists.alioth.debian. org] On Behalf Of Daniel Kahn Gillmor Sent: Thursday, September 12, 2013 1:52 PM To: Simo Cc: freedombox-discuss@lists.alioth.debian.org; ke...@sd-kvm.me4.it Subject: Re: [Freedombox-discuss] Freedombox CA On 09/12/2013 04:40 PM, Simo wrote: On Thu, 2013-09-12 at 15:13 +0100, ke...@sd-kvm.me4.it wrote: Gnutls may be usable as an alternative to Openssl. It's already in Debian, new to me. What's wrong with OpenSSL that GNUTLS get's right ? * Licensing that is not deliberately incompatible with the GPL. * A sane and modern library API (granted, parts of OpenSSL are have these features too; most projects are mired in the horror, though) * delegation of specific tasks to other libraries, rather than kitchen-sink agglomeration. There are probably other reasons. --dkg ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-dis cuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Drop exmachina, use sudo instead - at least short term (Was: Kerberos and remctl instead of exmachina?)
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 p...@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
Re: [Freedombox-discuss] Key Splitting to Protect Client Data on Boxes
On Wed, 2013-02-06 at 22:52 -0600, Nick M.Daly wrote: So, it's pretty easy to split data using Shamir's Secret Sharing (package: gfshare). If we split a client's PGP key using a 2:3 split (2 of three pieces are required to reform the key), then we could meaningfully PGP encrypt the client's data on the box. That would prevent the box from ratting out the client if it ever fell into nefarious hands. The user would need to split their key into three pieces: 1. On the box. 2. On a client device. 3. On a backup, somewhere. The box could send the client its piece, along with the encrypted data, even over an insecure channel, because one piece of the key is meaningless. This works as long as we can get the first piece of the key onto the client device, out of band, and the client device remains unsurveiled. If either of these assumptions are incorrect, we'll need different solutions (performing the decryption and service operation on the box itself, for example). The only problem of doing this is that you need to find out how bad for gpg encryption it is a partial leak of a key. Not all encryption algorithm have linear resistance to attack based on the number of bits of the key leaked. Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] BitTorrent Sync
On Wed, 2013-01-30 at 22:10 +0100, Elena ``of Valhalla'' wrote: On 2013-01-30 at 09:28:14 -0800, freedombox-discuss.neophyte_...@ordinaryamerican.net wrote: Doesn't that assume the devices are never the subject of a search warrant? in some countries in that case simple encryption isn't enough to protect you, since you are also forced to reveal your password by law. In other countries the same applies, not because you are forced by the law, but because the police have no incentive not to use unlawful methods to force you to reveal your password. In either cases, a solution that works at the filesystem layer is probably going to work better, expecially for the hiding part. Actually hiding data in a fully encrypted partition is much easier and *safe* than encrypting only some files at the filesystem level and hoping they won't find them. A simple block level analysis will easily find encrypted data via statistical means if only some data is encrypted, also copies of the data may be easily found in swap spaces and temporary files. There are also full encryption tools that allow you to have 2 sets of data, one real and one fake and innocuous that will be revealed by using a different password in a non-detectable way. So a proper full encryption is much better to protect one person privacy at multiple levels. Last but not least disposal of encrypted disks is relatively safe even if you forget (or don't know how) to wipe the data. Unless you leak your encryption keys/password the disk is simply unreadable by anyone that should pick it up once you dispose of it. Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] T-shirts
On Tue, 2012-12-11 at 13:56 -0500, Deb Nicholson wrote: Indeed. However, my main reasoning was to *raise money* by encouraging people to donate by purchasing a t-shirt, or other merchandise. I donated around 75 dollars in late 2011 and was promised stickers but still didn't receive anything so I would not encourage donating for something in return because chances are high you won't get it. I can understand your disappointment. It's often difficult for volunteer-run orgs to follow up on details in a timely fashion. If we go forward with t-shirts, my suggestion would be to sell them primarily in person, or outsource the shipping to a print on demand type place -- as opposed to further diverting volunteer energies to something like intermittent t-shirt fulfillment. I did try to do my own with shipping shirts in the past, don't do that you are wasting a lot of resources unless you like the actual shipping business. Relying on a third party may be more expensive but will get you better results. Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Creating Box Identity Keys
On Sun, 2012-12-09 at 20:48 -0600, Nick M. Daly wrote: Charles N Wyble charles-li...@knownelement.com writes: Why not just generate high amounts of entropy on a constant basis? Create the keys when the user account gets created? That's the approach we (Free Network Foundation) are taking with the AutoTunnel system. That's the goal, but I'm lost as how to constantly generate high amounts of quality entropy on low-throughput consumer-grade hardware in a timely fashion. An Entropy Key might help (still need to buy and try out one of those things), but requiring or bundling one of those raises the overall investment for FBX hardware significantly (it's 1/3 the price of a DreamPlug). Any suggestions? How much is it ? Maybe we could publish design for a home made device using a photo diode for those that want to have fun building one :) Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Diaspora becoming a community project
On Sat, 2012-09-01 at 17:37 +0200, Leandro Noferini wrote: Jonas Smedegaard d...@jones.dk writes: [...] For example here in Italy it is all but easy to have a static ip address in home connections: again for example my ISP does not sell this kind of service at all. This is what I mean normal. So you really mean normal consumer access to internet, not normal FreedomBox? Yes, almost here in Italy, having a static ip address in home connections it is not normal. Not only you do not have static ip addresses, often not even public ip address, but just dynamic private addresses and NAT. Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] PHP is not the problem, security is!
On Mon, 2012-07-16 at 15:35 -0400, Boruch Baum wrote: From: Rick graham.r...@gmail.com robvanderhoe...@ziggo.nl wrote: Yesterday Nick Daly started a discussion about PHP alternatives. PHP is crap, and has a very bad security reputation. Should we use programs that are written in PHP for the FreedomBox? Sounds like a job for selinux. Rob is spot on regarding TOMOYO. I've easily deployed version 2.3 of TOMOYO on a Linux box and was (figuratively speaking) ecstatic over its ease of use compared to SElinux. TOMOYO also doesn't mess with with your filesystem (as SElinux does). Two caveats: 1] AKARI --should-- be similar; 2] I understand that the tomoyo developers were considering some major structural feature and syntax changes since version 2.3, and they're currently at version 2.5. In my particular usage case, Tomoyo revealed alot of nonsense that some Firefox add-ons were doing, and allowed me to easily restrict the wayward activities. And the add-ons continued to function fine anyway. Even though tomoyo is ridiculously simpler to use than SElinux, Should Freedombox decide to integrate TOMOYO or AKARI into the build, I would still strongly (very very) suggest FreedomBox prepare default profiles for the default FreedomBox apps. (SUSE and Canonical did so for Apparmor, but when I evaluated Apparmor a few years ago, their defaults were uselessly liberal - no offense intended to you liberals on the list). I had suggested this a few years ago on the tomoyo discussion list and directly with the tomoyo developers, but at the time, the effort went nowhere. Hi Boruch, I have been working with SELinux for quite a few years now, and I find it complete and tested on the ground in a manner that trumps all other players from my POV. However I am interested in understanding why you say that Even though Tomoyo is ridiculously simpler to use than SElinux. In what ways is Tomoyo simpler ? I admit I do not know much about tomoyo, but because it is based on file paths like apprmor I find it is probably inherently less powerful than SElinux on top of the fact that is certainly a lot less tested, which is not too good in security related stuff. Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Some thoughts I think should be widely shared
On Mon, 2012-07-02 at 08:54 -0700, freedombox-discuss.neophyte_...@ordinaryamerican.net wrote: Guidelines on launching an open source project? http://lists.teachingopensource.org/pipermail/tos/2012-June/004986.html You may be more interested in how to deal with handling and nurturing Communities. This is an excellent reference: http://www.theopensourceway.org/wiki/Main_Page Simo. -- Simo Sorce Samba Team GPL Compliance Officer s...@samba.org Principal Software Engineer at Red Hat, Inc. s...@redhat.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
