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 a.user@new.exmple.com | Enter new password: | Retype new password: | hostname ~ # vmm ua b.user@new.exmple.com p4s5W0rd | hostname ~ # vmm aa c.user@new.exmple.com b.user@new.exmple.com | hostname ~ # vmm di new.exmple.com detailed | tail -n 9 | Available accounts | ------------------ | a.user@new.exmple.com | b.user@new.exmple.com | | Available aliases | ----------------- | c.user@new.exmple.com `--
Regards Pascal