Summary: | sys-kernel/hardened-sources-2.6.32-r116 and sys-devel/distcc-3.1-r5: grsec: From X.X.X.X: denied following symlink /dev/shm/tmpjCv2Wf.include_server-28429-1/usr/include since symlink owner 250 does not match target owner 0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | [OLD] Core system | Assignee: | MATSUU Takuto (RETIRED) <matsuu> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | cluster, hardened, kernel, pageexec, spender |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Dennis Schridde
2012-10-01 14:30:11 UTC
This could also become a problem in Linux 3.6, if I understand the LWN article about temporary directories and symlinks [1] correctly. [1] http://lwn.net/Articles/503660/ (In reply to comment #1) > This could also become a problem in Linux 3.6, if I understand the LWN > article about temporary directories and symlinks [1] correctly. The article is a bit older. The described behaviour was meanwhile implemented for Linux 3.6: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 For the time being you could try disabling CONFIG_GRKERNSEC_LINK though I have to agree with you on this behaviour being bad. There is little more we can do on the hardened side to fix this except explaining how to fix the issue. @matsuu it would be cool if you can get distcc to create its own directory in the temporary system so race conditions can be avoided. Or you could read the documentation for the CONFIG_GRKERNSEC_SYMLINKOWN feature you enabled and notice what you configured its GID to be (250 it seems), and note that this feature is mainly to be used for Apache, not for emerge. -Brad (In reply to comment #4) > Or you could read the documentation for the CONFIG_GRKERNSEC_SYMLINKOWN > feature you enabled and notice what you configured its GID to be (250 it > seems), and note that this feature is mainly to be used for Apache, not for > emerge. I think I enabled it generally, for all users. And I think I used the autoconfiguration, instead of enabling this feature manually. (I could be mistaken, though. The config is a few years old -- carried over from version to version.) Also: Could someone please comment on comment #2? Is my understanding correct? (In reply to comment #2) > (In reply to comment #1) > > This could also become a problem in Linux 3.6, if I understand the LWN > > article about temporary directories and symlinks [1] correctly. > > The article is a bit older. The described behaviour was meanwhile > implemented for Linux 3.6: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git; > a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 Dennis that commit is fairly recent. Revert it in your system and see if it removes the problem. If it does, we have at least the culprit. Fixing it we'll think about later. (In reply to comment #6) > (In reply to comment #2) > > (In reply to comment #1) > > > This could also become a problem in Linux 3.6, if I understand the LWN > > > article about temporary directories and symlinks [1] correctly. > > > > The article is a bit older. The described behaviour was meanwhile > > implemented for Linux 3.6: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git; > > a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 > > Dennis that commit is fairly recent. Revert it in your system and see if it > removes the problem. If it does, we have at least the culprit. Fixing it > we'll think about later. I am not using 3.6 on that machine yet. I just wanted to point out, that the same issue might not be specific to sys-kernel/hardened-sources, but might affect >=sys-kernel/gentoo-sources-3.6, too. I guess I need to be incredibly specific and repetitive to resolve this. BTW I hate this Gentoo bugtracker, it's a huge waste of time if you're looking for my involvement in it. When a bug is assigned to some group that has me on CC, I get basically no information at that point (other than a subject) and have to visit the site to see if it's a real issue or not. CONFIG_GRKERNSEC_SYMLINKOWN, the feature I specifically mentioned, is not CONFIG_GRKERNSEC_LINK (the feature everyone seems to be confusing it with but which a simple grep in grmsg.h would have ruled out very quickly). SYMLINKOWN is a feature only a few months old. It has an associated GID setting, GRKERNSEC_LINK does not. SYMLINKOWN is intended for something very specific: as a race-free kernel implementation of Apache's SymlinksIfOwnerMatch option. With the new grsecurity autoconfiguration settings, you have to decide on a number of GIDs, including the SYMLINKOWN feature if the "server" option is selected. Blueness: you need to do a better job of educating your users on what exactly the hardened kernel is doing for them. There's a reason I write the documentation in the configuration help and that information needs to be relayed to a user whether they're configuring their own kernel or using something you give them. It's embarrassing to me for people to be using grsecurity and not understand what it is doing for them. That goes against everything I'm about -- security is not a checkbox to mark. -Brad Sorry, it seems I messed something up during kernel updates. In "Default Special Groups" I have: (601) GID for untrusted users (601) GID for users with kernel-enforced SymlinksIfOwnerMatch But in "Executable Protections" this gets translated to: (601) GID for trusted users Apparently, during updating the kernel config, I thought that it would be good to enforce SymlinksIfOwnerMatch for untrusted users. What I did not check, was that CONFIG_GRKERNSEC_TPE_INVERT is set, which alters the description of CONFIG_GRKERNSEC_TPE_GID from "GID for untrusted users" to "GID for trusted users". So instead of applying restrictions to untrusted users, I was suddenly imposing them on the trusted ones... @spender: Could you maybe change CONFIG_GRKERNSEC_TPE_GID in "Default Special Groups" to also switch its description based on CONFIG_GRKERNSEC_TPE_INVERT, as is done in "Executable Protections"? |