| |||||||||||||
!Bizarre!BizarrePosted Mar 22, 2012 6:34 UTC (Thu) by eru (subscriber, #2753)In reply to: Bizarre by ringerc Parent article: Shadow hardening Please: scrap the file-based auth, and move to LDAP. But if the network is down or LDAP otherwise hosed, how do you get access for fixing things? Files are also useful for situations where the system is never meant to be part of a wider authentication domain (eg. most home users and embedded systems). But I agree that in most professional deployments you want to use network-based authentication, except for root and other special cases, so improving shadow password security in the ways described in the article does not seem terribly important.
(Log in to post comments)
!Bizarre Posted Mar 22, 2012 6:48 UTC (Thu) by ringerc (subscriber, #3071) [Link]
Loopback is never down. Well, not past *incredibly* early boot, anyway, such that a NSS module that provided a hardcoded uid 0 and a uid for the LDAP daemon (to run it as non-root) would be all that'd be required until LDAP came up.
I'm talking about LDAP on the local host, as the primary and only storage for user credentials. Unlike passwd/shadow/group, it's extensible, supports fine-grained access control, mirroring and sync, etc.
I run an LDAP daemon on each server. When a change is made, the change is pushed to the master and then out to all the slaves via client-cert-protected tls-secured channels. If the master goes down, nobody cares.
!Bizarre Posted Mar 22, 2012 11:29 UTC (Thu) by cortana (subscriber, #24596) [Link]
Do you have a particularly slimmed-down build of OpenLDAP for this purpose? How much memory does it take up in regular use? Does anything break if it needs to do a lookup while the daemon is being restarted (I imagine you build it yourself, but imagine if you were using a distro-provided package that pushed out a security update). How do you handle the split between 'system' users created by distro packages with low UIDs and human users created with high UIDs? Do you use nss_ldap, nss_ldapd + nslcd (with or without nscd or unscd), nss_ldapd + slapd's nss overlay, or nss_cache?
I've been thinking along these lines for a while, but I haven't actually bothered to look at setting such a system up yet. The tuning & maintenance requirements of OpenLDAP's use of libdb put me off. Current versions have a new backend however, mdb, that appears have no such demands on the admin. The main problem I'd forsee is that slapd is not available during boot, and particularly so in early boot when everything's being run out of the initramfs.
!Bizarre Posted Mar 22, 2012 11:49 UTC (Thu) by ringerc (subscriber, #3071) [Link]
I use regular OpenLDAP from the Debian archives. It's probably possible to optimise it for memory use and cut out optional features, but with RSS at 7MB I don't care to. Remember, much of that RSS is overhead - `grep` has 1MB RSS on my system!
That kind of memory use might be a concern on particularly tiny embedded boxes, but few of those will want a full NSS anyway, they're likely to be using busybox and uclibc with their very cut down identity stuff.
slapd restarts haven't been a problem the couple of times I've done them to add new schema. Requests though PAM or NSS are delayed until slapd comes up again, then continue as normal. The delay hasn't been noticeable since slapd restarts in a fraction of a second.
Because LDAP is an afterthought in Linux distros at the moment, the situation with ldap auth in current distros is absolutely rotten. The separation between system and LDAP users that you alluded to is the problem, and the lack of testing of package scripts etc with LDAP adds to the pain. It's particularly bad when you need users the system thinks are "system" users to appear in the directory because they must be consistent across several systems for, say, NFS4 shared storage. Most package scripts will scream when they can't find the user in /etc/passwd even though it exists.
At this point I don't recommend running LDAP auth for Linux environments because it's badly tested and badly integrated into most distros as a half-assed afterthought. To work well, it must *replace* /etc/passwd and friends, not layer on top of them, and all system tools for user creation/removal/etc must manipulate LDAP transparently instead of passwd.
With the current situation I've even had to remove a user from LDAP and allow a package to create the user in the system auth files with a different auto-generated uid, then remove that generated user, add the original user back to ldap, and chown everything to the new uid. I'm not impressed.
As for my setup: I use plain old nscd on top of slapd.
FWIW, I don't particularly adore LDAP, but it's there and it works. Apple demonstrated the folly of rolling their own directory system with the short-lived NetInfo; IMO, LDAP should be adopted because we need *something* better than passwd, LDAP is there, and LDAP is mature and interoperable.
!Bizarre Posted Mar 22, 2012 17:03 UTC (Thu) by drag (subscriber, #31333) [Link]
> At this point I don't recommend running LDAP auth for Linux environments because it's badly tested and badly integrated into most distros as a half-assed afterthought.
LDAP auth always seemed weak to me. If you are doing network authentication, why not doing it right with Kerberos? It seems like any decent software has support for SASL and/or GSSAPI. This seems like a much better and more robust approach and has been the one I always have taken.
Also most of your issues with PAM and NSS can be taken care of with SSSD. Vastly better then nscd and can support 'road warrior' type configurations, which is fantastic.
Howeve, Seeing how this article is about improving the security of your shadow user database putting it all in a network daemon, even if it's localhost-only, seems like a step backwards.
!Bizarre Posted Mar 23, 2012 13:27 UTC (Fri) by Creideiki (subscriber, #38747) [Link]
Is there a way to do passwordless entry into a Kerberos system? I like using public-key SSH to save me from having to remember passwords for all the systems I have accounts on, but from what I understand Kerberos requires you to enter your password at some point (either at login or later using kinit) to get a TGT.
!Bizarre Posted Mar 23, 2012 13:32 UTC (Fri) by cortana (subscriber, #24596) [Link]
!Bizarre Posted Mar 23, 2012 16:34 UTC (Fri) by drag (subscriber, #31333) [Link]
With Kerberos it is single sign on. Which means, of course, once you get your ticket then you don't have to re-enter your password for the lifetime of that ticket. (usually about 8 hours)
On your main administrative system I found that it's most useful to not actually have it hooked into your domain. That way when something goes wrong with your domain you can do something to fix it. In that case you run 'kinit username' to request a ticket. Once you get your ticket then you should be good for at least 8 hours without having to re-enter it.
The biggest downside is that Kerberos requires a fairly significant amount of functionality to be present and working on your network before you can use it. Most networks that have grown up fairly willy-nilly tend to have a lot of brokenness in them and that won't fly with kerberos.
Your reverse DNS lookups need to be working perfectly for all the machines in the domain, for example.
The easiest way to implement a domain nowadays is to use FreeIPA. Install a CentOS or Fedora system on your network and follow Redhat's documentation.
For non-Redhat/Fedora type systems all you really need to do is install 'sssd'. There was a couple recent bugs that popped into Debian unstable that I had issues with, but Debian stable works very well.
The biggest problem with FreeIPA and SSSD is if you already have a existing OpenLDAP deployment it's not going to work well with that. You need to use the specific configuration provided with FreeIPA packages with the 389 LDAP server to be compatible.
Once you get that sorted out though then it makes all sorts of previously difficult things to do pretty easy.
!Bizarre Posted Mar 26, 2012 18:48 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
Your analysis sadly mirrors mine. I'd like to use slapd, because it doesn't make any choices for me, but it's so dedicated to not making choices for me that I can't understand how to do anything useful with it without an enormous investment of time to learn and configure it. 389ds is better, and obviously made by people who expect real sysadmins to be able to use it, but it makes so many assumptions about how you want to do things that it leaves a bad taste in my mouth. The real down side to 389ds is that using it on non-Fedora non-RHEL (read: Debian) is so difficult you may as well hand craft a slapd setup.
I came from an eDir/NDS background so I think I know what I want, but creating it is an enormous pain. Where's the distribution the presumes you want to put $everything into LDAP, users and all, right from the start, use kerberos everywhere, etc? I get a very 1996-friendly-linux-desktop kind of vibe where I think "Of course it's possible to configure Linux to do this" but in practice you may as well give up. It would be a shame if the eventual solution to this problem is to adopt samba4 and just have everyone follow Microsoft's lead.
SSSD is refreshing, but it only makes the client side easier. FreeIPA is really nice for being sort of the KDE of my desktop linux analogy, but it's a lot more than I need and is sadly tied to 389ds only and thus to Fedora systems. There seem to be only two types of person trying to get things working in this area: the people who are wizards and use slapd and the people who aren't necessarily wizards and use Fedora specific solutions.
!Bizarre Posted Mar 26, 2012 19:08 UTC (Mon) by cortana (subscriber, #24596) [Link]
I think recent versions of slapd are getting better in this area. They have a new database backend, mdb, which has no configuration knobs at all, and yet outperforms hdb/bdb. So operationally, administering slapd is a lot easier than it used to be (particularly since the hdb/bdb docs say "read the Berkeley DB documentation", which Oracle have now helpfully broken all the links to...)
Of course, you still have to decide on your schema, and come up with tools for creating and maintaining objects, set up replication and so on.
|
|||||||||||||