Marco d'Itri <m...@linux.it> writes:
> On Jul 04, "Trent W. Buck" <trentb...@gmail.com> wrote:
>
>> * If it runs its own process manager (e.g. postfix's "master"),
>> don't bother trying to harden it.
> I disagree. It may not be possible to use NoNewPrivileges, but at least
> file system hardening is usually trivial to enable for most daemons.
>
>> * If it sends mail via /usr/sbin/sendmail,
>> don't bother trying to harden it.
> See above.
Let me tone down my answer: rather than "don't bother",
I should have said something like "focus on other daemons first".
You've convinced me we can still do the "easy" bits of those daemons,
e.g. ProtectSystem= and ProtectHome= as you suggested.
Usually I got so annoyed that I just gave up and moved onto the next
daemon, though -- hence my initial rule of thumb :-)
For the record,
I think "can't do NoNewPrivileges=" also precludes all of:
Importance
2.0 SystemCallFilter= <-- these are the ones
0.9 RestrictNamespaces= <-- I appreciate the most
0.9 RestrictAddressFamilies= <--
0.4 DynamicUser=
0.2 SystemCallArchitectures=
0.2 RestrictSUIDSGID=
0.2 ProtectKernelTunables=
0.2 ProtectKernelModules=
0.2 ProtectKernelLogs=
0.2 ProtectClock=
0.2 PrivateDevices=
0.2 NoNewPrivileges=
0.1 RestrictRealtime=
0.1 ProtectHostname=
0.1 MemoryDenyWriteExecute=
0.1 LockPersonality=
0.0? SystemCallLog=
Oh, before I forget:
someone pointed out to me that distros probably can't enable
SystemCallArchitectures=native, because multiarch
(e.g. if you want to use nginx/i386 on amd64,
nginx.service can't SystemCallArchitecture=native).
>> If it sends mail via smtp://localhost, that's MUCH easier.
>> Start encouraging upstreams to do that instead?
> Do you know an appropriate C library that could be used?
> Speaking proper SMTP is a bit harder than rfc821 | sendmail, so let's
> try to not overshoot...
My solution was to use msmtp as a sendmail(8)-to-SMTP adapter.
Something like this:
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-via-msmtp.conf
I'm using that in production, for uh... logcheck (bottom of the file):
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1020328;filename=logcheck.service;msg=5
I'm using the same trick for a PHP5 app which uses RootImage= (instead
of docker). Turns out Docker's PHP5 containers are ENTIRELY built
from jessie; my RootImage= mmdebstrap --variant=apt bullseye, with only
src:{php5,uwsgi-plugin-php,uwsgi}/jessie.
Anyway, inside that RootImage= is just enough msmtp to make
https://www.php.net/manual/en/function.mail.php (/usr/sbin/sendmail)
get forwarded to smtp://localhost:25 -- which is postfix OUTSIDE the RootImage=.
'mmdebstrap', ⋯,
'--include=msmtp-mta libnss-myhostname',
'--customize-hook=(echo account default;
echo syslog on;
echo host localhost;
echo auto_from on) >$1/etc/msmtprc',
I don't know whether it's reasonable to make C daemons in-house this via
a C library. For things like python and emacs, it's pretty much just a
matter of changing "import sendmail" to "import smtpmail".
Daemons that expect to send a lot of email often have an existing config option
for this.
Daemons that only send mail incidentally, or
have never had to deal with Windows,
are more likely to just use mail(1) or /usr/sbin/sendmail.
PS: note that msmtp-mta nowadays includes msmtpd.service which just accepts
mail on localhost:25 and forwards it to /usr/bin/msmtp, which
can then forward it to the "real" mail server.
For my personal setups, this means I have an easy way to guarantee all hosts
have a smtp://localhost:25 listener,
then same way I have historically guaranteed all hosts have a
/usr/sbin/sendmail.
Again there's a big difference between "I do this by default" to "Debian should
do this by default".
I can see a lot of pushback about having msmtpd.service on by default –
at least until it's renamed to systemd-mail-submission-agentd :-)
>> Moving pidfiles from /run/%p.pid to /run/%p/%p.pid and
>> letting systemd do the User=%p can help quite a bit.
> In general, all services should be STRONGLY encouraged to use
> RuntimeDirectory, StateDirectory, etc...
> Also because this makes possible implementing the "file system factory
> reset" patterns.
No argument here.
Note one gotcha is if you have something nuanced like
motion:root 755 /var/lib/motion/
motion:motion 750 /var/lib/motion/incoming/
motion:adm 750 /var/lib/motion/CCTV-recordings/
motion:adm 640 /var/lib/motion/CCTV-recordings/2023-01-01T00:00:00.mkv
Then systemd can go
"oh, your owner/permissions changed -- I'll fix that for you" and
RECURSIVELY chown/chmod, messing up your inner settings.
I forget exactly how I triggered that, but
it was one of those "systemd isn't WRONG, but that was unexpected"
cases. It might only happen if you're using tmpfiles.conf as well?
This shouldn't ever affect actual users, but
it's something packagers should be aware of while they're testing out
different .service configs (if not doing a full OS rebuild between tests).
