-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings.
Currently I'm in need of some information about both vanilla and Exec
Shield kernels in regards to markings emitted by the toolchain,
specifically PT_GNU_STACK. I'd like to check my assumptions, in
preparation for possibly making a non-intrusive change which would allow
the PT_PAX_FLAGS from PaX to be used in a more finegrained way than
PT_GNU_STACK is used now to control mainline and exec shield memory
protections.
As I understand, PT_GNU_STACK uses a single marking to control whether a
task gets an executable stack and whether ASLR is applied to the
executable. I would like more information on this. To start, I'll
supply some background on why I need this information.
PaX uses its own markings, PT_PAX_FLAGS, to control the way PaX applies
protections to processes. In particular, PaX supplies the following
markings:
P - PAGEEXEC (NX bit or emulated NX bit)
S - SEGMEXEC (NX emulation on x86, ignored for our purposes)
E - EMUTRAMP (Trampoline emulation, to avoid giving an executable stack
in situations where nested functions are used)
M - MPROTECT (mprotect() restrictions, to control kernel policy on how
memory protections may be applied in userspace)
R - RANDMMAP (mmap() base randomization, for libraries, PIEs, anonymous
segments, etc; also controls all other randomization
except RANDEXEC)
X - RANDEXEC (random ET_EXEC base)
Each marking has three states: On, Off, and Neutral. The Neutral
marking takes the most restrictive setting by default, except in the
case of RANDEXEC, in which it's off because RANDEXEC can crash things
easily. A sysctl in PaX can switch the Neutral logic, except for RANDEXEC.
For our purposes, SEGMEXEC is completely ignored; aside from x86 PaX,
SEGMEXEC has no impact on anything. PAGEEXEC is equivalent to using the
processor supplied facilities to enforce PROT_EXEC (or emulation to do
such on x86).
I believe that these could map easily to PT_GNU_STACK's functionality:
P - Page-based PROT_EXEC enforcement. With this off, PROT_EXEC has no
effect. This is slightly different than normal PT_GNU_STACK
(executable stack).
R - Randomization. With this off, the ASLR for stack, heap, mmap(),
etc are disabled.
E - Trampoline Emulation, port this from PaX in the future
If PT_PAX_FLAGS exists (the logic to check and read it can be derived
from PaX), these markings should be used; else, PT_GNU_STACK should be
fallen back to. This would have no effect on any current distributions;
however, future development could mark for any situation and potentially
have one marking which simultaneously make the program work under PaX,
Exec Shield, and Vanilla.
The default state (when these are Neutral) would be the more
restrictive, of course; that is, PRe would be equal to ---.
Trampoline emulation would allow for a task to use nested functions with
a non-executable stack. This would allow some PT_GNU_STACK markings to
come off for i.e. x86-64 and for Exec Shield.
Currently my understanding of how PT_GNU_STACK affects mainline and exec
shield kernels is very limited. The above is what I came up under the
assumption that it simply allows the stack to be made executable and
allows ASLR to be turned off with one setting, rather than individual
fine-grained settings; I may need more information. If anyone has any
suggestions, comments, etc, I'd like to hear them.
To do this, I'd pretty much simply have to port over the part of PaX
which checks for PT_PAX_FLAGS and if it can't find it falls back to
EI_PAX, changing that to falling back to PT_GNU_STACK and appropriate
code; and tweak the code to reflect mainline rather than a PaX kernel.
Not sure how I'd do that exactly, but I have a whole week off work and
class somehow so maybe I'll learn something.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSEsThDd4aOud5P8RAnh8AJ9dv11ozerlf5MKGzeFIyvLpucjtACfV+vF
Ll8bAJBbTCReRBwToCGVX/c=
=1qEV
-----END PGP SIGNATURE-----
> As I understand, PT_GNU_STACK uses a single marking to control whether a
> task gets an executable stack and whether ASLR is applied to the
> executable.
you understand wrongly.
PT_GNU_STACK just sets the exec permission for the stack (and the heap
now mirrors the stack). Nothing more nothing less.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
>>As I understand, PT_GNU_STACK uses a single marking to control whether a
>>task gets an executable stack and whether ASLR is applied to the
>>executable.
>
>
> you understand wrongly.
>
> PT_GNU_STACK just sets the exec permission for the stack (and the heap
> now mirrors the stack). Nothing more nothing less.
>
So then this would be slightly more useful than I had previously
thought, bringing control over the randomization as well?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSFINhDd4aOud5P8RAv36AJ9kFyE4u14CAVvWNu4bl11Gd125agCfVj3I
gNPQRd73mWJCLrPd5Ge/EnM=
=jqg0
-----END PGP SIGNATURE-----
On Mon, 2005-03-28 at 13:50 -0500, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> >>As I understand, PT_GNU_STACK uses a single marking to control whether a
> >>task gets an executable stack and whether ASLR is applied to the
> >>executable.
> >
> >
> > you understand wrongly.
> >
> > PT_GNU_STACK just sets the exec permission for the stack (and the heap
> > now mirrors the stack). Nothing more nothing less.
> >
>
> So then this would be slightly more useful than I had previously
> thought, bringing control over the randomization as well?
actually Linus was really against adding non-related things to this
flag. And I think he is right...
Now.. do you have any examples of when you want a binary marked for no-
randomisation ?? (eg something the setarch flag won't fix/won't be good
enough for)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Mon, 2005-03-28 at 13:50 -0500, John Richard Moser wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>
>>Arjan van de Ven wrote:
>>
>>>>As I understand, PT_GNU_STACK uses a single marking to control whether a
>>>>task gets an executable stack and whether ASLR is applied to the
>>>>executable.
>>>
>>>
>>>you understand wrongly.
>>>
>>>PT_GNU_STACK just sets the exec permission for the stack (and the heap
>>>now mirrors the stack). Nothing more nothing less.
>>>
>>
>>So then this would be slightly more useful than I had previously
>>thought, bringing control over the randomization as well?
>
>
> actually Linus was really against adding non-related things to this
> flag. And I think he is right...
>
I'm not interested in altering and hacking up PT_GNU_STACK; PT_PAX_FLAGS
already supplies enough to do what I want. My goal is to have
PT_PAX_FLAGS code in mainline and Exec Shield, so that if it exists in
the binary it will be used; else PT_GNU_STACK will be fallen back to.
> Now.. do you have any examples of when you want a binary marked for no-
> randomisation ?? (eg something the setarch flag won't fix/won't be good
> enough for)
What's setarch do for one? Anyway, ASLR has been known to break some
things. Blackdown Java used to break IIRC; also there's the poorly
designed Oracle and the poorly designed solution of Oracle on a 32 bit
platform; and of course there's Emacs, which I heard was broken due to
Exec Shield's randomization. Temporary work-arounds are sometimes needed.
Remember also that I'm not just trying to make a more robust setting for
ES and mainline; I'm trying to find a way to make it so that
distribution maintainers can set one set of flags and have it assure
that the program works in Mainline, Exec Shield, and PaX. Just a little
less work for the distribution maintainers, which I think would be a
good thing considering that apparently Ubuntu Linux might support both
PaX and Exec Shield in the future, if I'm reading this[1] right.
[1] http://thread.gmane.org/gmane.linux.ubuntu.devel/6130
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSFeuhDd4aOud5P8RApQ+AKCPtp5b4/2rw+aRqEUg7r1FlphmQwCfX3Io
FUNq9xZlDsoo1poGBo5+zus=
=v0dv
-----END PGP SIGNATURE-----
> > actually Linus was really against adding non-related things to this
> > flag. And I think he is right...
> >
Makes sense to me.
> I'm not interested in altering and hacking up PT_GNU_STACK; PT_PAX_FLAGS
> already supplies enough to do what I want. My goal is to have
> PT_PAX_FLAGS code in mainline and Exec Shield, so that if it exists in
> the binary it will be used; else PT_GNU_STACK will be fallen back to.
>
> > Now.. do you have any examples of when you want a binary marked for no-
> > randomisation ?? (eg something the setarch flag won't fix/won't be good
> > enough for)
I also recall a few oddball cases where PaX randomization broke things,
I'll try and dig one up and see if it fails as well on ExecShield.
> What's setarch do for one? Anyway, ASLR has been known to break some
> things. Blackdown Java used to break IIRC; also there's the poorly
> designed Oracle and the poorly designed solution of Oracle on a 32 bit
> platform; and of course there's Emacs, which I heard was broken due to
> Exec Shield's randomization. Temporary work-arounds are sometimes needed.
> Remember also that I'm not just trying to make a more robust setting for
> ES and mainline; I'm trying to find a way to make it so that
> distribution maintainers can set one set of flags and have it assure
> that the program works in Mainline, Exec Shield, and PaX. Just a little
> less work for the distribution maintainers, which I think would be a
> good thing considering that apparently Ubuntu Linux might support both
> PaX and Exec Shield in the future, if I'm reading this[1] right.
>
> [1] http://thread.gmane.org/gmane.linux.ubuntu.devel/6130
IMO you have this backwards, John. Rather than having the majority (ES,
mainline NX stuff) respect your less popular branch, it would make sense
to have PaX work as well as possible with PT_GNU_STACK, and politely
request that any missing functionality be duplicated in ES. PT_GNU_STACK
is the most widely available header, and we should leverage that
ubiquity as much as possible. Marking our binaries with PT_PAX_FLAGS
and then begging everyone else to support our way of doing things will
never work.
---
Brandon Hale
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brandon Hale wrote:
>>>actually Linus was really against adding non-related things to this
>>>flag. And I think he is right...
>>>
>
>
> Makes sense to me.
>
>
[...]
>
> IMO you have this backwards, John. Rather than having the majority (ES,
> mainline NX stuff) respect your less popular branch, it would make sense
> to have PaX work as well as possible with PT_GNU_STACK, and politely
> request that any missing functionality be duplicated in ES. PT_GNU_STACK
> is the most widely available header, and we should leverage that
> ubiquity as much as possible. Marking our binaries with PT_PAX_FLAGS
> and then begging everyone else to support our way of doing things will
> never work.
>
You need to consider that in the end I'd need PT_GNU_STACK to do
everything PaX wants, and to make PF_X a tristate (On, Off, Neutral)
which mapped to PF_PAGEEXEC in PaX. In other words, I'd have to
overhaul and most likely *break* everything else that relied on
PT_GNU_STACK, instead of passively adding logic for PT_PAX_FLAGS and
letting everyone else catch up at their leisure.
I'd rather not break anything and force everyone to upgrade *now*; but
instead add PT_PAX_FLAGS functionality for mainline/ES, let it lay there
for a year or so as people start moving over and accepting it, let the
kernel devs decide when it's time to depricate PT_GNU_STACK, and see it
naturally decay away once it's actually no longer needed. The point is
to not break anything, yet to still make things easier for those
projects and distributions like Hardened Ubuntu.
> ---
> Brandon Hale
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSIKKhDd4aOud5P8RAkqEAJwNhFvfDc63qyPrBvMxs6naG1xuAQCfZKHn
upzqNI5/XzYVCmDKGM6q8ZY=
=YZkT
-----END PGP SIGNATURE-----
>
> You need to consider that in the end I'd need PT_GNU_STACK to do
> everything PaX wants
why?
Why not have independent flags for independent things?
That way you have both cleanness of design and you don't break anything.
> The point is
> to not break anything, yet to still make things easier for those
> projects and distributions like Hardened Ubuntu.
to achieve that you need to get the toolchain to omit this stuff
automatically somehow.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
>>You need to consider that in the end I'd need PT_GNU_STACK to do
>>everything PaX wants
>
>
> why?
> Why not have independent flags for independent things?
> That way you have both cleanness of design and you don't break anything.
>
In the end I want to fine-tune for what the best behaviors are, and then
define exactly what the flags should do.
Right now, my rough sketch is:
MF_PAX_PAGEEXEC
ON: ET_EXEC enforced. Stack NX. Heap NX. Code PROT_EXEC.
OFF: Stack and heap default to +X
The PAGEEXEC flag will basically mandate the automated non-executable
setting for the stack and heap. When off, these areas are executable
(like when PT_GNU_STACK is on)
MF_PAX_EMUTRAMP:
ON: Trampolines (in NX stack) and PLT will be detected and emulated
OFF: Stack needs to be +X for trampolines to work
The EMUTRAMP flag will basically allow certain known exceptional
conditions to be trapped and allowed somehow automatically. This
includes mainly nested functions on a non-executable stack, and parisc
procedural linkage tables (binutils patch can fix these apparently).
This is off by default in hardmode, but on by default in soft or
compatibility mode if PAGEEXEC is manually on.
MF_PAX_RANDMMAP:
ON: stack, heap, mmap() base randomized
OFF: Nothing is randomized in memory
RANDMMAP should probably be called "RANDADDR" instead. When set, the
kernel randomizes anything that can be randomized in the address
space (support determining).
MF_PAX_RANDEXEC:
ON: Fixed-position things are also randomized
OFF: Fixed-position things are at fixed positions
RANDEXEC allows things that normally can't be placed randomly to be
placed randomly if hacks exist to do it. Any hacks 100% safe that
don't cause excess overhead are for RANDMMAP; any that may cause
instability or excessive overhead go under RANDEXEC. OFF BY DEFAULT
in any mode.
MF_PAX_MPROTECT:
ON: Enforce certain mprotect() restrictions
OFF: Normal mprotect() restrictions
A certain defined set of transitions and creation states are banned
when this is on. PaX has these now, nobody else has them and
apparently nobody else wants them.
MF_PAX_SEGMEXEC:
Absolutely no effect, reserved for PaX or anything else that
implements PaX' specific SEGMEXEC emulation method.
Obviously mainline and ES won't do anything with RANDEXEC, MPROTECT, or
SEGMEXEC.
RANDMMAP will be useful to control ES and mainline ASLR (on-off switch).
PAGEEXEC being OFF will act exactly like PT_GNU_STACK being ON for
mainline and ES.
EMUTRAMP. . . I think I've got a patch for trampoline emulation, which
should let red hat use Exec Shield with fewer PT_GNU_STACK markings.
Mainline should benefit from this too. It feels like porting this was
way too easy, so I'll ask pipacs to give it a quick look.
I also don't have a soft/hard mode for mainline. I expect that mainline
will be more into making softmode (compatibility mode) into a
personality, which makes sense for softmode shells (which I've needed
before, i.e. to compile mono without softmoding my whole system).
Soft/Hard mode controls what flags are set by default. Each flag has
ON/OFF/NEUTRAL settings (thus each is 2 bits).
HARDMODE:
MF_PAX_PAGEEXEC, MF_PAX_RANDMMAP, MF_PAX_MPROTECT
SOFTMODE:
(MF_PAX_EMUTRAMP if MF_PAX_PAGEEXEC is ON)
>
>>The point is
>>to not break anything, yet to still make things easier for those
>>projects and distributions like Hardened Ubuntu.
>
>
> to achieve that you need to get the toolchain to omit this stuff
> automatically somehow.
>
Emit.
And there's a patch for binutils that Gentoo uses. Ubuntu can use it too.
Remember that the way I'm doing it, PT_GNU_STACK is used if there is no
PT_PAX_FLAGS header. Distributions not using PT_PAX_FLAGS will not care
about the kernel's ability to read PT_PAX_FLAGS, because it will still
behave the same with PT_GNU_STACK. In other words, if Red Hat updated
the kernel with this stuff today (assuming it's non-buggy), it won't do
shit, and Fedora will still work exactly as expected.
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSQlqhDd4aOud5P8RAgCIAJ4hGeiHD/wcB+B6u9up4v37CT0bAwCeKgcA
zX00s0dqVkkRhnxmmzQLZq0=
=4EMG
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
>>You need to consider that in the end I'd need PT_GNU_STACK to do
>>everything PaX wants
>
>
> why?
> Why not have independent flags for independent things?
> That way you have both cleanness of design and you don't break anything.
>
Also, I should have pointed out that independent flags for each part of
this would require at the very least a 1 byte field per flag, totaling
6. In practice, the fields are usually 1 processor word (4 or 8 bytes),
totalling 24 (or 48) bytes rather than 4 (or 8).
As these are all pretty much "control memory space related security
protections," convergence to a well-defined standard would be both clean
and non-stuff-breaking. Now of course there's no standard, but several
things operating very similarly. This gives us the opportunity to look
at how each reacts to each different proprietary marking, take the most
robust (which just happens to be PT_PAX_FLAGS, no flamewars please), and
define exactly what each setting controls.
I want something very well defined for PAGEEXEC (executable stack,
heap). The MPROTECT setting should also be very well defined, which
will match with PaX because nobody else restricts mprotect(). EMUTRAMP
should be defined fairly loosely, but enough to say "stuff we can
predictably identify as exceptions to the rules are caught here." All
of these alter the programming environment, so must be predictable to
the programmer; emutramp is a special case, which allows the programmer
to assume that he needs PAGEEXEC off while the administrator knows to
just EMUTRAMP in this case.
For the two randomizers, "sane for default" should define one and "not
sane for default" should define the other. These have little to no
effect on most programs, VM space fragmentation aside. We don't need to
define these too well, but enough to know what they're for.
SEGMEXEC is of course "nothing." In truth, I want PaX to change to make
SEGMEXEC absolutely nothing unless PAGEEXEC is on, and only for x86.
This is because PAGEEXEC can be very clearly defined, and SEGMEXEC can
be defined as a specific modifier on PAGEEXEC.
Of course, the effect of any one of these being on is subject to
implementation; obviously if mprotect() restrictions aren't supported,
MPROTECT being on does nothing. I doubt mainline and ES will take that
particular logic specifically, though either way I have no intention of
even trying to force them to. EMUTRAMP, however, I hope would be able
to enhance mainline and ES both (that means Red Hat/Fedora) by allowing
some of the PT_GNU_STACK markings to come off.
In the future, an SeLinux hook should go into the pax_parse_elf_flags()
logic to allow SeLinux policy to control these settings for PaX,
mainline, and ES in one sweep:
+ /*Are these broke? Then get out*/
+ if (0 > pax_check_flags(&pax_flags))
+ return -EINVAL;
+
(insert hook here)
+ /*Add to the memory manager flags*/
+ current->mm->flags |= pax_flags;
[...]
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSQ6chDd4aOud5P8RAvr3AJ91i8c7W1CetmjWFGuItG6pCHEiigCbBfXb
H4RCVuOjFI71R45Q+TUw/AY=
=dLsN
-----END PGP SIGNATURE-----
On Tue, 2005-03-29 at 02:53 -0500, John Richard Moser wrote:
> Right now, my rough sketch is:
>
> MF_PAX_PAGEEXEC
> ON: ET_EXEC enforced. Stack NX. Heap NX. Code PROT_EXEC.
> OFF: Stack and heap default to +X
> The PAGEEXEC flag will basically mandate the automated non-executable
> setting for the stack and heap. When off, these areas are executable
> (like when PT_GNU_STACK is on)
how is this one different from PT_GNU_STACK
> MF_PAX_EMUTRAMP:
> ON: Trampolines (in NX stack) and PLT will be detected and emulated
> OFF: Stack needs to be +X for trampolines to work
> The EMUTRAMP flag will basically allow certain known exceptional
> conditions to be trapped and allowed somehow automatically. This
> includes mainly nested functions on a non-executable stack, and parisc
> procedural linkage tables (binutils patch can fix these apparently).
> This is off by default in hardmode, but on by default in soft or
> compatibility mode if PAGEEXEC is manually on
do you actually need this? the number of apps that have actual
trampolines is *really really* low. At that point you get to a balance
between complexity and very limited added security. And the answer is
really not straight forward since complexity is a security risk in
itself; or more direct, by allowing this at all you in theory can open
other security holes. (note the "can" here. I'm not saying the
implementation does, but there sure is added complexity which in turn
means added chances for bugs. If the number of things that need this is
really low (and it should be) the balance isn't so clear).
> .
> MF_PAX_RANDMMAP:
> ON: stack, heap, mmap() base randomized
> OFF: Nothing is randomized in memory
> RANDMMAP should probably be called "RANDADDR" instead. When set, the
> kernel randomizes anything that can be randomized in the address
> space (support determining).
This one could in theory be useful. However need info on what breaks. I
know that if you do full blown ES/PaX level randomisation the build
process of some older emacsen, and build process won't benefit from such
a flag unless you can make the toolchain insert it automatic (I suspect
that will be hard); once it's manual and during build only using setarch
is sufficient to cover that one.
> MF_PAX_RANDEXEC:
> ON: Fixed-position things are also randomized
> OFF: Fixed-position things are at fixed positions
> RANDEXEC allows things that normally can't be placed randomly to be
> placed randomly if hacks exist to do it. Any hacks 100% safe that
> don't cause excess overhead are for RANDMMAP; any that may cause
> instability or excessive overhead go under RANDEXEC. OFF BY DEFAULT
> in any mode.
Is this what PIE would be for? Eg if you change binaries why not just
change them to be PIE ?
> MF_PAX_MPROTECT:
> ON: Enforce certain mprotect() restrictions
> OFF: Normal mprotect() restrictions
> A certain defined set of transitions and creation states are banned
> when this is on. PaX has these now, nobody else has them and
> apparently nobody else wants them.
> MF_PAX_SEGMEXEC:
> Absolutely no effect, reserved for PaX or anything else that
> implements PaX' specific SEGMEXEC emulation method.
Actually SELinux currently has stuff for this. Does this need to be in
the binary or would SELinux policy be enough (I assume that any hardened
linux distro nowadays also enables selinux so this question is quite
relevant).
> EMUTRAMP. . . I think I've got a patch for trampoline emulation, which
> should let red hat use Exec Shield with fewer PT_GNU_STACK markings.
actually fc4 and such don't have that many markings so I wonder what the
usefulness is. (most of the spurious markings we had in the past were
due to assembly files not being correctly marked, not due to recursive
functions)
> > to achieve that you need to get the toolchain to omit this stuff
> > automatically somehow.
> >
>
> Emit.
eh yeah need coffee ;)
>
> And there's a patch for binutils that Gentoo uses. Ubuntu can use it too.
>
> Remember that the way I'm doing it, PT_GNU_STACK is used if there is no
> PT_PAX_FLAGS header.
since you duplicate PT_GNU_STACK exactly it seems (well inverse meaning
but a ! in C is cheap) I think there's no point in obsoleting
PT_GNU_STACK. I realize some people see PT_GNU_STACK as an Exec-Shield
thing and thus evil, but lets ignore all that politics and stick to
facts here: No need to obsolete/remove existing things if they're not
broken and are good enough.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Richard Moser wrote:
>
>
> Arjan van de Ven wrote:
>
[...]
Three more notes, then I'll sleep. These notes won't include the two
paragraph long explaination of falling back to PT_GNU_STACK if
PT_PAX_FLAGS isn't there; compatibility has been touched what, 5 times?
1. I don't want to continue using PT_GNU_STACK for three reasons. The
first being that PaX uses a tristate in PT_PAX_FLAGS; the second being
that PT_GNU_STACK is a whole ELF field and I'm inclined to take the more
space-efficient method; and the third being that PT_GNU_STACK is not a
tristate.
The last is particularly an important consideration to me: a tristate
would allow for a compatibility/soft mode, but changing PT_GNU_STACK's
logic would change the current expected behavior and thus could be
unpredictable (break things). I have no interest in breaking Fedora
horribly, nor wasting space with a full field where sharing with the
other parts of PT_PAX_FLAGS would do just fine.
2. Although binutils can emit PT_GNU_STACK, the paxctl utility could
also be modified to detect PT_GNU_STACK in a binary without PT_PAX_FLAGS
and change it to PT_PAX_FLAGS, then nuke it. This would allow the flags
to be changed without relinking (remember PT_GNU_STACK is to be ignored
if PT_PAX_FLAGS exists at all). This is only of interest to
distributions which will use PT_PAX_FLAGS.
Note also that execstack would probably be wisely modified to set
PF_PAGEEXEC and PT_GNU_STACK both, just for future compatibility. This
is of course a lot of work (I tried to make paxctl hack EI_PAX too, and
. . .well, it didn't work).
3. PaX won't pay any attention to markings on libraries. Exec Shield
and Mainline may, though I have no idea how. If it can be done with
PT_GNU_STACK, it can be done with PT_PAX_FLAGS. Such behavior is
acceptable, though libraries should be coded with the utmost care to
avoid this simply because the weakening of security around a library
weakens any and all programs using that library.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSRWghDd4aOud5P8RAhRFAJ9Ezr6mMIEvk9R+4XpXq7+lZxgd0gCfYhBa
IuUU7Zeuk1J9kSJXCSqZlKU=
=m0YW
-----END PGP SIGNATURE-----