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.