[RndTbl] "washing" a fork/exec to force all groups

[Adam Thompson]

> Meh, I guess it has to be your "personal" group of specialists before
> one really pays attention?  I'm pretty sure for 80% of the daemons,
> languages, idioms, etc, I use you could easily find 5 specialists to
> say it's "unsafe".

When Wietse says "don't use procmail" many times over the last... 20? yrs, and then Gilles Chehade (OpenSMTPd) also says the same thing, repeatedly, and then I Allman said the same once when I asked in person, I just stop questioning, because I have better things to do with my time than argue with people far better-versed than I in a particular space.
(OTOH, I've argued with and corrected OpenBSD network stack devs more than once - that *is* an area where I know enough to spot errors, sometimes!)
I don't think you can possibly get better credentials than Eric Allman and Wietse Venema.  I've even seen ESR express opinions to the same end, although whether he's credible in anything is open to question nowadays... and then of course there's procmail's author's own comments: https://marc.info/?l=openbsd-ports&m=141634350915839&w=2.

Summarizing it, albeit dated: https://lwn.net/Articles/416901/

However, I'm not the person to convince you to stop using procmail, if only because *I* don't have that credibility in the MTA/MUA space, and credibility is - as you've just demonstrated - not transitive.

Allman's comment to me was oral, so there's no documentary proof of that.  (Memory is also hardly a durable medium, as I've had proven to me in the last year, no matter how clearly remembered we think something is.)

One countervailing point: 
Procmail starting becoming abandonware as of 2001, in 2014 that was codified (see link, above), BUT apparently it's under maintenance again as of 2020 (although the website is dead-ish, sigh).
LOL, even the Wikipedia page says:
	"For approximately ten years, procmail was not maintained, and multiple serious security vulnerabilities[7] were discovered in the intervening time span[3] (since fixed)."


> And if they think procmail is unsafe, then they should expound on
> precisely why it is so and post bugzillas about it so someone can make
> the CVEs!  Procmail (at least on my RHEL box) is still included as part
> of the core supported product meaning we all have an obligation to
> report sec flaws.

"Cannot be proven safe" isn't a CVE, it's an architectural problem.  And there were some CVEs, although not many.  I'm not claiming every other mail-related program is provably-secure, I'm only saying that when the people with the best credentials in the history of the universe on how to write RFC822-handling software all seem to agree that I shouldn't use procmail, I'm probably going to stop using procmail without demanding they explain their reasoning to me in detail.


> In a similar vein, is vim unsafe?  

Arguably: yes, OMG yes it's unsafe!  Yet it's still included in base for the same reason: it's a critical tool for too many people.
RH doesn't include packages based on their safety, it's nearly all based on "That One Big Customer Says They Still Need It".  That's the same logic as any commercial entity - MS is the most notable example, which is why so many garbage [mis]features stick around in Windows far too long.

You know that as well as anyone here - 99% of the programs we run on a daily basis aren't "safe" in either a theoretic (academic) or practical sense.  GNU added enough features to it that I would think twice before suggesting even cat(1) is safe.  But there are varying degrees of safety, and various approaches to it.  (Don't get me started on SELinux.)


>  Ya, but in this case nope.  I need a full-blown MTA to do all the wacky
> stuff in every direction with every option.  Only have so many static
> IPs we can assign to MTA-like programs, gotta make them count.

Er, say what?  Run them on different ports, if they're all internal, and you can use sendmail to front-end everything and pass the mails on to the internal MTAs.  You can run Postfix on loopback IPs only, if you want.  Have them use the "public" sendmail as a mailhost for sending, and use rules to fwd inbound to either custom ports or custom IPs, whichever is easier for you.  Linux lets you use the entire /8 on lo0 ad hoc, I think you'd run out of FDs before running out of IPs.

You could avoid ssh by running a daemon with appropriate permissions on lo0 and aliasing to "|nc 127.0.0.1 12345".

I'm not convinced you truly need multiple MTAs in the sense you suggest, but I'm not in your shoes so it's possible - in which case you have my sympathy :).


> I also found a way to simultaneously run sendmail and postfix on the
> same box, which RHEL really really doesn't want you to do.  

Ohhhh yeah, if you need two different MTAs on the same RH or even Deb-based system, I would recommend installing the 2nd (and subsequent, if any) from source just to avoid having them fight over who gets to be the system MTA on every package update.


> It was MUUG guys on this list that gave me all the ideas a few years
> back when I didn't know squat about git.  P.S. Switching to git was the
> best move I ever made.  Recommended, though there will be some
> wall-head-bashing, guaranteed.

You are possibly the only person I would ever /recommend/ use git!  I absolutely believe it's a good fit for your brain!  Every time I have to use git for anything non-trivial, though, I am equally-absolutely guaranteed to leave work with a headache at least 3 days in a row, usually more like 2 weeks.  If git works for you, great, meanwhile I'll be over here installing RCS.


> The key will be if
> postfix really does have that option you mentioned that really will
> make it not drop the supplementary groups.  I will try that next!  Love
> the idea of cutting out the "middleman" programs where possible.

Sorry to bear this bad news, but yeah, the same behaviour applies for aliases "|" execution.  That's actually where it's documented.  ☹  See above comments for possible workarounds.


> Postfix ticked me
> off; and I love a good unix-y problem to boot.  If you ever find the
> rationale for the "feature", post it to the list!  

No rationale as yet, but it happens in set_ugid.c: https://github.com/vdukhovni/postfix/blob/master/postfix/src/util/set_ugid.c

The dropping-secondary-groups thing was present in postfix-beta-19990122, which I think would have been somewhere just before v0.8.  I haven't been able to find any earlier source code, so it's essentially been there forever.  And nary a mention in the HISTORY file about why.

The only clue I have is the original name of Postfix, which is IBM's "The Secure Mailer" as documented in that source code file, and irrevocable operations like this are a common "smell" for "secure" programs.  I'm in agreement with you here, it seems unhelpful, so hopefully someone else here can explain why secondary groups are *so* bad for security they need to be nuked from orbit?

-Adam