[Dovecot] Last login tracking with login_executable
Hi,
I'm using Dovecot 1.2.14, and I've read PostLoginScripting on the wiki.
Is there any way to make Dovecot use the same username/password for database access as userdb and passdb queries? Specifying the password with -p doesn't seem like a good idea, so I'm wondering if it can be handled by Dovecot directly.
Or is it possible to track last logins with a plugin similar to quota?
-- Denny Lin
On 13/10/2010 13:14, Denny Lin wrote:
Hi,
I'm using Dovecot 1.2.14, and I've read PostLoginScripting on the wiki.
Is there any way to make Dovecot use the same username/password for database access as userdb and passdb queries? Specifying the password with -p doesn't seem like a good idea, so I'm wondering if it can be handled by Dovecot directly.
Or is it possible to track last logins with a plugin similar to quota?
So you have read here: http://wiki.dovecot.org/PostLoginScripting
What are you trying to defend against that this isn't covered here?
If your risk is that the user compromises the login process and can see the login script then why not create a separate user who only has permission to touch the "last_login" table. If that's not enough then drop all that into a script and remove permissions from the script (I think chmod -r+x works?).
One step up might be to a) create a new user b) grant that user ONLY access to a stored proc c) now their only ability to influence the database is to call the stored proc which is itself only allowed to insert rows. Difficult to imagine how you could lock down tighter than this AND it doesn't require per-user permissions?
I think unless you enforce row level AND table level security you won't defend against someone using a per user password anyway (you need to give everyone access to the last_logins table - what stops them wiping out other users rows simply because they are logged in as them?).
Ed W
On Thu, 2010-10-14 at 09:55 +0100, Ed W wrote:
Is there any way to make Dovecot use the same username/password for database access as userdb and passdb queries? Specifying the password with -p doesn't seem like a good idea, so I'm wondering if it can be handled by Dovecot directly. If your risk is that the user compromises the login process and can see the login script
BTW. That's not enough. The login process is chrooted to nearly empty directory and can't read anything. To read the post-login script the user would have to compromise imap/pop3 process (which is more likely anyway, because they're more complex). But that could also be prevented by not giving that process read access to the script.
I think more problematic is that the -p password shows up in ps list. That can be avoided by placing the script to MySQL's config file. http://dev.mysql.com/doc/refman/5.1/en/password-security-user.html
Hi,
On Thu, Oct 14, 2010 at 03:00:32PM +0100, Timo Sirainen wrote:
On Thu, 2010-10-14 at 09:55 +0100, Ed W wrote:
Is there any way to make Dovecot use the same username/password for database access as userdb and passdb queries? Specifying the password with -p doesn't seem like a good idea, so I'm wondering if it can be handled by Dovecot directly. If your risk is that the user compromises the login process and can see the login script
BTW. That's not enough. The login process is chrooted to nearly empty directory and can't read anything. To read the post-login script the user would have to compromise imap/pop3 process (which is more likely anyway, because they're more complex). But that could also be prevented by not giving that process read access to the script.
I think more problematic is that the -p password shows up in ps list. That can be avoided by placing the script to MySQL's config file. http://dev.mysql.com/doc/refman/5.1/en/password-security-user.html
Sorry for not describing the problem clearly. Timo is spot on the problem I was trying to describe.
I was wondering if it would be possible to read the username/password from a Dovecot config file (like userdb/passdb/quota/expire) instead of using my.cnf.
Thanks!
-- Denny Lin
On Thu, 2010-10-14 at 22:04 +0800, Denny Lin wrote:
I was wondering if it would be possible to read the username/password from a Dovecot config file (like userdb/passdb/quota/expire) instead of using my.cnf.
See if something like this works:
HOME=/etc/dovecot/mysql mysql ...
And put the password to /etc/dovecot/mysql/.my.cnf
On 14/10/2010 15:04, Denny Lin wrote:
I was wondering if it would be possible to read the username/password from a Dovecot config file (like userdb/passdb/quota/expire) instead of using my.cnf.
In that case I think just creating a script with the password in it, which is itself called from login process does what you need? (As Timo just said)
In Dovecot 2 there is a move to splitting the config files up to a greater extent, so I think it can be seen really as an extension of that if you have one more file knocking around?
However, do still remember that you should almost certainly create a separate database user for this task - this user can then be locked down (eg only insert access to a single table) and in that way there is a limit to the damage they could do even if the password were compromised?
I like people who think about security though - please consider writing up your final solution on that page of the wiki so that there is a "best practice" solution on there?
Cheers
Ed W
On Thu, Oct 14, 2010 at 03:38:04PM +0100, Ed W wrote:
On 14/10/2010 15:04, Denny Lin wrote:
I was wondering if it would be possible to read the username/password from a Dovecot config file (like userdb/passdb/quota/expire) instead of using my.cnf.
In that case I think just creating a script with the password in it, which is itself called from login process does what you need? (As Timo just said)
In Dovecot 2 there is a move to splitting the config files up to a greater extent, so I think it can be seen really as an extension of that if you have one more file knocking around?
However, do still remember that you should almost certainly create a separate database user for this task - this user can then be locked down (eg only insert access to a single table) and in that way there is a limit to the damage they could do even if the password were compromised?
I like people who think about security though - please consider writing up your final solution on that page of the wiki so that there is a "best practice" solution on there?
Sorry for the late reply. I've been very busy recently (filling out university applications). In the end I decided to use Timo's solution as it seems like the best one.
Thanks for all the advice and suggestions.
-- Denny Lin
participants (3)
-
Denny Lin
-
Ed W
-
Timo Sirainen