Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 446518 - sys-kernel/hardened-sources-3.6.8 pax doesn't handle if some of flags are set to '-'
Summary: sys-kernel/hardened-sources-3.6.8 pax doesn't handle if some of flags are set...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 431092
  Show dependency tree
 
Reported: 2012-12-08 20:27 UTC by Amadeusz Sławiński
Modified: 2012-12-17 17:42 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch with change proposed in bug report (fix_xt_pax.patch,367 bytes, patch)
2012-12-08 20:28 UTC, Amadeusz Sławiński
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Amadeusz Sławiński 2012-12-08 20:27:46 UTC
If flags are set for example to "--me-"
# getfattr -d /usr/games/bin/xonotic-glx
getfattr: Removing leading '/' from absolute path names
# file: usr/games/bin/xonotic-glx
user.pax.flags="--me-"

kernel seems to ignore these flags

It's caused by not handling '-' in them
in fs/binfmt_elf.c

static unsigned long pax_parse_xattr_pax(struct file * const file)
{
.....
	for (i = 0; i < xattr_size; i++)
		switch (xattr_value[i]) {
		default:
			return ~0UL;  <-- it quits here

After adding simple
		case '-':
			/* ignore not set flag */
			break;
everything works again.

Reproducible: Always
Comment 1 Amadeusz Sławiński 2012-12-08 20:28:45 UTC
Created attachment 331828 [details, diff]
Patch with change proposed in bug report
Comment 2 Anthony Basile gentoo-dev 2012-12-08 20:55:56 UTC
Okay this is a misunderstanding (probably on my part) on how the paxflags are set when they are "blank".

@pipacs,  suppose we have something like pax flags = "--me-", where the field order is something like PSMER, what exactly should user.pax.flags look like?
Comment 3 Anthony Basile gentoo-dev 2012-12-08 21:18:22 UTC
(In reply to comment #2)
> Okay this is a misunderstanding (probably on my part) on how the paxflags
> are set when they are "blank".
> 
> @pipacs,  suppose we have something like pax flags = "--me-", where the
> field order is something like PSMER, what exactly should user.pax.flags look
> like?

I read the code. I see how the implementation works.  There is a variable xattr_size.

@pipacs: Can we consider a "blank" char like '-' so that the xattr field is always 5 chars long and it can nicely be formated when printed out?  Adding adding a case '-': continue; seem innocent enough.
Comment 4 iGentoo 2012-12-08 21:54:35 UTC
Could paxctl-ng set real text value "me" ( user.pax.flags="me" ), and formatted display "--me-" ?
Comment 5 Anthony Basile gentoo-dev 2012-12-08 22:21:07 UTC
(In reply to comment #4)
> Could paxctl-ng set real text value "me" ( user.pax.flags="me" ), and
> formatted display "--me-" ?

paxctl-ng is easy to fix.  i'm thinking more of setfattr in conjunction with script.s
Comment 6 PaX Team 2012-12-09 11:00:32 UTC
the pax flags as stored have never been the same as the flags shown to a human user (or parser script) and i don't want to tie one to the other in the future either. for user.pax.flags this means that you are not supposed to set it to the output your parsed out from paxctl (the PT_PAX_FLAGS value has nothing to do with the paxctl output either, one's binary, the other's ascii text), you must set it to actually meaningful flags that you want enabled/disabled on the given binary (not unlike you already have to do with paxctl ;). a '-' does not mean anything (at least not now, i can't predict the future of course ;) so it will not be accepted by the kernel. this is by design and this bug is invalid, as far as the kernel side is concerned. for the '--me-' example, user.pax.flags should be set to 'me' or 'em, the ordering doesn't matter (much like it never mattered to paxctl either). so if there's a bug here, it's the inclusion of '-' in the user.pax.flags value.
Comment 7 Anthony Basile gentoo-dev 2012-12-10 01:14:16 UTC
(In reply to comment #6)
> the pax flags as stored have never been the same as the flags shown to a
> human user (or parser script) and i don't want to tie one to the other in
> the future either. for user.pax.flags this means that you are not supposed
> to set it to the output your parsed out from paxctl (the PT_PAX_FLAGS value
> has nothing to do with the paxctl output either, one's binary, the other's
> ascii text), you must set it to actually meaningful flags that you want
> enabled/disabled on the given binary (not unlike you already have to do with
> paxctl ;). a '-' does not mean anything (at least not now, i can't predict
> the future of course ;) so it will not be accepted by the kernel. this is by
> design and this bug is invalid, as far as the kernel side is concerned. for
> the '--me-' example, user.pax.flags should be set to 'me' or 'em, the
> ordering doesn't matter (much like it never mattered to paxctl either). so
> if there's a bug here, it's the inclusion of '-' in the user.pax.flags value.

Okay we'll code accordingly in our scripts.
Comment 8 Anthony Basile gentoo-dev 2012-12-17 00:51:33 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > the pax flags as stored have never been the same as the flags shown to a
> > human user (or parser script) and i don't want to tie one to the other in
> > the future either. for user.pax.flags this means that you are not supposed
> > to set it to the output your parsed out from paxctl (the PT_PAX_FLAGS value
> > has nothing to do with the paxctl output either, one's binary, the other's
> > ascii text), you must set it to actually meaningful flags that you want
> > enabled/disabled on the given binary (not unlike you already have to do with
> > paxctl ;). a '-' does not mean anything (at least not now, i can't predict
> > the future of course ;) so it will not be accepted by the kernel. this is by
> > design and this bug is invalid, as far as the kernel side is concerned. for
> > the '--me-' example, user.pax.flags should be set to 'me' or 'em, the
> > ordering doesn't matter (much like it never mattered to paxctl either). so
> > if there's a bug here, it's the inclusion of '-' in the user.pax.flags value.
> 
> Okay we'll code accordingly in our scripts.

I just committed =dev-python/pypax-0.7.0 and =sys-apps/elfix-0.7.0 to the tree.  They fix this bug and should work with the new eclass correctly.  Please test.
Comment 9 Amadeusz Sławiński 2012-12-17 17:00:02 UTC
Testing with valgrind

 * XT PaX marking -m
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/cachegrind-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/callgrind-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/drd-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/exp-bbv-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/exp-dhat-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/exp-sgcheck-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/helgrind-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/lackey-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/massif-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/memcheck-amd64-linux
 *      /var/tmp/portage/dev-util/valgrind-3.8.1/image//usr/lib64/valgrind/none-amd64-linux

# paxctl-ng -v /usr/lib64/valgrind/cachegrind-amd64-linux
/usr/lib64/valgrind/cachegrind-amd64-linux:
	XT_PAX: -em--

# getfattr -d /usr/lib64/valgrind/cachegrind-amd64-linux 
getfattr: Removing leading '/' from absolute path names
# file: usr/lib64/valgrind/cachegrind-amd64-linux
user.pax.flags="em"

# paxctl-ng -v /usr/lib64/valgrind/callgrind-amd64-linux 
/usr/lib64/valgrind/callgrind-amd64-linux:
	XT_PAX: -em--

# getfattr -d /usr/lib64/valgrind/callgrind-amd64-linux 
getfattr: Removing leading '/' from absolute path names
# file: usr/lib64/valgrind/callgrind-amd64-linux
user.pax.flags="em"

Looks like this problem with paxctl-ng is fixed.