silly quesiton

[Marc]

> 
> Marc> Why? Just disallow login, and that is from the perspective that
> Marc> a mail user should be limited mail resources.
> >>
> >> If the user does NOT need to login to the dovecot/mail servers, then
> >> not having these users at all is more secure.
> 
> Marc> No, because there is a difference between a need to login and
> Marc> the presence of a uid. Lots of daemons run under accounts that
> Marc> cannot login.
> 
> 
> You're missing my point.  Yes, the daemons running the services are
> locked down.  But the users using those services have no need to for
> logins or access to the system. 

I am not missing the point. I am stating that it is very common to have users that are limited, nothing more nothing less. 

> They only need access to the
> application.

Incorrect, they also need to have access the file system. 

and if I process is spawned under the uid of the logged in user, then only those files having those uid's are available. So if there is some sort of problem in the code of the spawned process it is only limited to the current uid environment.

> That's why virtual users are good.  

That is why the use of tooth paste is good!

> Also, UIDs used to be limited to
> under 65,000 seperate logins, but early on large FTP and ISP sites
> disovered that they wanted to have more user than that, so moving to
> virtual users was the solution.

Again not relevant for the discussion

> Marc> 1. if a user does not exist on the os, how can processes be
> Marc> spawned as these uid's. Everything is running under the same
> Marc> uid.
> 
> Yes, the daemons/applications running the service being provided runs
> under a single UID.  Which is more secure becuase now you have just
> one UID to lock down tight, using apparmour, selinux or other OS level
> tools.

Indeed so if you argue the running under separate uid's is more secure. How can you also argue exactly the opposite that running all virtual users as a single uid is more secure. These statements are contradictory.

> Marc> 2. if you do not use separate users, everything is written under
> Marc> the same uid.
> 
> So?

So if something is wrong with your application. Say a user can escape, all other users data are available.
if the process runs under the uid, even if the user can escape it somehow, the linux os will limit this user to the files it is owning.

> Marc> 3. most amateurs use a crappy mysql as backend for virtual
> Marc> users. The likelihood of that being compromised compared to the
> Marc> linux os is much and much higher.
> 
> How would it be compromised?  What makes you think that the backend
> database is even exposed to the internet at all?  In a smart setup,
> it's configured so that only local access works, or only access from a
> restricted set of IPs with restricted logins is allowed access.

Is not relevant.

> Marc> 4. Say you are more professional and setup an ldap server (with
> Marc> correct acls (which is not trivial at all)) If you would have
> Marc> dovecot use it as a backend for virtual users. Does dovecot
> Marc> relay that user auth information or does it need some static
> Marc> bind. The static bind is already an increased attack
> Marc> surface. Better is have the os use the ldap backend and have
> Marc> dovecot use the os.
> 
> The static bind is fine, because you do not bind to AD as a root user,
> but only as a user with the minimum needed access to do the queries.

Incorrect, a static bind requires more privileges (searching acl etc) then simple auth request, ofter also on a lower ssf. But you are missing the most important point here. 

> Marc> 5. I would even argue that having dovecot 'outsource' the user
> Marc> management to the linux os is more secure. Because dovecot
> Marc> developers are more experienced in programming the email
> Marc> application and have far less experience with authorization,
> Marc> authentication than the linux developers. There is much more
> Marc> scrutiny on the linux os than the dovecot user system.
> 
> You really don't know how authentication and access to IMAP mailboxes
> works, do you?  

I think my knowledge exceeds yours, although I do not see myself as an expert.

> And how postfix submission port works.  

How is this relevant

> Regular port
> 25 SMTP traffic doesn't have access controls, but it's also not where
> you accept email that gets sent to other domains, you only accept
> email for your destination domains.

How is this relevant

> Submission port 587, for accepting outgoing email to be sent outside
> your your domain, needs and requires authentication.  It's part of the
> specs that mail clients need to implement properly.

How is this relevant 

> 
> Marc> You constantly apply incorrect logic. You think that "keeping
> Marc> them off the server entirely" equals virtual user. "keeping them
> Marc> off the server entirely" also includes /sbin/nologin.  According
> Marc> to your incorrect logic’s, you support my statement because in
> Marc> my case users are kept off.
> 
> Again, you're not being clear here.

The idea is that if you tell me I am wrong, you proove me wrong. But you are stating something that substantiates my case. Simply said you are telling me I am right, but you do not notice it.

> Marc> If your logic’s is incorrect, how can your conclusion be
> Marc> correct? Repeating this does not make it true, the alternative
> Marc> is far worse.
> 
> You're telling me my logic is broken, but I keep giving you reasons
> why I stand by my assertion that having virtual users is more secure,

Yes to me an indication of incorrect logics, is referring to not relevant things. Often when people can not prove their case they prove something unrelated. Something like the earth is round, that is why I am right.
Sort of how you here refer to MTA's.

> because it lowers the attack surface.

I wonder if you know what the definition of this is. I will tell you how I see this. The attack service is primaraly dovecot. A dovecot hack is limited if dovecot process run under uids, and processes running under specific uid's are quite well managed by the operating system.


> Marc> Linux always does a better job on permissions, users,
> Marc> authentication than whatever 3rd party software. And if you
> Marc> outsource this to linux you have even more possibilities by
> Marc> using selinux rules.
> 
> You need to think of security happening in layers.  Keeping users
> virtual means they have an outer layer to penetrate to get access, but
> they only get access to the UID of the mail/imap user.  

First of all 'real' virtual users do not have a uid. What is even virtual about a user that gets an os uid? The fact that the dovecot developers are using uid's is already an argument that a virtual users environment is to risky.
So they have build a 'semi' virtual user environment that utilizes the os file permissions. userdb/passwdb files even have a /etc/passwd file structure. They are just in a different location where the os does not know about it. Personally I think it is quite 'crappy' to start using uid's, that the os does not know anything about. 

> Which should
> also be locked odwn without any system privs beyond that bare minumum
> needed.

You can not use this argument with virtual users, this an argument for me having users in the os.

> Security by layers is a good thing, 

Why are you writing this? Is anyone disagreeing on this point?

>and virutal users means you can
> support lots and lots of users more easily in alot of ways.
> 

I just wrote, how is it relevant? The idea is that you read the arguments and learn. I think the arguments are made and people can decide what is more secure. So in future do not advice someone upon what is most secure, but link to this thread instead.