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

[Trevor Cordes]

On 2023-04-19 Adam Thompson wrote:
> 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.

Still meh.  Name dropping doesn't excite me.  Ya, might perk my ears up
a tad more than nobodies, but many will have an agenda.  We all know
many *BSD people seem to have a severe NIH complex.  And the author of
Postfix already has a hate-on for anything sendmail-era right out of
the gate.  If I find 5 prominent UNIXers that still use procmail, does
that make me the winner?  It's all rather silly.  We've had the exact
same discussion about sendmail, and ... and ...

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

I love it, it looks like a Lennart or PHP-voting-majority "argument":
======
The merits of the competing filter-writing syntaxes are a bit
subjective, but it is easy to see that procmail's recipe syntax is more
terse, using non-alphabetic characters and absolute positioning in
place of keywords like "if" and "to."
======

Oh noes, it's terse and a computer person might actually have to learn
a new "language" like they do all the time when language-du-jour comes
out and they have to tweak code.  The horror!

The replacement uses "if" so it must be better!  Ya ok, maybe to some
kid just starting out, but not (again the whole point) someone who has
been using it since 1993.

I find this more convincing:
"it is feature complete and apparently pretty bugfree"

as it echoes what I said.  Why can't the program just be "good" and
"done"?  I don't rewrite all my 10 and 20 year old code every few years
for kicks just because.

<much tongue-in-cheek, and cheekiness; apologies>

> 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)."

I followed the rabbit hole and it looks like as bugs were found, people
talked about it and distros added patches to the src rpms.  Sounds par
for the course.

But speak of the devil:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633
scroll to bottom

Someone seems to have taken it over and fixed any recent bugs,
including a formail (companion program not used as much) heap overflow.
A new version with a new minor number (24) has been released and should
worm itself into the distros.

So if the main point is it's "abandonware", then that seems to settle
that.

Message #44 in that link is from the original author (van den Berg)
himself, and is an interesting read.  Especially:

========
What can we learn from this:
a. Clearly I had my security focus on procmail back then.  But all the
critical paths have been audited to pieces before the year 2000.
...
>From a statistical standpoint, given the points a) to d) above, I'd say
that procmail/formail have a above average track record and can be
trusted.
========

Mic drop?

The only real thing I see in any of the forks' issues pages is handling
stuff like UTF8 headers.  But in all my time I've yet to see where this
is *required*.  You can still use procmail regex to match the funky
encoded version of whatever header.  Ugly, but it works.  I have little
doubt someone will add support for them into procmail soon, as I'm sure
there's pre-existing C libraries to do the conversions, and turning on
UTF8 shouldn't be hard (though I do live outside the world of C)?

> 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.

Fundamental philosophical differences.  I don't listen to any voice of
authority asking me to change unless I can do my own exhaustive research
and come to my own conclusions.  (Hmm, where have we all recently had
experiences with this dilemma?)  Maybe that's why I rarely change
anything, ever!  Hah

I'd put more stock in the opinion of MUUGers (including yours) than
rando wizzardz (hehe) on the interwebz.

> 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.

But aren't you then ruining your original argument that we shouldn't
use procmail because "people" declare it unsafe?  So then it becomes a
matter of degrees and the level of "convincing" one is subjected to?

If unsafe -> discontinue use, and you just said vim -> unsafe, then you
have just said vim -> discontinue use.  Have you discontinued use of
vim?

> Er, say what?  Run them on different ports, if they're all internal,

Nope, both sendmail and postfix are external-facing.  The requirement
is each IP appears to the world as its own box, with no trace or
mention of the other (legal-ish privacy-ish reasons).  Neither should
send/receive through the other's IP. Postfix can do it, sendmail
cannot.  That was my problem.

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

Yup, I just dreamed up using a named pipe or similar last night.  But
then I'd still need to root to make sure the daemon auto-restarts if it
dies.  So not much better off, unless systemd has an unprivileged-user
service concept now(? man that would be handy).

> 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 :).

Ya, trust me, I explored every avenue (short of VMs; though maybe
there's a container / jail way?).  The pain was great, but the pill has
been swallowed so no sense finding a "better" solution now.  Well, at
least until my sendmail+postfix twinning blows up due to RHEL clamping
down on the thumbscrews.  But at least I'll have a relatively painfree
option of just twinning my postfix config and ditching sendmail (or
sendmail will have the outgoing IP configurable by then).

> 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.

Turns out it wasn't a problem.  The /etc/alternatives setup and
interesting use of options in postfix make it update-proof.  At least
until we bump up a major RHEL version number.  It was quite hard and
interesting with no guarantee of success, but it worked 100% in the end
with no downsides I can see; besides being insane.  If anyone other
than me ever wanted to do such a thing (never gonna happen) I'd do a
presentation on it.  :-)  I found zero people actually attempting or
accomplishing the feat on the net, so not much help there.

> 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.

Oh git still gives me major headaches, whenever I have to do something
I haven't done yet and have a thin grasp of how to achieve it.  I've
learned that you hair-pull for a while to get a new thing done, then
save the invocation in your cheatsheet.  The grokking part seeps in
later.

Remember "crash your system in 2 keystrokes, or less"?  Ya, git feels a
lot like that; but there's almost always an "out" -- the key is finding
it...

I've found the git books (of which I have many) teach you all this
stuff about the node graphs and such that turns out to be near useless
for actually using the thing to just dev, save and push.  Though I
guess at some level knowing the guts actually makes the final grokking
possible.  Hard to say.

I like RCS.  But RCS can't possibly do all the git does for me now.
You'd probably be impressed (or dumbfounded?): 2 levels of libraries,
and app, a "super-app" on top of that app, all with git-subtrees, 2 apps
with 4 deployments (dev, test, demo, live) each.  Everything is a git
push away from having the latest version, including an automated db
schema updater.  My dev is now warp speed and I spend no time at all on
db syncing or deployment.  A new app on the libraries can be made in an
hour by a clone and adjusting a conf file or two (mostly paths and url
prefix).  Who used to have the slogan "now you're playing with power".

> Sorry to bear this bad news, but yeah, the same behaviour applies for
> aliases "|" execution.

Damn.

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

Thanks for the link.  I love short and sweet source files.  There's the
lame setgroups in there just staring at me, mocking, doing apparently
nothing useful.

> it's essentially been there forever.  And nary a mention in the
> HISTORY file about why.

I have faith you'll eventually find the original argument you read a
hundred years ago.  Gotta be somewhere.

> 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?

That's a great question for all MUUGers to ponder.  Maybe someone has
an idea.  I mean we can all agree the smell (as you say) seems to be on
the right track, but here's my real world pain point in opposition to
it, as well as upsetting the "don't surprise the user" dictum.  Sitting
here right now I can't really thing of a really-possible security issue
caused by keeping the groups intact.  I'll ponder it further in my
sleep.

The sendmail people obviously didn't consider this a "bug", unless they
really just never thought of it.

As such, if the braintrust of MUUG can't imagine a reason, it may be
productive to open a postfix bug/featurereq for it.  At least that
might make the devs justify the original choice.