hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/doc/man/man5
Modified Files: slapd-bdb.5 1.38 -> 1.39
Log Message: Support DB encryption
When this topic was first raised, I thought it was pretty useless:
http://www.openldap.org/lists/openldap-software/200202/msg00232.html
And in general, it's not even a necessary feature:
http://www.openldap.org/lists/openldap-devel/200211/msg00045.html
But it seems to be a checklist feature these days.
It may actually provide some value to sites that do regular backups of their raw DB files. It may actually be useful in some cases where you provide an encryption key on separate removable media (e.g. a USB flash drive). It might actually prevent a news article down the road on how some organization lost their 5 million record customer database and now all that unprotected data is now being exploited by criminals.
I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption.
But the question comes up from time to time, why we don't offer this feature in the DB itself, and sometimes it's easier to just say "ok" than try to educate people. (In fact we did a custom build of OpenLDAP for a bank a few years ago, that requested this feature from us. They didn't even care about the key management, the key was just a 96 character string hardcoded into the back-bdb patch. The current patch in CVS is obviously a little better than that.)
So anyway, if you're wondering, no, I still think it's a dumb solution. It's here as a marketing gimmick, for feature list checkboxes, not for any technical merit.
Howard Chu hyc@symas.com writes:
I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption.
The one place where I could see using this is if one is using OpenLDAP as the backend to a Kerberos KDC. It's considered best practice right now to always encrypt the KDC database at rest on disk, and some sites even require an administrator be present with a USB key to unlock the database whenever a KDC has to be rebooted. Given the increasing interest in using LDAP as a backend store for the KDC, this may be a simpler method for providing equivalent KDC security without encrypting various bits of data individually.
Russ Allbery wrote:
Howard Chu hyc@symas.com writes:
I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption.
The one place where I could see using this is if one is using OpenLDAP as the backend to a Kerberos KDC. It's considered best practice right now to always encrypt the KDC database at rest on disk, and some sites even require an administrator be present with a USB key to unlock the database whenever a KDC has to be rebooted. Given the increasing interest in using LDAP as a backend store for the KDC, this may be a simpler method for providing equivalent KDC security without encrypting various bits of data individually.
Yes, I guess that's a reasonable scenario. I thought about writing an overlay that can be configured with a list of attributes to encrypt, that just does that before giving an entry to the database. But in that case, you couldn't use indexing to search on any of the encrypted attributes. So encrypting the entire DB makes sense there.
Howard Chu writes:
Modified Files: slapd-bdb.5 1.38 -> 1.39 Support DB encryption
When this topic was first raised, I thought it was pretty useless: (...)
I can think of reasons to use it:
- Protecting data on the machine itself, if it gets stolen or carelessly sold. I don't know much about how that works though, in particular if one wants slapd to come up at reboot. Store the key physically in a different place, on a remote filesystem?
Data even from deleted files can be extracted. OS calls to wipe files when deleting them help, but I'm not sure if those are a guarantee that the data can't be recovered.
- Machines and OpenLDAP are quite fast nowadays. Enough so that speed may be less important to an admin than keeping backup routines as simple as possible. Or having as small exceptions as possible from site-wide practice, since DB backup needs an exception in any case.
Still, a flag which might be more useful is DB_CHKSUM, as described in "Berkeley DB Reference Guide: Berkeley DB recoverability" http://www.oracle.com/technology/documentation/berkeley-db/xml/ref/transapp/... Could offer options to (a) not use it, (b) use it when the filesystem block size differs from the DB file size, and (c) always use it. Except, I wonder if there is a good reason why this isn't already a DB_CONFIG option.
I wrote:
- Protecting data on the machine itself, if it gets stolen or carelessly sold. I don't know much about how that works though, in particular if one wants slapd to come up at reboot. Store the key physically in a different place, on a remote filesystem?
Sorry, I should have read the thread you referred to first. But still, I don't understand why it needs to be such a problem. It would need proper care, yes. The remote filesystem would have access controls for the machine's IP address and network, I presume. Or if not a filesystem, the server could fetch the keys with ldaps: or https: from a server with similar access controls:-)
-
Hallvard B Furuseth -
Howard Chu -
Russ Allbery