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. 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? 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. If you know of other options, please let me know. Best, Martin [1] https://gitlab.com/gnutls/gnutls/blob/master/tests/seccomp.c
