[Dovecot] Please help me resolve why mail isn't being delivered to virtual users

[mouss]

Timo Sirainen wrote:
> On Thu, 2008-01-10 at 09:32 +0100, mouss wrote:
>> Pascal Volk wrote:
>>> 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.
>> if there's a bug in dovecot that allows this, then there will also be
>> bugs that give the whole server to the attacker...
> 
> Why? The mail handling code in Dovecot is the most complex one, so it's
> most likely to have bugs.
> 

True. I was just trying to say that things aren't as simple as "using a 
single uid is bad". As usuaul, there are tradeoffs. and IMHO from a 
security perspective, the damages caused in the case of a single uid/gid 
are low compared to those (less probable but still) caused by the use of 
privileged programs.

with a single uid/gid, it is possible to run the whole server as that 
same user, chrooted in the mailstore base. Admittedly, the server has 
access to other people's mail. (A possible workaround would be to run 
privileged and once a user has authenticated, to chroot to the mailbox 
location. not sure this is "reasonable" though!).


>>> 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.
>>>
>> using different uids means that the delivery agent needs some privilege
>> to write to the mailboxes. In general, this is achieved by making the
>> MDA suid.
>>
>> and since we are talking about possible bugs, what do you think are the
>> consequences of potential bugs in the MDA if it is suid?
> 
> I do agree that setuid binaries are bad and hopefully one day Dovecot
> has LMTP server and there's no need for setuid-deliver. 

but even then, it will need to run with privileges to be able to write 
to people's mailboxes. I however agree that the privileges can be droped 
before complex code is executed.

> But even then
> the recommended way to set up setuid-deliver is to place it in a
> directory where only MTA can execute it, and again the (most complex)
> mail handling code is execute only after all the permissions have been
> dropped.
> 
>> Note that using different uids with virtual users don't bring much. one
>> needs to make sure there is no uid collision with unix users (which
>> means you must make sure adduser doesn't create an account with a uid
>> used by a virtual mailbox). the only thing it brings is that the uid has
>> no "name" and can't login.
> 
> It's more complex to set up, but it also does limit the damage that
> security holes can do. Two of the four security holes found from Dovecot
> already were completely prevented if each user used their own UID.
> 
> Or if you're just arguing about multiple UIDs for virtual users vs.
> using system users (I just quickly scanned through this thread), then I
> don't see much of a difference. From Dovecot's point of view there's
> none.

in the last paragraph, I was comparing virtual users with different uids 
to unix users.