Mailinglist Archive: opensuse (1352 mails)

< Previous Next >
[opensuse] Re: Problem with suid pgms on Leap-15.0
Mark Hounschell wrote:

In the main program, not the example I provided, I fork/exec/wait. The main process still has my group memberships after that. They just don't make it into the exec'd pgm/script.
---
It seems there is an important difference here.

It appears the patch to make this work is in _bash_ -- is that
your understanding as well?

If that's the case, are you sure the groups also get dropped
when exec'ing a non-script program? I can't see how a patch in bash
would fix anything other than a bash script.
Second question -- do you want the scripts to be executed
as 'root' or as the RUID/RGID? It seems you are execing the program
(binary or script, not sure yet), as root, and whatever you are
executing is dropping the root privs. That would explain the code
snippet and patch that affects the groups on transitioning away
from root.

Observation -- your workaround forces the sub processes to run
as root -- and certainly that would get around the problem. Do you want
them to run as root? If so, fine. If not, you might switch back to the RUID before you spawn of whatever program(s) you are running. That way, theoretically, you would be in control of the ROOT->RUID
transition and avoid any possibility of groups changing due to that
being handled in some external program (like bash).

Of note -- regarding the fix using "initgroups(3)". If a user
has acquired any groups in their session after login, it sounds like
they will still lose some groups. The only reliable way I see to
avoid the problem is to have the top-level program that is running
as EUID root, to transition to whatever UID & groups are needed
for proper execution of the children or scripts AFTER the fork and
before the exec.

The whole idea of randomly resetting groups to some arbitrary
user default default makes me queezy. It seems that even though
'bash' appears to think that it should set groups consistent with a particular UID, it doesn't know where those groups came from or
where the UID came from. If the program started as user 'joe' who
is a member of 'engineers', but not a member of 'finance', it seems
that switching the UID to to someone in finance, like 'bob'
and executing bash, would give instant access to the 'finance' group
that doesn't appear to be audited. Then the script runs another suid
prog and resets the UID/RUID to 'joe' (not using bash), then joe
gets access to 'finance' w/o, for example, having a usbkey that
most in 'finance' need to enter the group (i.e. newgrp calls pam-mod that
reads usbkey).

So re-initializing the group to the user's default could drop
groups acquired, as well as temporarily add groups to a user process.
Did I mention that the idea of user-level programs assigning
groups made me queezy? Ick.


The rpm provided by Dr. Werner Fink seems to have fixed it up.
---
For you, but it still introduces new security behaviors
that I'm not entirely comfortable with. There may be no problem
and I tend to be more paranoid than many, but hey, I compile my own
bash, so what do I care, right? ;-) [ :-( waaaah].


And that makes sense to me. When I execvpe something, I am transitioning away from root.
----
Nope...exec call is in kernel -- they are changing code in
bash. It's bash that was patched to drop your groups as per some
POSixish recommendation. Now, that's not being done either -- instead
the user's original groups are being restore -- which may be fine in your
use case, but not sure about the effects in the edges & margins.

This is sorta what I meant by how sources can get modified away from what other distros use or vanilla bash, and there's little
documentation about how or why it happens -- then in fixing that little
patch's side effects, something else might be introduced entirely different
from what POSix 'recommended'. I know some of the people making these
changes are *WAY* smart, but that doesn't mean breakages can't occur
which can be worse when no one even knows the code was modified in some
unique opensuse way.


--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >