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

[Trevor Cordes]

On 2023-04-17 Adam Thompson wrote:
> Why: "security".  I don't recall the details, but I think I remember
> this change - quite a long time ago, and it never affected me.

Hmm, that would be an interesting discussion in and of itself.  I'm at
a loss as to how allowing the user their normal groups could present a
security threat.  Unless of course this is yet another case of the
modern practice of infantilizing the user ("they are too stupid to not
shoot themselves in the foot"); though those scenarios usually result
in a conf option that defaults to "safe", not the complete removal of a
useful feature.

> The more general solution is broadly accepted to be: stop using
> procmail.  It's ancient, unmaintained code that doesn't meet modern

Haha, we always have this discussion.  I use procmail for the same
reason I use sendmail: it's in the repos, the install isn't telling me
it's deprecated, I know it intimately, have many installs/configs in
place using it, and it works great. Do you have any idea how much time
I've saved in my life by not jumping into the "latest thing" daemon
just because?

(And now I can safely say after having to replicate a sendmail setup in
postfix that postfix is just as insane, messy and illogical to
configure as sendmail!)

If I must learn something new, I'll wait until they come out with
Postsendfixmail-ng and just skip straight to that.  :-)

> If you use Dovecot, you already have a full SIEVE implementation.  Of
> course procmail can do dangerous things that SIEVE refuses to do, but
> for most sane needs, it's IMHO far superior to .procmailrc syntax.
> Much like switching from sendmail syntax to postfix syntax.  You
> might consider that a bug, not a feature, YMMV.

I'll look into SIEVE.  However, this particular use case is to run a
bot-ish thing on the email address.  If SIEVE is some sort of client-y
thing then I'm just adding an extra layer (dovecot) for no reason.

> You could "rootwash" procmail
> itself by using a wrapper script that sudo's procmail instead of
> having procmail sudo php.

Ya, I thought of that, but still needs root to edit sudoers.

> If you don't have root on the box?  Just use .forward files.  First
> character on the first line is "|" = exactly what you're doing with
> procmail.  Wait, you still have the secondary group problem, so maybe
> SSH to localhost to get the grous back?  I'm not sure how to regain
> secondary groups without a root process adding them, sorry. -Adam 

I do have root, but I wanted a "better" answer that doesn't involve
root to update the stackoverflow with a "real" answer.

Your ssh idea would probably do the trick!!  But man is that sure
cheeseball.  Ugh, pains me to even think about the silliness of it.
But it would work I'm pretty sure!!

Man, that would be ridiculous if the only way to get these groups back
is to run through ssh!

> If it's feasible, turn on command execution in postfix, make sure
> it's using a private aliases file, and do a "|/whatever" in its
> global aliases - if the original recipient does NOT have a matching
> userid, I believe you can have that command run as root.  Running out
> the door, can't check, but that just occurred to me. -Adam

Hmm, I'll check that out too.  The big assumption there is that postfix
hasn't dropped root in that sub-daemon and/or at that point in the
master daemon.  Not that I want my program to run as root!  But I could
have it (or a wrapper) drop root before execution.

Of course, if postfix allows this, it boggles the mind why it wouldn't
give an option to keep normal groups in the local delivery agent.

On 2023-04-17 Gilbert Detillieux wrote:
> If you do resort to a wrapper of some sort, and don't want it to have 
> full setuid-root privileges, you may be able to get by with just
> setting CAP_SETGID capability on the binary.  That's all that
> setgroups*(2) would need, if the man page is to be trusted.
> (However, setting just that on the procmail binary may not be
> sufficient, if it's expecting more privileges than that.  But it
> would be worth a try.)

Hmm, I'll check that out, too.  However, that change would also need
root access to effect, and would (probably) get hosed on every dnf
update of that rpm.  In the end while safer than setuid, it has similar
problems.

On 2023-04-17 Gilbert Detillieux wrote:
> You may also just want to rethink the root problem (no pun intended). 
> Do you really need secondary groups, or could a simple change to some 
> file ownership and/or permissions accomplish the same thing?  Or 
> changing the primary group on the affected user(s)?  Of course, those 
> solutions could turn out to be worse than the problem, so YMMV.

That's a decent idea.  However, I'm always a bit freaked out making a
user's primary group something other than their eponymous group.  Not
sure if that's justified or not, but it gives me the heebie-jeebies
like I'm breaking some cardinal rule and K&R will come to my house and
beat me up.

In my case the program lies in a super complex tree into a git
repository of php with strange group structure designed to eliminate the
need for world read on the php files themselves.  Changing that
structure would be impossible in this case.  But changing the primary
group would work, with probably the only downside being any logs the
program makes would be group-permed as the "new" primary group.

The more I think about this problem, the more angry I am with postfix
and any other program that arbitrarily drops secondary groups!  I think
it took me 2 hours to debug this problem (learned way more about
procmail debugging than I ever wanted to know).  All because someone
decided that they'll do some wacky group nonsense that I'm not sure
I've ever seen any daemon do(?).  It's not expected by the user, poorly
documented, and seemingly pointless (see my comment at the top of this
email).

I kept getting a whiff of "it looks like it's dropping groups" but kept
saying "nah, it can't be insane, must be another problem" and going
down the wrong rabbit hole.  Until I reached the Sherlock Holmes moment.

This "feature" is documented, but only after a convoluted search on the
143 man/doc files in the rpm.  And no where is there an explanation:

mailbox_command (default: empty)  Optional  external command that the
local(8) delivery agent should use for mailbox delivery.  The command
is run with the user ID and the primary group ID privileges of the
recipient.
...
Mailbox delivery can be delegated to an external command specified with
the mailbox_command_maps  and  mailbox_command  configuration
parameters.  The command executes with the privileges of the recipient
user (exceptions: secondary groups are not enabled...

For my future reference and ease:
zgrep -iP 'primary group|secondary group|/etc/group' `rpm -ql postfix |
grep -iP "man|doc"` | grep --color -iP 'primary group|secondary
group|/etc/group'

I'll try out both your ideas and then update the stackoverflow.  Don't
worry, I'll take the heat for being the luddite procmail neanderthal!