Bug#1020328: Acknowledgement (Native systemd units)

2022-12-07 Thread Trent W. Buck
On Wed 07 Dec 2022 23:46:43 +, Richard Lewis wrote: > I have been studying and experimenting - and learning a lot. > For exim4, i found ⋯ I slurped your exim notes into my repo. I probably won't do any actual testing with exim myself :-)

Bug#1020328: Acknowledgement (Native systemd units)

2022-12-07 Thread Richard Lewis
On Wed, 9 Nov 2022, 08:37 Trent W. Buck, wrote: > My old (Debian 9) notes about different techniques are here: > > https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES > > This is an amazing resource! (did you consider trying to introduce it into a

Bug#1020328: Acknowledgement (Native systemd units)

2022-11-09 Thread Trent W. Buck
On Wed 09 Nov 2022 19:29:56 +1100, Trent W. Buck wrote: > 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. > >

Bug#1020328: Acknowledgement (Native systemd units)

2022-11-09 Thread Trent W. Buck
On Fri 04 Nov 2022 00:45:52 +, 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

Bug#1020328: Acknowledgement (Native systemd units)

2022-11-03 Thread Richard Lewis
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

Bug#1020328: Acknowledgement (Native systemd units)

2022-09-26 Thread Trent W. Buck
UPDATE: a debian/logcheck.tmpfiles (/etc/tmpfiles.d/logcheck.conf) is also needed. The security hardening I added prevents logcheck from creating it. See attached. # Hardened logcheck.service started complaining after a reboot: # # systemd[1]: Starting logcheck — email sysadmin about