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

[Asheesh Laroia]

On Wed, 9 Jan 2008, Gerard wrote:

> On Wed, 9 Jan 2008 12:17:22 -0800 (PST)
> Asheesh Laroia <asheesh at asheesh.org> wrote:
>
>> On Wed, 9 Jan 2008, Charles Marcus wrote:
>>
>>> On 1/9/2008, Asheesh Laroia (asheesh at asheesh.org) wrote:
>>>> Basically - the above is a reason to use 'adduser', not a reason
>>>> to use virtual users!  If I'm wrong, please clarify my
>>>> understanding.
>>>
>>> My understanding is using Virtual Users is inherently more secure,
>>> since the users do not have system accounts, much less shell
>>> accounts.
>>
>> There should be a straightforward way to set their shell to something
>> that prevents shell login but allows Dovecot login.  Then they have
>> their own separate security contexts (i.e., UID), so in the case that
>> Dovecot goes horribly awry each user's data is isolated from the
>> other's.
>
> Whether a user is a virtual user or a regular user makes not
> difference. Their data is still isolated from each other.

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.

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.

> A virtual user simply does not have a system account, and therefore 
> cannot interact with the system directly.

This has the side-effect of not using UNIX UIDs to isolate the different 
users' data from each other.

> Why give any user who does not require access to a system the 
> possibility of doing so by making them regular users?

Because you can gain the benefit of UNIX filesystem permissions.

> Besides, as I stated in a previous post, once in place, adding virtual 
> users is trivial and far safer than adding regular shell accounts.

Imagine these two scenarios:

1. You add a UNIX UID to a system but configure the system to not 
give that user a login shell.

2. You do not add a new UNIX UID to a system.

The two have the same effect on shells - namely, that no one new can run a 
shell.  That's what I'm saying.

>> I believe /bin/false will work for this; since it is not listed in
>> /etc/shells, shell login will fail even with e.g. ssh
>> user at host /bin/sh, but PAM should authorize the user for Dovecot.  I
>> would double-check this before using it in production.
>
> I am not sure what you are trying to describe here. It appears that you
> are not either.

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.

-- Asheesh.

-- 
Different all twisty a of in maze are you, passages little.