Privilege Separation

This page is about how to implement privilege separation, some of the tasks involved, and what privilege separation would do.

What it means

Privilege separation means preventing the following:

  • Unauthorized theft of data
  • Unauthorized access to knowledge
  • Unauthorized destruction of data

Generally, privilege separation involves making the database engine handle the above with access controls (GRANT/REVOKE). Privilege separation for DBMail works under the premise that the people who make the database and the operating system already have to deal with security on these fronts, so let's let them handle it for DBMail while it's free.

What's involved

But it's not really free. DBmail requires a relatively large number of changes, and although most of them should be fairly simple, there are a few deep cuts.

The biggest change is making one collection of dbmail tables per-user. This is fairly easy to accomplish- simply override the prefix (DBPFX) and have it include the username (i.e. dbmail_physmessage → dbmail_geocar_physmessage)

This means we won't need dbmail_users anymore- or at least, it won't contain passwords. It could simply contain a mapping for invalid usernames → table prefixes.

The login procedure would need to perform the database-engine specific login method using the specified username and password. Because this would ordinarily make non-plaintext logins impossible (without database assistance), we'd need a new dbmail_shadow table that would ONLY be accessible in a limited way. This would be called “dbmail-auth”

dbmail-auth would start as a shadow user, and if a dbmail-imapd process logs in correctly, it is given a “real” username and password (or on some platforms, the already logged in database handle via SCM_RIGHTS) that can be used to get access to the real data.

dbmail-auth would be very short, and very easy to audit (compared to all of dbmail-proper)

The LIST/NAMESPACE/LSUB routines (and all the mailbox location code) would need to be changed as well, in order to support multi-user access to a shared mailbox (i.e. dbmail_acl). This, unfortunately, would probably be the messiest set of changes.

Handling SQLite

To safely handle SQLite, the procedure must be a little bit different:

  • dbmail-auth looks in shadow.sqlitedb for authentication, but not mapping
  • dbmail-auth checks the access control table and ATTACHes any user-mailbox.sqlitedb files that are interested (ATTACH makes it possible for a single SQLite session to access multiple databases)
  • dbmail-imapd runs chrooted in a directory that doesn't have access to the .sqlitedb files
 
privsep.txt · Last modified: 2012/02/12 16:33 by are
 
DBMail is developed by Paul J Stevens together with developers world-wide