[Dovecot] How to achieve proper privilege separation?
I'm using a simple mbox config with regular Unix users and pam authentication.
I'm also using grsecurity. That's why I see what dovecot does in which users' name. As times goes by and new versions are coming I can frustratedly see, that more and more tasks are performed as root. Why?
When I used 1.x series of Dovecot, imap process started in the name of the user whose mbox was accessed. Now I can see, that nearly every task is performed by root. Why? It even tampers with the mail directories of each user as root instead of the user as it was usual long before.
Please let me know how should I change the config to make dovecot stop using root privileges and revert it back to the old behavior.
Thanks for your help: Dw.
Here's my current config: dovecot -n # 2.0.17 (684381041dc4+): /etc/dovecot/dovecot.conf # OS: Linux 3.2.6-hardened i686 Gentoo Base System release 2.0.3 auth_socket_path = /var/run/dovecot/auth-userdb auth_verbose = yes auth_worker_max_count = 16 base_dir = /var/run/dovecot/ disable_plaintext_auth = no first_valid_gid = 99 first_valid_uid = 1000 hostname = host.name last_valid_gid = 65533 last_valid_uid = 1003 listen = * mail_access_groups = mail mail_full_filesystem_access = yes mail_gid = mail mail_location = mbox:~/mail/:INBOX=/var/spool/mail/%u mail_max_keyword_length = 150 mail_privileged_group = mail mail_uid = mail passdb { args = * driver = pam } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } postmaster_address = postmaster@host.name protocols = imap service auth-worker { user = root } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } service_count = 1 vsz_limit = 16 M } service imap { process_limit = 4 vsz_limit = 64 M } ssl_cert = </etc/apache2/ssl/cert-file.pem ssl_key = </etc/apache2/ssl/key-file.pem userdb { driver = passwd } verbose_proctitle = yes protocol lda { mail_plugins = sieve } protocol imap { imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags imap_max_line_length = 64 k
-- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
On 23.2.2012, at 7.20, Tóth Attila wrote:
I'm using a simple mbox config with regular Unix users and pam authentication.
I'm also using grsecurity. That's why I see what dovecot does in which users' name. As times goes by and new versions are coming I can frustratedly see, that more and more tasks are performed as root. Why?
Less tasks should be running as root now. The master process code is a lot smaller.
When I used 1.x series of Dovecot, imap process started in the name of the user whose mbox was accessed. Now I can see, that nearly every task is performed by root. Why? It even tampers with the mail directories of each user as root instead of the user as it was usual long before.
The imap process starts as root, does a userdb lookup and then drops privileges to that user. It worked this way before too, only the userdb lookup code was done by master process.
Unfortunately I can see, that in my case /usr/libexec/dovecot/imap accesses both the inbox and the mail directories of the user as root. Moreover, it creates the lock file as root. I can see no process running as the user.
How could I teach dovecot to start the imap process as the user. What configuration options I should blame?
Thx: Dw.
dovecot -n # 2.0.17 (684381041dc4+): /etc/dovecot/dovecot.conf # OS: Linux 3.2.6-hardened i686 Gentoo Base System release 2.0.3 auth_socket_path = /var/run/dovecot/auth-userdb auth_verbose = yes auth_worker_max_count = 16 base_dir = /var/run/dovecot/ disable_plaintext_auth = no first_valid_gid = 99 first_valid_uid = 1000 hostname = last_valid_gid = 65533 last_valid_uid = 1003 listen = * mail_access_groups = mail mail_full_filesystem_access = yes mail_gid = mail mail_location = mbox:~/mail/:INBOX=/var/spool/mail/%u mail_max_keyword_length = 150 mail_privileged_group = mail mail_uid = mail passdb { args = * driver = pam } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } postmaster_address = postmaster@ protocols = imap service auth-worker { user = root } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } service_count = 1 vsz_limit = 16 M } service imap { process_limit = 4 vsz_limit = 64 M } ssl_cert = </etc/apache2/ssl/cert.pem ssl_key = </etc/apache2/ssl/key.pem userdb { driver = passwd } verbose_proctitle = yes protocol lda { mail_plugins = sieve } protocol imap { imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags imap_max_line_length = 64 k }
-- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
2012.Február 23.(Cs) 06:29 időpontban Timo Sirainen ezt írta:
On 23.2.2012, at 7.20, Tóth Attila wrote:
I'm using a simple mbox config with regular Unix users and pam authentication.
I'm also using grsecurity. That's why I see what dovecot does in which users' name. As times goes by and new versions are coming I can frustratedly see, that more and more tasks are performed as root. Why?
Less tasks should be running as root now. The master process code is a lot smaller.
When I used 1.x series of Dovecot, imap process started in the name of the user whose mbox was accessed. Now I can see, that nearly every task is performed by root. Why? It even tampers with the mail directories of each user as root instead of the user as it was usual long before.
The imap process starts as root, does a userdb lookup and then drops privileges to that user. It worked this way before too, only the userdb lookup code was done by master process.
On Thu, 2012-02-23 at 09:03 +0100, "Tóth Attila" wrote:
Unfortunately I can see, that in my case /usr/libexec/dovecot/imap accesses both the inbox and the mail directories of the user as root. Moreover, it creates the lock file as root. I can see no process running as the user.
How could I teach dovecot to start the imap process as the user. What configuration options I should blame?
Well, that's strange. There shouldn't be any way for you to make imap access mails as root, even if you wanted to do that. If you log in as root, it'll fail with:
Error: user root: Invalid settings in userdb: userdb returned 0 as uid Fatal: Invalid user settings. Refer to server log for more information.
If there's a bug and it just somehow manages to get through that check, it fails with:
Fatal: We couldn't drop root privileges
So.. I'm not really sure what could be wrong. It makes me think maybe Gentoo's hardening features somehow mess this up, but I can't really think of how that could either.
Set auth_debug=yes and mail_debug=yes. What does it log when logging in?
In the mean time I've upgraded to 2.1. I've enabled debug logging and logged in.
I suspect that hardening features can be blamed for my problem. After booting a previous kernel the behavior was reverted.
Here is what I got. As I can make it out it uses the proper user for the imap process according to the logs.
Thx: Dw.
Feb 23 20:49:39 atoth dovecot: master: Dovecot v2.1.0 starting up (core
dumps disabled)
Feb 23 20:50:12 atoth dovecot: auth: Debug: Loading modules from
directory: /usr/lib/dovecot/auth
Feb 23 20:50:12 atoth dovecot: auth: Debug: auth client connected (pid=16584)
Feb 23 20:50:12 atoth dovecot: auth: Debug: client in: AUTH 1
PLAIN service=imap secured lip=127.0.0.1 rip=127.0.0.1 lport=143
rport=50264 resp=<hidden>
Feb 23 20:50:12 atoth dovecot: auth-worker(16586): Debug: Loading modules
from directory: /usr/lib/dovecot/auth
Feb 23 20:50:12 atoth dovecot: auth-worker(16586): Debug:
pam(atoth,127.0.0.1): lookup service=imap
Feb 23 20:50:12 atoth dovecot: auth-worker(16586): Debug:
pam(atoth,127.0.0.1): #1/1 style=1 msg=Password:
Feb 23 20:50:12 atoth dovecot: auth: Debug: client out: OK 1
user=atoth
Feb 23 20:50:12 atoth dovecot: auth: Debug: master in: REQUEST 3337879553
16584 1 0a36f4227122eb3d59466523e937b25b
Feb 23 20:50:12 atoth dovecot: auth: Debug: passwd(atoth,127.0.0.1): lookup
Feb 23 20:50:12 atoth dovecot: auth: Debug: master out: USER 3337879553
atoth system_groups_user=atoth uid=1000 gid=100
home=/home/atoth
Feb 23 20:50:12 atoth dovecot: imap-login: Login: user=<atoth>,
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=16587, secured
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: Effective uid=1000,
gid=100, home=/home/atoth
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: Namespace inbox:
type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes,
subscriptions=yes location=mbox:~/mail/:INBOX=/var/spool/mail/atoth
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: fs:
root=/home/atoth/mail, index=, control=, inbox=/var/spool/mail/atoth, alt=
Feb 23 20:50:12 atoth dovecot: imap(atoth): Disconnected: Logged out in=44
out=747
Feb 23 20:50:12 atoth dovecot: auth: Debug: auth client connected (pid=16588)
Feb 23 20:50:12 atoth dovecot: auth: Debug: client in: AUTH 1
PLAIN service=imap secured lip=127.0.0.1 rip=127.0.0.1 lport=143
rport=50265 resp=<hidden>
Feb 23 20:50:12 atoth dovecot: auth-worker(16586): Debug:
pam(atoth,127.0.0.1): lookup service=imap
Feb 23 20:50:12 atoth dovecot: auth-worker(16586): Debug:
pam(atoth,127.0.0.1): #1/1 style=1 msg=Password:
Feb 23 20:50:12 atoth dovecot: auth: Debug: client out: OK 1
user=atoth
Feb 23 20:50:12 atoth dovecot: auth: Debug: master in: REQUEST 401211393
16588 1 59b6d569049f955f31991ac3cfb1f54c
Feb 23 20:50:12 atoth dovecot: auth: Debug: passwd(atoth,127.0.0.1): lookup
Feb 23 20:50:12 atoth dovecot: auth: Debug: master out: USER 401211393
atoth system_groups_user=atoth uid=1000 gid=100
home=/home/atoth
Feb 23 20:50:12 atoth dovecot: imap-login: Login: user=<atoth>,
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=16589, secured
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: Effective uid=1000,
gid=100, home=/home/atoth
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: Namespace inbox:
type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes,
subscriptions=yes location=mbox:~/mail/:INBOX=/var/spool/mail/atoth
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: fs:
root=/home/atoth/mail, index=, control=, inbox=/var/spool/mail/atoth, alt=
Feb 23 20:50:14 atoth dovecot: imap(atoth): Disconnected: Logged out
in=42671 out=174898
Feb 23 20:50:14 atoth dovecot: auth: Debug: auth client connected (pid=16600)
Feb 23 20:50:14 atoth dovecot: auth: Debug: client in: AUTH 1
PLAIN service=imap secured lip=127.0.0.1 rip=127.0.0.1 lport=143
rport=50276 resp=<hidden>
Feb 23 20:50:14 atoth dovecot: auth-worker(16586): Debug:
pam(atoth,127.0.0.1): lookup service=imap
Feb 23 20:50:14 atoth dovecot: auth-worker(16586): Debug:
pam(atoth,127.0.0.1): #1/1 style=1 msg=Password:
Feb 23 20:50:14 atoth dovecot: auth: Debug: client out: OK 1
user=atoth
Feb 23 20:50:14 atoth dovecot: auth: Debug: master in: REQUEST 3933732865
16600 1 8382f23ff412178311e55bf74162e4cd
Feb 23 20:50:14 atoth dovecot: auth: Debug: passwd(atoth,127.0.0.1): lookup
Feb 23 20:50:14 atoth dovecot: auth: Debug: master out: USER 3933732865
atoth system_groups_user=atoth uid=1000 gid=100
home=/home/atoth
Feb 23 20:50:14 atoth dovecot: imap-login: Login: user=<atoth>,
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=16601, secured
Feb 23 20:50:14 atoth dovecot: imap(atoth): Debug: Effective uid=1000,
gid=100, home=/home/atoth
Feb 23 20:50:14 atoth dovecot: imap(atoth): Debug: Namespace inbox:
type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes,
subscriptions=yes location=mbox:~/mail/:INBOX=/var/spool/mail/atoth
Feb 23 20:50:14 atoth dovecot: imap(atoth): Debug: fs:
root=/home/atoth/mail, index=, control=, inbox=/var/spool/mail/atoth, alt=
Feb 23 20:50:14 atoth dovecot: imap(atoth): Disconnected: Logged out
in=405 out=9240
-- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
2012.Február 23.(Cs) 09:15 időpontban Timo Sirainen ezt írta:
On Thu, 2012-02-23 at 09:03 +0100, "Tóth Attila" wrote:
Unfortunately I can see, that in my case /usr/libexec/dovecot/imap accesses both the inbox and the mail directories of the user as root. Moreover, it creates the lock file as root. I can see no process running as the user.
How could I teach dovecot to start the imap process as the user. What configuration options I should blame?
Well, that's strange. There shouldn't be any way for you to make imap access mails as root, even if you wanted to do that. If you log in as root, it'll fail with:
Error: user root: Invalid settings in userdb: userdb returned 0 as uid Fatal: Invalid user settings. Refer to server log for more information.
If there's a bug and it just somehow manages to get through that check, it fails with:
Fatal: We couldn't drop root privileges
So.. I'm not really sure what could be wrong. It makes me think maybe Gentoo's hardening features somehow mess this up, but I can't really think of how that could either.
Set auth_debug=yes and mail_debug=yes. What does it log when logging in?
On 23.2.2012, at 21.56, Tóth Attila wrote:
In the mean time I've upgraded to 2.1. I've enabled debug logging and logged in.
I suspect that hardening features can be blamed for my problem. After booting a previous kernel the behavior was reverted.
OK.
Feb 23 20:50:12 atoth dovecot: imap(atoth): Debug: Effective uid=1000, gid=100, home=/home/atoth
This says that the IMAP is running as UID 1000. The code that produces this is:
i_debug("Effective uid=%s, gid=%s, home=%s",
dec2str(geteuid()), dec2str(getegid()), home);So if the process is still creating files as root, the kernel is lying..
On 24.2.2012, at 1.26, Timo Sirainen wrote:
On 23.2.2012, at 21.56, Tóth Attila wrote:
In the mean time I've upgraded to 2.1. I've enabled debug logging and logged in.
I suspect that hardening features can be blamed for my problem. After booting a previous kernel the behavior was reverted.
OK.
BTW. It would be interesting to know if the attached patch causes it to fail with the hardening patches.
It was probably caused by a bug already corrected. And not by dovecot.
commit 4fd554e3a097b22c5049fcdc423897477deff5ef Author: Brad Spengler <spender@grsecurity.net> Date: Mon Feb 20 09:17:57 2012 -0500
Fix wrong logic on capability checks for switching roles, broke policies
Thanks to Richard Kojedzinszky for reportingI'll test it with an updated kernel containing the fix.
Thx: Dw.
dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
2012.Február 24.(P) 00:28 időpontban Timo Sirainen ezt írta:
On 24.2.2012, at 1.26, Timo Sirainen wrote:
On 23.2.2012, at 21.56, Tóth Attila wrote:
In the mean time I've upgraded to 2.1. I've enabled debug logging and logged in.
I suspect that hardening features can be blamed for my problem. After booting a previous kernel the behavior was reverted.
OK.
BTW. It would be interesting to know if the attached patch causes it to fail with the hardening patches.
participants (2)
-
"Tóth Attila"
-
Timo Sirainen