dovecot - Mar 2023 - Postfix : root and system user authentication

Le mardi 14 mars 2023 ? 22:32, dovecot at ptld.com a ?crit :
>> However, when we have a postfix server on the same machine, 
>> that delegates authentication to dovecot SASL ... we can indeed 
>> log in as root on the postfix server.
>
>
> You are not logging into Dovecot with root, you are connecting 
> to Postfix for submission.
>
> When you connect to dovecot using linux users (PAM) the process 
> running takes on the UID of the login user to give file 
> permissions to read that users home directory where email could 
> be stored. The risk being if someone had root UID:0 they could 
> read anything on the server, not just the home directory of a 
> user.
>
> But you aren't logging into Dovecot, you are connecting to 
> Postfix. You aren't
> checking mail or reading directories. You are only submitting an 
> email to
> Postfix for submission services. Postfix runs as its own Postfix 
> UID no matter
> who you authenticate as. So even though you are authenticating 
> yourself with
> root credentials, you aren't doing so as the root UID, you 
> aren't reading email,
> and you aren't accessing any file systems like Dovecot would be.
I agree that this is absolutely not the same in terms of security.

The thing I'm worrying about is a lot less dangerous than what 
you're describing, no arguing about that. It's just, if we imagine 
that we have disabled root ssh access, and password ssh connection 
(allowing only keypair connection), this situation provides the 
port 465 as another way to test passwords, for instance. I would 
just like to be able to implement on port 465 more or less the 
same requirements I have implemented on port 22, and on port 993 
as well through the use of {first,last}_valid_{u,g}id : a static, 
and well-known set of users that are allowed to try and 
authenticate, even though, as you say (and I agree), that the risk 
is absolutely not the same as with SSH or IMAPS.

So, am I to understand from your answer that the fact that login 
with root or with users not respecting {first,last}_valid_{u,g}id 
is only applicable to dovecot direcly, not to other processes that 
have delegated authentication to dovecot ? In other words, that 
this is a feature and not a bug ?

Best,

Aymeric

>>> However, when we have a postfix server on the same machine, that
delegates authentication to dovecot SASL ... we can indeed log in as root on the
postfix server.
>> You are not logging into Dovecot with root, you are connecting to
Postfix for submission.
>> 
>> When you connect to dovecot using linux users (PAM) the process running
takes on the UID of the login user to give file permissions to read that users
home directory where email could be stored. The risk being if someone had root
UID:0 they could read anything on the server, not just the home directory of a
user.
>> 
>> But you aren't logging into Dovecot, you are connecting to Postfix.
You aren't
>> checking mail or reading directories. You are only submitting an email
to
>> Postfix for submission services. Postfix runs as its own Postfix UID no
matter
>> who you authenticate as. So even though you are authenticating yourself
with
>> root credentials, you aren't doing so as the root UID, you
aren't reading email,
>> and you aren't accessing any file systems like Dovecot would be.
> I agree that this is absolutely not the same in terms of security.
> 
> The thing I'm worrying about is a lot less dangerous than what
you're describing, no arguing about that. It's just, if we imagine that
we have disabled root ssh access, and password ssh connection (allowing only
keypair connection), this situation provides the port 465 as another way to test
passwords, for instance. I would just like to be able to implement on port 465
more or less the same requirements I have implemented on port 22, and on port
993 as well through the use of {first,last}_valid_{u,g}id : a static, and
well-known set of users that are allowed to try and authenticate, even though,
as you say (and I agree), that the risk is absolutely not the same as with SSH
or IMAPS.
> 
> So, am I to understand from your answer that the fact that login with root
or with users not respecting {first,last}_valid_{u,g}id is only applicable to
dovecot direcly, not to other processes that have delegated authentication to
dovecot ? In other words, that this is a feature and not a bug ?

Me personally, this is why i prefer to use virtual users stored in a database
for email and never use linux users. I have ultimate control over what users can
be authenticated or receive email. I can add flags to the DB query to fail an
otherwise valid user. Why would i want a root@ email address? Why would i want
my system to accept email for httpd from some stranger on the internet? Why
would i want to have to create a linux user at the OS level just to add a
mailbox?

I have a solution to my problem.

For reference, I am putting it here :

I recall that my issue is that postfix authorises login with root 
(or other users), even though authentication is delegated to 
dovecot, and the documentation about {first,last}_valid_{g,u}id 
seems to say that is should not be possible (and that 
authentication to dovecot with root is also forbidden in a 
hardcoded way).

I thank Mr. Ardley to have pointed out that dovecot delegates the 
authentication to PAM.

What actually happens (in my case at least) is that dovecot 
questions PAM about a specific authentication attempt, and 
receives PAM's answer. Then, *and only for itself*, it applies its 
own restrictions regarding root login and 
{first,last}_valid_{g,u}id. When it authenticates on behalf of 
postfix, it notifies postfix of success directly.

So the semantic of {first,last}_valid_{g,u}id should be understood 
for dovecot only, not for other processes that have delegated 
authentication to dovecot, which answers my first question.

Then, on how to effectively restrict postfix submission login 
based on uids, the simple solution not involving virtual users is 
to set these conditions in PAM directly.

The conditions that dovecot must match in order to succeed 
authentication with PAM are in the file /etc/pam.d/dovecot (at 
least on Debian) :

#%PAM-1.0

@include common-auth
@include common-account
@include common-session

A simple way to restrict login based on uids is to modify the file 
as such :

#%PAM-1.0

auth    required        pam_succeed_if.so uid > 500 quiet
@include common-auth
@include common-account
@include common-session

Now, in order for dovecot (and *for every process it authenticates 
on behalf of* as well, which is what matters) to succeed 
authentication, the uid will have to be greater than 500. It is 
possible to specify other conditions as well, see 
https://linux.die.net/man/8/pam_succeed_if.

Best regards to everyone,

Aymeric