On 10/26/20 5:32 AM, gil...@poolp.org wrote: > October 23, 2020 6:03 PM, "Demi M. Obenour" <demioben...@gmail.com> wrote: > >> Would it be reasonable to allow the admin to configure a list of >> directories MDAs may reside in? I would like to only allow custom MDAs >> (from ~/.forward files) to be run in if they are in /etc/mail/mdas >> or ~/.config/mail/mdas. >> > > I'm unsure how to tackle this really. > > If you're going that path it will work at odds with what other MTA do and > you need approval from OpenBSD hackers that this is ok.
Indeed, it does break backwards compatibility. I understand if this cannot be enabled by default. > I'm unconvinced personally because: > > - all ports mda are installed in /usr/local/bin on OpenBSD which means it > will almost always be there if people rely on procmail, fdm or other. > > - once /usr/local/bin is in there, then you're no longer limiting to them > because any shell installed from ports is also there. > > - many people use custom mda which aren't installed system-wide and these > are not going to be part of the allowed directory. The idea I had is that /etc/mail/mdas contains symlinks to the "legitimate" MDAs installed from ports, such as fdm, maildrop, procmail, etc. And ~/.config/mail/mdas contains contains symlinks to the various user-installed mdas. It can also contain custom programs or scripts, so there is no loss of generality. In fact, a ~/.forward file that would not work under this restriction can be automatically converted into one that will, by adding suitable scripts to the user-writable ~/.config/mail/mdas directory. > Forward files serve two purposes: > > - redirecting to another address > - redirecting to another MDA > > What you're doing is restricting the second but I doubt you'll find a way > that's satisfying. If custom MDA scare you, wouldn't it be better then if > you had: > > action "foobar" mbox forward no-exec > > and toggled it off altogether ? In some cases, yes (and thank you for informing me of this feature). That said, I am not sure if it is enforced by PROC_PARENT; if not, it would not achieve my goals. That said, the real purpose of this is not to restrict what MDAs a user can choose, but what MDAs PROC_PARENT will run on behalf of PROC_PONY. When CVE-2020-8794 came out, I concluded that OpenSMTPD's privilege separation is not as effective as would be desired. The purpose of this feature is to ensure that if a rogue command winds up in an envelope file, it won't be executed. Postfix takes a different approach, but adopting that approach would likely require massive refactoring in OpenSMTPD, as well as significantly complicating error handling. There are other ways this could be handled, too. PROC_PARENT could verify that the MDA from the envelope file is actually in the user's forward file, for example. I make no claim that my solution is optimal. Sincerely, Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
