"Marc" == Marc Marc@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