On 2020-11-21 4:02 a.m., Martin Lambers wrote:
On Fri, 20 Nov 2020 10:35:00 -0500, Simon Deziel wrote:
A big problem is that users do not know where to look if they get an
unexplainable "permission denied" error. Almost nobody knows that
AppArmor interferes.
A working AppArmor profile would have to allow reading, writing and
executing arbitrary files, which would make it pretty much useless.
I therefore propose to either remove the AppArmor profile or
restrict it to the msmtp-mta package, so that most users can
continue using msmtp as expected.
I'd like to propose to continue shipping the Apparmor profile but have
it disabled by default. This way it would be an (easy) opt-in
procedure for those who want the additional security and not even a
concern for others. Presumably, those opting in would be more savvy
with Apparmor and should in theory not send you as many bug reports.
Would that work for you?
Yes, an opt-in approach seems ideal.
Here's the proposal:
https://salsa.debian.org/kolter/msmtp/-/merge_requests/16
I appreciate your work on securing msmtp; it's just that the current
approach causes problems. The threat scenario is a malicious SMTP
server trying to trigger a bug in msmtp, right?
Another use case is to limit transitions between Apparmor confined apps.
If you lockdown a daemon (like apache2) with Apparmor, you can still
permit it to send emails by allowing it to execute msmtp in its own profile.
For that case, I
thought about adding seccomp() after the configuration is initialized
(file read, logfile opened, passwords acquired) but before connecting
to the SMTP server. Msmtp would still need memory allocation and
temporary file usage. When TLS is involved, things are more complex.
GnuTLS requires a long list of syscalls to work properly [1], and
that list will probably change with future versions, so using
seccomp() here seems complex, fragile and hard to maintain.
Something like OpenBSDs pledge() would be simpler, but still require
knowledge about the requirements of GnuTLS.
seccomp() seems brittle and overly complex when compared with pledge()'s
simplistic beauty. One can hope though [1].
Regards,
Simon
[1] https://github.com/seccomp/libseccomp/issues/71
