Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote:
> 
>>-BEGIN PGP SIGNED MESSAGE-

[...]

>>/me shrugs.  It's a security blanket for him mostly; he fears automagic
>>security maintainence.
> 
> 
> who is "him" ?
> 

me in third person?  :)

> 
Remember also I'm very much against "let the compiler guess if you need
an executable stack"
>>>
>>>
>>>it's not guessing. the *compiler* emits the stack trampoline. So the
>>>*compiler* knows that it needs that stack.
>>>
>>
>>With a trampoline, things like Grub and a few libs need PT_GNU_STACK.
> 
> 
> sure they do. There's about a handful in an entire distro.

Right, so it's a toss-up:  Do you want to fix these few things, or do
you want to let trampolines exist?  Are trampolines that useful?

> 
> 
>>Of course you can't just suddenly say "OH!  Well PT_GNU_STACK should do
>>this instead!" because you'll break everything.
> 
> 
> I'm not a fan of any kind of emutrampoline. At all. But I am open to
> others making a different tradeoff; for me the option to have a
> trampoline at all is just a bypass of the non-exec stack... legit bypass
> one hopes but a bypass regardless. Some time ago we did an eval of how
> much stuff would need the emutramp (well or something equivalent) and
> the list was so small that I decided that the added risk and complexity
> were not worth it and that I rather had those 5 or so apps run with exec
> stack.
> 

Eh.

> 
>>>again what does tristate mean.. "I don't know" ? But gcc does know, with
>>>very very very few exceptions. Eg old mono is the exception because it
>>>didn't do a proper mprotect. Saying "I don't know" doesn't solve you
>>>anything, since in the end there needs to be a policy enforced anyway,
>>>it's just postponing the inevitable to a point with less knowledge.
>>>
>>
>>Remember I'm also thinking of restricted mprotect() situations as well,
>>because I'm trying to get it to the point where one set of markings has
>>a predictable effect on any kernel, be it vanilla, pax, or ES.
> 
> 
> well that is an entirely independent thing again. Really.
> I think mixing all these into one big flag is a mistake. 
> (And thats a lesson I learned the hard way, but Linus was right; don't
> mix independent things into one flag artificially. Extra flags are
> cheap. Don't complicate the world for a dozen bytes.)
> 
> 

two or four dozen bytes, eight dozen bytes in 10 years when 128 bit
systems come along, and 16i dozen planck qubytes when we get quantum
computers :)

Actually when I proposed adding PT_PAX_FLAGS to Ubuntu, the very first
argument I got was "Oh, yeah right, add just a few bytes here for this.
 Then later it'll be a few more bytes for something else.  Then a few
more for another thing.  It all adds up, especially when you have
thousands of binaries."

And if bitfield logic is "complicated," you should stop pretending to be
a programmer.


#define BIG   (1)
#define LONG  (1 << 1)
#define FAT   (1 << 2)
#define TALL  (1 << 3)
#define GREEN (1 << 4)

struct foo {
  char *myname;
  unsigned long flags;
};

struct foo *newfoo() {
  struct foo *out = malloc(sizeof(struct foo));
  out->myname = malloc(4);
  strcpy(out->myname, "bob");
  out->flags = BIG | TALL | GREEN;
  return out;
}


Easy enough?


struct foo {
  char myname[10];
  int big;
  int long;
  int fat;
  int tall;
  int green;
};

struct foo *newfoo() {
  struct foo *out = malloc(sizeof(struct foo));
  strcpy(out->myname, "bob");
  out->big = 1;
  out->tall = 1;
  out->green = 1;
  return out;
}


I don't find the above to be quite as elegant.  In fact, it looks ugly
and wasteful; even checking ...

if (myfoo->flags & BIG)

versus

if (myfoo->big)

> 
> 
> 

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

iD8DBQFCSb1rhDd4aOud5P8RAg2cAJ98SlxFCLcHvN+aWcVTM2VWxiRCEACfUPPl
24wpdtY/VyKHGs/YpPDo8Hk=
=mVc5
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> 
> Arjan van de Ven wrote:
> >>>H you either need an executable stack or you don't. Can you explain
> >>>why you think there is a strong advantage for a "neutral" setting on
> >>>this one?
> >>>
> >>
> >>As I said, compatibility mode.  The toolchain should not emit
> >>*everything* PT_GNU_STACK and leave it up to you to de-mark it; instead,
> >>everything should be emitted without PT_GNU_STACK set, in which case
> >>violating code would die.
> > 
> > 
> > actually right now the toolchain marks things automatically correct.
> > If gcc emits a stack trampoline, it gets marked needing executable
> > stack, if gcc can prove it doesn't need executable stack, it gets marked
> > as such as well. 
> > 
> 
> And the toolchain emits a -E library with PT_PAX_FLAGS if there's a
> stack trampoline :)  But it's defficient right now, doesn't inherit when
> you link to a library with -E. . . you can fix that right?  :)

it's inherited for PT_GNU_STACK though.
Not sure how you implemented PT_PAX_FLAGS, but for PT_GNU_STACK it's
inherited.

> > I *really* don't understand why you want to get away from automatic
> > marking to something manual, which *has* to be more fragile.
> > 
> 
> /me shrugs.  It's a security blanket for him mostly; he fears automagic
> security maintainence.

who is "him" ?

> 
> > 
> >>Remember also I'm very much against "let the compiler guess if you need
> >>an executable stack"
> > 
> > 
> > it's not guessing. the *compiler* emits the stack trampoline. So the
> > *compiler* knows that it needs that stack.
> > 
> 
> With a trampoline, things like Grub and a few libs need PT_GNU_STACK.

sure they do. There's about a handful in an entire distro.

> 
> Of course you can't just suddenly say "OH!  Well PT_GNU_STACK should do
> this instead!" because you'll break everything.

I'm not a fan of any kind of emutrampoline. At all. But I am open to
others making a different tradeoff; for me the option to have a
trampoline at all is just a bypass of the non-exec stack... legit bypass
one hopes but a bypass regardless. Some time ago we did an eval of how
much stuff would need the emutramp (well or something equivalent) and
the list was so small that I decided that the added risk and complexity
were not worth it and that I rather had those 5 or so apps run with exec
stack.

> > again what does tristate mean.. "I don't know" ? But gcc does know, with
> > very very very few exceptions. Eg old mono is the exception because it
> > didn't do a proper mprotect. Saying "I don't know" doesn't solve you
> > anything, since in the end there needs to be a policy enforced anyway,
> > it's just postponing the inevitable to a point with less knowledge.
> > 
> 
> Remember I'm also thinking of restricted mprotect() situations as well,
> because I'm trying to get it to the point where one set of markings has
> a predictable effect on any kernel, be it vanilla, pax, or ES.

well that is an entirely independent thing again. Really.
I think mixing all these into one big flag is a mistake. 
(And thats a lesson I learned the hard way, but Linus was right; don't
mix independent things into one flag artificially. Extra flags are
cheap. Don't complicate the world for a dozen bytes.)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

On Tue, 2005-03-29 at 03:29 -0500, John Richard Moser wrote:

> >>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
> > 
> 
> PT_GNU_STACK is on/off, PT_PAX_FLAGS settings are all on/off/neutral.
> The neutral state becomes on or off depending on whether some kind of
> compatibility mode is used.

H you either need an executable stack or you don't. Can you explain
why you think there is a strong advantage for a "neutral" setting on
this one?

>  
> >>MF_PAX_EMUTRAMP:

> > 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).
> > 
> 
> - -rw-r--r--   1 root  src  10485 Mar 29 00:47 emu_tramp.diff
> 
> I was surprised it wasn't that complex,

10k lines of patch. And you introduce a mechanism to bypass non-exec-
stack sometimes a 10 line patch can be "complex" in that sense.
So I'll repeat my question about the gains of this, you only answered by
showing something about the complexity.


> >>.
> >>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.
> 
> There's a patch that makes the toolchain spit out PT_PAX_FLAGS.

that's not an answer to what I said though. You propose a new
implementation for something, for that you should say why this one is
useful, not "because something else does it".

> Consider that PT_PAX_FLAGS are all tristates.

I think that's a bad idea though.


>   A compatibility mode
> personality (think linux32 for 64 bit systems) could allow for a shell
> to be spawned (`nopax make` or something dumb like that) which puts
> everything into softmode. 

setarch flags are inherited too (not by setuid of course); and that
mechanism already exists. What does your proposed solution add value
wise to that?

>  Anything not marked (binutils with the patch
> emits x- PT_PAX_FLAGS, hard-disabling RANDEXEC because it's a bad
> hack) will of course run as if it had psemrx (emutramp is useless anyway
> with an executable heap/stack) in softmode and PSeMrX (emutramp isn't
> used by default, near nothing needs it so why risk a "potential security
> risk" if it even is) in hardmode.

we're talking here about randomisation; I don't see where emutrap comes
in at all


> > 
> >>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 ?
> > 
> 
> Not everything (mplayer!  And last year KDE really hated it too)
> compiles PIE. 

Hmmm we'd need details in a bug report to investigate, I can't think of
a fundamental reason for this...

(other than mplayer doing the wine thing, which indeed means it needs to
be very careful to not trump over certain VA regions; but that is a
separate problem)

The rest of your comment suggests that you consider this one not too
valueable. PIE imo is a pretty nice solution to the problem, and does
not have the performance costs that you get with forcing non-PIE
binaries to be randomized.


> > 
> >>MF_PAX_MPROTECT:
> > 
> > Actually SELinux currently has stuff for this. Does this need to be in
> > the binary or would SELinux policy be enough 

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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(_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-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

On Tue, 2005-03-29 at 03:29 -0500, John Richard Moser wrote:

 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
  
 
 PT_GNU_STACK is on/off, PT_PAX_FLAGS settings are all on/off/neutral.
 The neutral state becomes on or off depending on whether some kind of
 compatibility mode is used.

H you either need an executable stack or you don't. Can you explain
why you think there is a strong advantage for a neutral setting on
this one?

  
 MF_PAX_EMUTRAMP:

  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).
  
 
 - -rw-r--r--   1 root  src  10485 Mar 29 00:47 emu_tramp.diff
 
 I was surprised it wasn't that complex,

10k lines of patch. And you introduce a mechanism to bypass non-exec-
stack sometimes a 10 line patch can be complex in that sense.
So I'll repeat my question about the gains of this, you only answered by
showing something about the complexity.


 .
 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.
 
 There's a patch that makes the toolchain spit out PT_PAX_FLAGS.

that's not an answer to what I said though. You propose a new
implementation for something, for that you should say why this one is
useful, not because something else does it.

 Consider that PT_PAX_FLAGS are all tristates.

I think that's a bad idea though.


   A compatibility mode
 personality (think linux32 for 64 bit systems) could allow for a shell
 to be spawned (`nopax make` or something dumb like that) which puts
 everything into softmode. 

setarch flags are inherited too (not by setuid of course); and that
mechanism already exists. What does your proposed solution add value
wise to that?

  Anything not marked (binutils with the patch
 emits x- PT_PAX_FLAGS, hard-disabling RANDEXEC because it's a bad
 hack) will of course run as if it had psemrx (emutramp is useless anyway
 with an executable heap/stack) in softmode and PSeMrX (emutramp isn't
 used by default, near nothing needs it so why risk a potential security
 risk if it even is) in hardmode.

we're talking here about randomisation; I don't see where emutrap comes
in at all


  
 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 ?
  
 
 Not everything (mplayer!  And last year KDE really hated it too)
 compiles PIE. 

Hmmm we'd need details in a bug report to investigate, I can't think of
a fundamental reason for this...

(other than mplayer doing the wine thing, which indeed means it needs to
be very careful to not trump over certain VA regions; but that is a
separate problem)

The rest of your comment suggests that you consider this one not too
valueable. PIE imo is a pretty nice solution to the problem, and does
not have the performance costs that you get with forcing non-PIE
binaries to be randomized.


  
 MF_PAX_MPROTECT:
  
  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).
  
 
 See my other reply, an LSM hook would be nice for 

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 
 Arjan van de Ven wrote:
 H you either need an executable stack or you don't. Can you explain
 why you think there is a strong advantage for a neutral setting on
 this one?
 
 
 As I said, compatibility mode.  The toolchain should not emit
 *everything* PT_GNU_STACK and leave it up to you to de-mark it; instead,
 everything should be emitted without PT_GNU_STACK set, in which case
 violating code would die.
  
  
  actually right now the toolchain marks things automatically correct.
  If gcc emits a stack trampoline, it gets marked needing executable
  stack, if gcc can prove it doesn't need executable stack, it gets marked
  as such as well. 
  
 
 And the toolchain emits a -E library with PT_PAX_FLAGS if there's a
 stack trampoline :)  But it's defficient right now, doesn't inherit when
 you link to a library with -E. . . you can fix that right?  :)

it's inherited for PT_GNU_STACK though.
Not sure how you implemented PT_PAX_FLAGS, but for PT_GNU_STACK it's
inherited.

  I *really* don't understand why you want to get away from automatic
  marking to something manual, which *has* to be more fragile.
  
 
 /me shrugs.  It's a security blanket for him mostly; he fears automagic
 security maintainence.

who is him ?

 
  
 Remember also I'm very much against let the compiler guess if you need
 an executable stack
  
  
  it's not guessing. the *compiler* emits the stack trampoline. So the
  *compiler* knows that it needs that stack.
  
 
 With a trampoline, things like Grub and a few libs need PT_GNU_STACK.

sure they do. There's about a handful in an entire distro.

 
 Of course you can't just suddenly say OH!  Well PT_GNU_STACK should do
 this instead! because you'll break everything.

I'm not a fan of any kind of emutrampoline. At all. But I am open to
others making a different tradeoff; for me the option to have a
trampoline at all is just a bypass of the non-exec stack... legit bypass
one hopes but a bypass regardless. Some time ago we did an eval of how
much stuff would need the emutramp (well or something equivalent) and
the list was so small that I decided that the added risk and complexity
were not worth it and that I rather had those 5 or so apps run with exec
stack.

  again what does tristate mean.. I don't know ? But gcc does know, with
  very very very few exceptions. Eg old mono is the exception because it
  didn't do a proper mprotect. Saying I don't know doesn't solve you
  anything, since in the end there needs to be a policy enforced anyway,
  it's just postponing the inevitable to a point with less knowledge.
  
 
 Remember I'm also thinking of restricted mprotect() situations as well,
 because I'm trying to get it to the point where one set of markings has
 a predictable effect on any kernel, be it vanilla, pax, or ES.

well that is an entirely independent thing again. Really.
I think mixing all these into one big flag is a mistake. 
(And thats a lesson I learned the hard way, but Linus was right; don't
mix independent things into one flag artificially. Extra flags are
cheap. Don't complicate the world for a dozen bytes.)




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Arjan van de Ven wrote:
 On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote:
 
-BEGIN PGP SIGNED MESSAGE-

[...]

/me shrugs.  It's a security blanket for him mostly; he fears automagic
security maintainence.
 
 
 who is him ?
 

me in third person?  :)

 
Remember also I'm very much against let the compiler guess if you need
an executable stack


it's not guessing. the *compiler* emits the stack trampoline. So the
*compiler* knows that it needs that stack.


With a trampoline, things like Grub and a few libs need PT_GNU_STACK.
 
 
 sure they do. There's about a handful in an entire distro.

Right, so it's a toss-up:  Do you want to fix these few things, or do
you want to let trampolines exist?  Are trampolines that useful?

 
 
Of course you can't just suddenly say OH!  Well PT_GNU_STACK should do
this instead! because you'll break everything.
 
 
 I'm not a fan of any kind of emutrampoline. At all. But I am open to
 others making a different tradeoff; for me the option to have a
 trampoline at all is just a bypass of the non-exec stack... legit bypass
 one hopes but a bypass regardless. Some time ago we did an eval of how
 much stuff would need the emutramp (well or something equivalent) and
 the list was so small that I decided that the added risk and complexity
 were not worth it and that I rather had those 5 or so apps run with exec
 stack.
 

Eh.

 
again what does tristate mean.. I don't know ? But gcc does know, with
very very very few exceptions. Eg old mono is the exception because it
didn't do a proper mprotect. Saying I don't know doesn't solve you
anything, since in the end there needs to be a policy enforced anyway,
it's just postponing the inevitable to a point with less knowledge.


Remember I'm also thinking of restricted mprotect() situations as well,
because I'm trying to get it to the point where one set of markings has
a predictable effect on any kernel, be it vanilla, pax, or ES.
 
 
 well that is an entirely independent thing again. Really.
 I think mixing all these into one big flag is a mistake. 
 (And thats a lesson I learned the hard way, but Linus was right; don't
 mix independent things into one flag artificially. Extra flags are
 cheap. Don't complicate the world for a dozen bytes.)
 
 

two or four dozen bytes, eight dozen bytes in 10 years when 128 bit
systems come along, and 16i dozen planck qubytes when we get quantum
computers :)

Actually when I proposed adding PT_PAX_FLAGS to Ubuntu, the very first
argument I got was Oh, yeah right, add just a few bytes here for this.
 Then later it'll be a few more bytes for something else.  Then a few
more for another thing.  It all adds up, especially when you have
thousands of binaries.

And if bitfield logic is complicated, you should stop pretending to be
a programmer.


#define BIG   (1)
#define LONG  (1  1)
#define FAT   (1  2)
#define TALL  (1  3)
#define GREEN (1  4)

struct foo {
  char *myname;
  unsigned long flags;
};

struct foo *newfoo() {
  struct foo *out = malloc(sizeof(struct foo));
  out-myname = malloc(4);
  strcpy(out-myname, bob);
  out-flags = BIG | TALL | GREEN;
  return out;
}


Easy enough?


struct foo {
  char myname[10];
  int big;
  int long;
  int fat;
  int tall;
  int green;
};

struct foo *newfoo() {
  struct foo *out = malloc(sizeof(struct foo));
  strcpy(out-myname, bob);
  out-big = 1;
  out-tall = 1;
  out-green = 1;
  return out;
}


I don't find the above to be quite as elegant.  In fact, it looks ugly
and wasteful; even checking ...

if (myfoo-flags  BIG)

versus

if (myfoo-big)

 
 
 

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

iD8DBQFCSb1rhDd4aOud5P8RAg2cAJ98SlxFCLcHvN+aWcVTM2VWxiRCEACfUPPl
24wpdtY/VyKHGs/YpPDo8Hk=
=mVc5
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Brandon Hale]

> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[Arjan van de Ven]

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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[Arjan van de Ven]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[Arjan van de Ven]

 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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[Arjan van de Ven]

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)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Brandon Hale]

  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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

-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-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ubuntu-hardened] Re: Collecting NX information

[Arjan van de Ven]

 
 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. 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/