Summary: | TPE Invert GID misbehavior | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christian Holler <decoder> |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Kernel Team (OBSOLETE) <hardened-kernel+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | bugzilla, dirk, gengor, hardened, kfm, spender |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Kernel config on the -r7 system
grsec-2.1.11-2.6.2X-tpe_all_invert-fix.patch |
Description
Christian Holler
2008-04-08 16:01:13 UTC
Please attach your kernel config as well. Thanks. Created attachment 149109 [details]
Kernel config on the -r7 system
I've just read again the description of the TPE settings, as well as the kernel source code that implements TPE and it seems to me that this behavior is indeed intended. If the INVERT option is on, then those in the exclude group are as well restricted according to the TPE_ALL option. The behavior with TPE_INVERT and TPE_ALL at once enabled is not straight forward though, the description of the invert option says "If you say Y here, the group you specify in the TPE configuration will decide what group TPE restrictions will be *disabled* for.". This is not true with the TPE_ALL option enabled as well. Maybe the behavior with TPE_ALL+TPE_INVERT should be reviewed, it is however not a coding bug, rather a design/description problem. Confirmed the behavior reported by the OP. Incoming patch changes behavior to that desired by OP. I believe the existing behavior probably is a bug and not what upstream grsec had in mind, but I'll let spender speak for himself. CCing him here now. Created attachment 149138 [details, diff]
grsec-2.1.11-2.6.2X-tpe_all_invert-fix.patch
grsec-2.1.11-2.6.2X-tpe_all_invert-fix.patch
(In reply to comment #3) > I've just read again the description of the TPE settings, as well as the kernel > source code that implements TPE and it seems to me that this behavior is indeed > intended. If the INVERT option is on, then those in the exclude group are as > well restricted according to the TPE_ALL option. > > The behavior with TPE_INVERT and TPE_ALL at once enabled is not straight > forward though, the description of the invert option says "If you say Y here, > the group you specify in the TPE configuration will decide what group TPE > restrictions will be *disabled* for.". This is not true with the TPE_ALL option > enabled as well. Maybe the behavior with TPE_ALL+TPE_INVERT should be reviewed, > it is however not a coding bug, rather a design/description problem. > I can see where you were coming from originally. Seems to me when using INVERT+GID to exclude users from TPE restrictions, it should exclude them from all TPE restrictions. But perhaps there is indeed good reason not to. (In reply to comment #6) > > I can see where you were coming from originally. Seems to me when using > INVERT+GID to exclude users from TPE restrictions, it should exclude them from > all TPE restrictions. But perhaps there is indeed good reason not to. > Yes, I agree, that needs to be carefully thought. The first point is: if the INVERT does not disable all TPE restrictions for a user in the group, then the description needs to state that (otherwise it is confusing). Secondly: If user A is in the group and INVERT is on, the restriction then would be, as far as I understood, that no other user should be able to modify the code that user A may run. This makes of course sense. However, if that other user is a trusted one as well (also in the group), then there is no security problem from my point of view. Thirdly: In my example, the second user still was able to modify the file the first user runs, so that restriction didn't even work as it should, it was only directory based for some reason. Since you have TPE_INVERT enabled, the normal TPE algorithm is applying to all nonroot users that aren't in the trusted group. TPE_ALL applies a separate, weaker, restriction against all nonroot users. If you want the trusted group to not be restricted, the correct thing to have done would be to not enable TPE_ALL. -Brad (In reply to comment #8) > Since you have TPE_INVERT enabled, the normal TPE algorithm is applying to all > nonroot users that aren't in the trusted group. TPE_ALL applies a separate, > weaker, restriction against all nonroot users. If you want the trusted group > to not be restricted, the correct thing to have done would be to not enable > TPE_ALL. > > -Brad > I just came to that conclusion as well, thank you very much for clarifying. Maybe the description in the kernel should be altered such that it reflects this more clearly. I agree, though the name of the TPE_ALL feature: "Partially restrict non-root users" is clear, its description doesn't clearly account for the presence of TPE_INVERT. -Brad *** Bug 319745 has been marked as a duplicate of this bug. *** Can you check that the additional groups were loaded for your test user? The recent changes in hardened-sources-2.6.32-r134 hardened-sources-3.2.31 hardened-sources-3.6.1 clarify this issue, so this bug is done. Please reopen if you still think there's an issue here. I though I had wrotten a cool nice doc for TPE for something... http://www.gentoo.org/proj/en/hardened/grsec-tpe.xml |