silly quesiton

[John Stoffel]

>>>>> "Marc" == Marc  <Marc at f1-outsourcing.eu> writes:

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.  They only need access to the
application.

That's why virtual users are 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.  


Marc> I argue exactly the opposite. Keep as much as possible linux
Marc> users. As linux has been engineered for allowing multiple user
Marc> accounts, and most other virtual user providers that are used
Marc> here, have not.
>> 
>> I'm having a hard time to parse what you are saying here.
>> 
>> I'm saying that if the mail/dovecot server is only providing mail
>> services, then putting all the users (across multiple domains even)
>> into a virtual user database is more secure

Marc> No it is not more secure, eg. 

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.  

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

So?  

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.

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.  

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?  And how postfix submission port works.  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.

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. 

>> and more scalable.

Marc> Not relevant, that is different discussion.
 
>> General users don't need accounts on the mail server, and security in
>> depth argues that keeping them off the server entirely is a good
>> thing.
>> 

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. 

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,
because it lowers the attack surface.  

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.  Which should
also be locked odwn without any system privs beyond that bare minumum
needed.

So then the attacker needs to break the application access to get into
the OS to successfully attack.

Security by layers is a good thing, and virutal users means you can
support lots and lots of users more easily in alot of ways.

John