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.