Am 09.01.2008 21:43 schrieb Asheesh Laroia: > Not in the way I was describing: > > Let's say some person logs on to your Dovecot-based IMAP service and > figures out how to take over Dovecot to read and modify arbitrary files on > the system. (Timo, I hope this doesn't happen - but bear with me.) To be > clear, Dovecot's imap handler runs as the UNIX UID associated with the > user logging in, not root. > > In the virtual user setup that the thread starter described, the user > shares his UNIX UID with the other virtual users on the system. So he has > UNIX permission to read and write other users' mail.
This will be only the case, if you have a poor™ setup. If the setup is done right, each imap/pop user will have it's on UID. And therefor each imap/pop process will run with the UID from the user. ,--[ `ps aux | grep imap | head -n 5` ]-- | 70001 5691 0.0 0.0 2676 1416 ? S 12:45 0:00 imap | 70002 5693 0.0 0.0 2600 1212 ? S 12:45 0:00 imap | 70014 5695 0.0 0.0 2676 1256 ? S 12:45 0:00 imap | 70013 5696 0.0 0.0 2420 1164 ? S 12:45 0:00 imap | 70000 5698 0.0 0.0 2564 1200 ? S 12:45 0:00 imap `-- > In my setup where you assign separate UIDs to each user, the attacking > user can only read/modify the files that he has UNIX filesystem permission > to read/modify. That would limit the attacker to only being able to > destroy his own mail, unlike the virtual user setup. > >> Virtual users do not have all of their data jumbled together into one >> file, which seems to me anyway what you are referring to. > > No, I meant filesystem-level permissions. Obviously no one is talking > about different users having "all their data jumbled together into one > file"; sorry if I wasn't clear. Filesystem-level permissions are also possible with virtual Users: ,--[ `ls -l /srv/mail/1/70003 | tail -n 5` ]-- | drwx------ 3 70007 70003 4096 2007-12-31 17:48 70007 | drwx------ 3 70008 70003 4096 2007-10-16 23:07 70008 | drwx------ 3 70009 70003 4096 2007-10-16 23:08 70009 | drwx------ 3 70010 70003 4096 2007-10-16 23:08 70010 | drwx------ 3 70011 70003 4096 2007-12-31 18:19 70011 `-- > This has the side-effect of not using UNIX UIDs to isolate the different > users' data from each other. Oh, would you please explain why this should be? > Because you can gain the benefit of UNIX filesystem permissions. It's also possible with virtual domains/users. > I am sure what I'm trying to describe here; it's scenario 1. It should be > "trivial", just like adding new virtual users, and I believe the above is > the way to do it, but again I would double-check because I haven't done > this in a while and neglected to keep notes when I did it. > > I hope that clears things up. If this is getting off-topic and boring let > me know. It is very trivial to manage multiple virtual domains with a lot of virtual users: ,--[ stdout ]-- | hostname ~ # vmm da new.exmple.com | hostname ~ # vmm useradd [EMAIL PROTECTED] | Enter new password: | Retype new password: | hostname ~ # vmm ua [EMAIL PROTECTED] p4s5W0rd | hostname ~ # vmm aa [EMAIL PROTECTED] [EMAIL PROTECTED] | hostname ~ # vmm di new.exmple.com detailed | tail -n 9 | Available accounts | ------------------ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | Available aliases | ----------------- | [EMAIL PROTECTED] `-- Regards Pascal
