Re: Bug#993488: maybe reason for wontfix?
* Tomas Pospisek [210903 08:27]: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a > "wontfix + close" but no rationale. Which leaves the original reporter with > a large "?" I guess. > > I am guessing that the reason for the "wontfix" is "that's just how Unix > works unfortunately" aka "that's a Unix design bug"? Is my guess correct? > > One other question - any idea on a way forward here? I would guess that > behaviour (changing group membership won't change group membership of > running processes) is rooted somewhere quite low in the stack, maybe in the > kernel itself (or in posix :-#)? So if the original reporter would want to > go ahead and look to that problem beeing fixed would he need to go talk to > the kernel mailing list or do you have idea where he could go to? > *t Attempting to "fix" this can never fully work. One of the fundamental designs of *nix permissions is that a process can open handles with current permissions, than drop privileges below what would be necessary to open those handles, but continue to use those handles. So, even if the Linux kernel watched for group membership changes, it could only affect attempts to open new handles, not existing open handles (otherwise, much existing code intended to increase security would cease to function without any obvious way to fix it). I don't think this was a design bug, but rather a conscious design choice. Just like a process can drop permissions, the process gets is initial set of permissions from the state of the user db _at process start_, not dynamically each time a permission-checking system call is made. Suppose a root process calls setgroups to add specific supplementary groups, then sets the uid. One of the groups the process intentionally set is coincidentally one of the user's additional groups. Now the user (in the user db) is dropped from that group, but the program was written intentionally to grant that group regardless of the user's group membership. In other words, the kernel has no way of knowing whether a process was granted group access because the user was a member of that group or because the program running in that process explicitly added that group. The OP's issue is really only an issue for shells, where one might expect that a new "command" uses the current user db rather than inheriting from the shell, which got its permissions from the initial, rather than current, state of the user db. Changing the shell behavior to track the user db is fraught with security issues. Adding new groups would require the shell to maintain CAP_SETGID permissions, and properly retain or drop those permissions for each created process. This would require the shell to be setuid root to be able to work correctly in all situations. This is just not going to happen. It doesn't make much sense to me for the shell to drop removed groups but not add new groups when the user db changes. So, I think your real answer is "that's just how Unix works (fortunately)". I really think this should be tagged not-a-bug. :-) ...Marvin
Bug#993488: maybe reason for wontfix?
On 2021-09-03 14:23, Tomas Pospisek wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a "wontfix + close" but no rationale. Which leaves the original reporter with a large "?" I guess. I am guessing that the reason for the "wontfix" is "that's just how Unix works unfortunately" aka "that's a Unix design bug"? Is my guess correct? One other question - any idea on a way forward here? I would guess that behaviour (changing group membership won't change group membership of running processes) is rooted somewhere quite low in the stack, maybe in the kernel itself (or in posix :-#)? So if the original reporter would want to go ahead and look to that problem beeing fixed would he need to go talk to the kernel mailing list or do you have idea where he could go to? Processes in *nix inherit permissions. That's inherent to the design. If you want more guarantees, you need to move from discretionary access control (based on the identity at the time of process (tree) creation) to mandatory access control (e.g. SELinux). Kind regards Philipp Kern
Re: Bug#993488: maybe reason for wontfix?
Tomas Pospisek wrote: > I am guessing that the reason for the "wontfix" is "that's just how > Unix works unfortunately" aka "that's a Unix design bug"? Is my guess > correct? I would call it a "Unix design decision" or even an "OS design decision", because Windows (of the NT variant) has made the same decision: Not allowing changes to running programs or sessions vastly simplifies everything. (Yes, with AD you can refresh some of the memberships in a purely Kerberos environment and for local group you can use "runas" to get the new groups for a new process, but the same can be done in Unix as well.) In the then I can see the designers thinking "a change in group membership is happening not often, allowing or optimizing this use case will be a huge hassle" and thus never implemented or even mandated its existance. And now this is so baked in to everything that suddenly allowing it would break many programs, without a doubt. In the end, this tag is a more "cantfix" than a "wontfix", because you basically can't, without creating a new OS. Grüße, Sven. -- Sigmentation fault. Core dumped.
Bug#993488: maybe reason for wontfix?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a "wontfix + close" but no rationale. Which leaves the original reporter with a large "?" I guess. I am guessing that the reason for the "wontfix" is "that's just how Unix works unfortunately" aka "that's a Unix design bug"? Is my guess correct? One other question - any idea on a way forward here? I would guess that behaviour (changing group membership won't change group membership of running processes) is rooted somewhere quite low in the stack, maybe in the kernel itself (or in posix :-#)? So if the original reporter would want to go ahead and look to that problem beeing fixed would he need to go talk to the kernel mailing list or do you have idea where he could go to? *t
