On Fri 04 Nov 2022 00:45:52 +0000, Richard Lewis wrote:
> Hi trent - i am interested in this approach:
>
> i see you are binding msmtp over /usr/sbin/sendmail - i dont
> understand how this would lead to a different outcome: how else does
> msmtp know where to send the mail? is there some implicit assumption
> about local delivery here? i tried testing but msmtp does not work at
> all out of the box for me - complains that it has no configuration
> file)
If you install msmtp you need to configure it.
Just as if you installed postfix, you would need to configure it.
"dpkg-reconfigure msmtp" ought to prompt you, but
here are some basic examples:
1. $ sudo apt install msmtp postfix
$ cat >/etc/msmtprc <<'EOF'
# Send everything to postfix (smtp://localhost:25)
account default
syslog on
auto_from on
host localhost
EOF
2. $ sudo apt install msmtp-mta
$ cat >/etc/msmtprc <<'EOF'
# Send everything to gmail (no "real" MTA on localhost)
account default
syslog on
auto_from on
host smtp.gmail.com
port 587
tls on
auth on
user alice
passwordeval /usr/bin/cat /etc/secret.gmail.password
EOF
$ printf swordfish >/etc/secret.gmail.password
$ chmod 640 /etc/secret.gmail.password
$ chown -h root:logcheck /etc/secret.gmail.password
> As far as i can tell, the issue isn't with the "send mail" part, but
> the part where the mta (exim/postfix) tries to deliver it
I don't know about exim.
When /usr/sbin/sendmail is implemented by postfix (i.e. "apt install postfix),
1. sendmail calls postdrop
2. postdrop is sgid postdrop, so now you run with elevated privileges
3. postdrop writes to /var/spool/postfix/maildrop, which normal users can't
write to
Note the sgid bit:
-rwxr-xr-x 1 root root /usr/sbin/sendmail
-r-xr-sr-x 1 root postdrop /usr/sbin/postdrop
drwx-wx--T 2 postfix postdrop /var/spool/postfix/maildrop
If you use systemd hardening NoNewPrivileges=yes, that DISABLES SETGID -- by
design.
So logcheck.service run /usr/bin/logcheck
which runs /usr/bin/mail
which runs /usr/sbin/sendmail
which runs /usr/sbin/postdrop
which DOESN'T get escalated privileges (group postdrop)
which FAILS to write to /var/spool/postfix/maildrop/<random file name>.
By telling logcheck.service "actually just use msmtp", the path instead becomes
logcheck.service runs /usr/bin/logcheck
which runs /usr/bin/mail
which runs /usr/sbin/sendmail (actually /usr/bin/msmtp)
which connects to (say) smtp://localhost:25 or smtp://smtp.gmail.com:587
Thereafter, the rest of the flow (whatever is listening on
localhost:25) is not running inside the logcheck.service hardened
namespace/cgroup. So it can do whatever it wants.
In short, what I'm saying is:
1. you can't harden a script/daemon that uses the "fork+exec
/usr/sbin/sendmail" API, because
different /usr/sbin/sendmail implementations (e.g. postfix) require
different privileges.
In particular, "requires setgid" prevents ALL of the following hardening
options:
DynamicUser LockPersonality MemoryDenyWriteExecute
NoNewPrivileges PrivateDevices ProtectClock
ProtectHostname ProtectKernelLogs ProtectKernelModules
ProtectKernelTunables RestrictAddressFamilies RestrictNamespaces
RestrictRealtime RestrictSUIDSGID SystemCallArchitectures
SystemCallFilter SystemCallLog
2. the smtp://localhost:25 API is usually available.
It prevents fewer hardening options:
PrivateNetwork=yes
IPAddressDeny=any
RestrictAddressFamilies=~AF_TCP
Basically you have to leave TCP/IP unblocked, but that's all.
3. msmtp is a quick and easy way to convert (1) to (2).
4. "apt install msmtp-mta" does (3) easily, but
won't work if a "real" MTA is already installed.
5. BindReadOnlyPaths=/usr/bin/msmtp:/usr/sbin/sendmail does (3), and
works even if a "real" MTA is installed.
