On Wed, 9 Jan 2008, Gerard wrote:
On Wed, 9 Jan 2008 12:17:22 -0800 (PST) Asheesh Laroia asheesh@asheesh.org wrote:
On Wed, 9 Jan 2008, Charles Marcus wrote:
On 1/9/2008, Asheesh Laroia (asheesh@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:
You add a UNIX UID to a system but configure the system to not give that user a login shell.
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@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.