Bug 436796 – 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

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Dennis Schridde 2012-10-01 14:30:11 UTC]

I get several of these during emerge runs:
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, by /usr/bin/python2.7[python2.7:28429] uid/euid:250/250 gid/egid:250/250, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

Portage 2.2.0_alpha134 (hardened/linux/ia64/server, gcc-4.5.3, glibc-2.15-r2, 2.6.32-hardened-r116 ia64)                                                                                                                              [12/1945]
=================================================================
System uname: Linux-2.6.32-hardened-r116-ia64-31-with-gentoo-2.1
Timestamp of tree: Sat, 29 Sep 2012 15:15:01 +0000
distcc 3.1 ia64-unknown-linux-gnu [enabled]
app-shells/bash:          4.2_p37
dev-lang/python:          2.7.3-r2, 3.2.3-r1
dev-util/cmake:           2.8.8-r3
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.9.8.4
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.68
sys-devel/automake:       1.11.6
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.5.3-r2
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r3
sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers)
sys-libs/glibc:           2.15-r2
Repositories: gentoo local sunrise
ACCEPT_KEYWORDS="ia64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="ia64-unknown-linux-gnu"
CFLAGS="-pipe -mtune=mckinley -O2"
CHOST="ia64-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/san
dbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-pipe -mtune=mckinley -O2"
DISTDIR="/var/cache/portage/distfiles"
EMERGE_DEFAULT_OPTS="--usepkg --binpkg-respect-use --with-bdeps y --keep-going"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distcc distcc-pump distlocks ebuild-locks fixlafiles news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unm
erge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distfiles.gentoo.org"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu"
MAKEOPTS="-j6"
PKGDIR="/var/cache/portage/packages"
PORTAGE_COMPRESS="xz"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/cache/portage/gentoo"
PORTDIR_OVERLAY="/var/cache/portage/local /var/cache/portage/overlays/sunrise"
[...]
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

Reproducible: Always

[Comment 1 Dennis Schridde 2012-10-01 14:36:23 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/

[Comment 2 Dennis Schridde 2012-10-01 14:53:02 UTC]

(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

[Comment 3 Francisco Blas Izquierdo Riera (RETIRED) 2012-10-03 02:40:05 UTC]

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.

[Comment 4 Brad Spengler 2012-10-03 12:42:53 UTC]

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

[Comment 5 Dennis Schridde 2012-10-03 21:57:09 UTC]

(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?

[Comment 6 Anthony Basile 2012-10-04 09:59:59 UTC]

(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.

[Comment 7 Dennis Schridde 2012-10-04 10:45:58 UTC]

(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.

[Comment 8 Brad Spengler 2012-10-04 12:22:24 UTC]

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

[Comment 9 Dennis Schridde 2012-10-04 14:50:30 UTC]

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...

[Comment 10 Dennis Schridde 2012-10-04 21:31:34 UTC]

@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"?