Exec-Shield vs. PaX
page...@freemail.hu
up a few of them:
1. 'It seems that exec-shield does 99% of what PaX does'
i don't know the origin of that number above, for now i'll just
stick to the facts i know:
- PaX implements perfect non-executable pages on amd64, i386,
ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
some imitation of it only on i386 (it's not true per-page).
- PaX implements a concept about how runtime code generation
should be done, there's nothing similar in Exec-Shield, and
it seems that Ingo does not even understand why this is
important (for Ingo: please read and understand [1] before
you call something bogus, see below for more).
- PaX implements best-effort randomization of the entire
address space, Exec-Shield does it too but at a higher
code complexity and a lower entropy rate while having
a worse effect on the kernel entropy pool.
2. paxtest 'proofs'
i saw several people point to paxtest results to 'prove' how
good Exec-Shield it is. it is not. first, Exec-Shield has a
fundamental design problem stemming from the lack of understanding
or design on Ingo's part (what i call MPROTECT in PaX). you'll
really have to read the PaX design docs to understand its role
in the grand scheme of things (see below for a bit more).
second, paxtest had some bugs which Exec-Shield exposed and made
Exec-Shield appear better than it is. i've fixed them here and
expect to release 0.9.5 today or so. the results now look like:
PaXtest - Copyright(c) 2003 by Peter Busser <pe...@adamantix.org>
Released under the GNU Public Licence version 2 or later
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003 by Peter Busser <pe...@adamantix.org>
Released under the GNU Public Licence version 2 or later
Executable anonymous mapping : Vulnerable
Executable bss : Vulnerable
Executable data : Vulnerable
Executable heap : Vulnerable
Executable stack : Vulnerable
the above changes are the result of Ingo's approach to create
non-executable memory on i386, they're not per page as a simple
mprotect on the top of the stack shows. before i get accused of
specifically rigging the tests, i'll tell you that running
multithreaded apps would have almost the same effect (only the
main stack would stay non-exec under Exec-Shield). needless to
say, PaX passes all the above as before.
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 8 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 13 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 12 bits (guessed)
Shared library randomisation test : 12 bits (guessed)
Stack randomisation test (SEGMEXEC) : 17 bits (guessed)
Stack randomisation test (PAGEEXEC) : 17 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Vulnerable
Executable shared library data : Vulnerable
these two had bugs in them (they were trying to execute code
from the wrong location). i find it somewhat funny that the
Exec-Shield proponents (including Ingo himself) have used the
previous false results as a justification for their claims.
apparently none of you understood what the tests and Exec-
Shield did, otherwise you would have known that Exec-Shield
cannot possibly pass these tests due to its design (or at
least not without going down the OpenBSD road).
Writable text segments : Vulnerable
3. MPROTECT is bogus
it is not. Ingo says so because he did not understand how
PaX works. the short story (there's no substitute to reading
the docs!) is that in PaX we want to handle the problems posed
by memory corruption bugs. all such bugs. the approach chosen
in PaX is based on preventing exploit techniques from working
(vs. preventing specific bug situations from occuring, at least
for now, efficient full runtime bounds checking will have to
wait a bit). in the docs you will find a classificaiton of
exploit techniques:
(1) introduce/execute arbitrary code
(2) execute existing code out of original program order
(3) execute existing code in original program order with arbitrary data
every possible exploit technique against memory corruption bugs
belongs to one of the above (note that it is a classification of
exploit techniques, not bugs, that is, a given technique can be
used against different bugs and a given bug can be exploited by
more than one technique). the idea in PaX is that we try to prevent
entire classes of exploit techniques from working, starting with
the easy ones and going up to the hard problems. in the present
situation (1) has been dealt with, (2) is in the works, and (3)
is somewhere in the future (pending some research).
dispite Ingo's claim, restricting page protection transitions on
memory pages (which is what the mprotect() restrictions do) is
mandatory for our purposes, far from being bogus. without it, it
remains possible to introduce/execute new code into a process.
with MPROTECT and the ACL system (or a read-only chroot) to prevent
arbitrary file mappings and/or creation you can prevent attack
method (1), guaranteed. the fact that PaX does not contain the
ACL part is the simple consequence of its being used by different
projects who want to do it their way, i explicitly chose not to
stand in there (for the same reason PaX itself does not prevent
information leaking in /proc, that's up to the patch integrators).
Ingo also implied that executing an in-memory shell script via
system() does (1). it does not, it does (2). think about it,
(1) is about executable machine code, a shell script is not
machine code.
Ingo also confuses MPROTECT with mprotect() restrictions, the
former is much more than the latter, it's about separating the
writable pages from executable ones for the purposes of preventing
(1), something that Exec-Shield doesn't (cannot) do.
Ingo also argues about non-completness... in the main doc there's
an explicit paragraph for people like him, please read it again.
it will explain to you why you cannot judge a building block on
its own, only together with others. the combined effect is much
more than what the individual pieces are capable of. PaX is not
a finished project, there are several pieces of the puzzle yet
to be written.
4. PaX breaks apps, specs, whatnot
i chose to enable most of PaX by default (while allowing as many
apps to run as possible, e.g., that's why ELF text relocs are
allowed by default). since PaX explicitly wants to prevent runtime
code generation, obviously apps that want to do it will no longer
work. there are two categories of such apps and two ways to fix
them.
- apps that don't really need to generate code runtime but still
do it for whatever reason: they are buggy and must be fixed at
the source level. one prime example is the module loader code
in XFree86 which assumes that malloc()'ed memory was executable
whereas it was not (run strace on any app and you'll see how
glibc uses mmap() to request memory). another good example is
the various .plt stubs that are runtime generated on many risc
archs, for now i added emulation to them, but eventually they'd
better be redesigned a la i386.
- apps that by their nature want to generate code runtime (e.g.,
java). they're broken for good which many people noticed by now.
that's good, that was my purpose because i wanted to draw
attention to the fact that runtime code generation is an
important privilege that should be carefully managed (as it
happens to be also one of the exploit techniques). of course if
you don't agree with my exploit technique classification and
the general solution approach i took with PaX, then there's
nothing to discuss and you can stop reading this ;-). for those
who are interested in solving this problem, please read my
proposal in mprotect.txt (available at [1]).
about PaX breaking specs: i urge Ingo and others saying this to
point me to the precise location in SUSv3 or POSIX 1003.1-2001
that PaX conflicts with. for all i know, none of these standards
give ANY guarantees about the ability to generate code at runtime.
and rightly so, just think of non-coherent cache systems, you
need explicit userland (or kernel assisted, not sure how all such
systems solve it) flush interfaces, nothing like that is in the
standards (msync() is for something else, nor is it used by any
code i know that generates code at runtime, so they'd be non-compliant
even if msync() was meant for this purpose).
about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could
be changed (if one can live with a more limited range for executable
mappings), yes, it would need some userland tagging, yes, i have
ideas for it, no, it's got nothing to do with PT_GNU_STACK. the
longer story is that the majority of users don't need to care about
this address space limit, it's mainly databases and some scientific
applications that run into. mind you, they already had this problem
before when people were using 1-2 GB userlands (which back then
was the way to allow the kernel to use more than 1 GB RAM, and even
these days it's the only way to go if you don't want HIGHMEM).
as for userland tagging: i'd like to have much more control over
what userland can request from the kernel than what PT_GNU_STACK
allows. for one, requesting executable stacks is irrelevant, it
should be about requesting permission to generate code at runtime
(or just use my proposed mmap() interface changes), request
randomization, etc. i'd also like to have control over the
placement of the stack and the userland address space size in
the future. for now chpax is the quick & dirty solution for
tagging, although users of complete systems with ACLs (grsec
or RSBAC in Adamantix) can control the PaX flags via ACLs,
no need for binary modifications. mind you, it's somewhat
misleading to state that PT_GNU_STACK is a better solution
than chpax, after all, someone HAS to decide whether a given
module needs it or not (before someone points it out, trampolines
are only a small and least important part of the problem), the
toolchain cannot automatically determine it, so it needs the
exact same manual work as chpax.
i'm sure i left questions unanswered, feel free to ask here or
in private.
[1] http://pageexec.virtualave.net/docs/
PS: please CC on responses.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ingo Molnar
On Tue, 4 Nov 2003 page...@freemail.hu wrote:
> since a few points have been made regarding $subject, let me clear
> up a few of them:
>
> 1. 'It seems that exec-shield does 99% of what PaX does'
this is not the case and i'm not claiming it. If you feel attacked, please
dont - i'll stipulate that PaX gives better security than exec-shield, ok?
> i don't know the origin of that number above, for now i'll just
> stick to the facts i know:
>
> - PaX implements perfect non-executable pages on amd64, i386,
> ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
> some imitation of it only on i386 (it's not true per-page).
non-executable pages on anything else but i386 is a triviality, as the
hardware and the kernel supports it. There's virtually nothing that PaX or
exec-shield has to add to enable them - they are there. [there's the minor
issue of the process stack's protection bits.]
> - PaX implements best-effort randomization of the entire
> address space, Exec-Shield does it too but at a higher
> code complexity and a lower entropy rate while having
> a worse effect on the kernel entropy pool.
lets also point out that exec-shield offers relative randomization of DSOs
to each other, while PaX only randomizes a single base of the DSOs, their
relative addresses remain constant. This way the randomization bits of
exec-shield add up for brute-force attacks. Lets add it that if a limited
exploit can be turned into an information leak then relative randomization
does not help - but it does help if the first exploit itself needs precise
addresses from multiple DSOs. (I agree that exec-shield drains the entropy
pool more, i've got this on my TODO.)
> second, paxtest had some bugs which Exec-Shield exposed and made
> Exec-Shield appear better than it is. i've fixed them here and
> expect to release 0.9.5 today or so. the results now look like:
( how fair that you give me a chance to run it ... not. )
> 3. MPROTECT is bogus
>
> it is not. Ingo says so because he did not understand how
> PaX works. [...]
[ ... to 100% prevent: ]
> (1) introduce/execute arbitrary code
> (2) execute existing code out of original program order
> (3) execute existing code in original program order with arbitrary data
no. No offense meant, but i say so because right now i dont see the way to
have a generic and usable Linux system with all the restrictions you are
talking about. If you complete your project and everything works and it's
still the same live, flexible and kicking Linux system that we all know
and love then i was clearly wrong. Right now it seems to be heading more
in the direction of a prison - but this is just my judgement. In any case,
i did not want to add any of that to exec-shield. I'll leave the prison
guard work to selinux.
you do realise that most of those 'exploit techniques' overlap with some
programming concepts, and you think that those concepts are flawed by
design and should be eliminated - i dont agree with this characterisation.
denying executability of non-executable memory is a fair game - well
specified and a clear-cut goal. Restricting an OS to do what is arguably a
fair thing to do in a number of cases did not sound so clear-cut to me -
end of story. You might still be right in the long run, but it wasnt
obviously right at first sight, and was not complete either so it had
limited value at this stage.
> 4. PaX breaks apps, specs, whatnot
> - apps that by their nature want to generate code runtime (e.g.,
> java). they're broken for good which many people noticed by now.
> that's good, that was my purpose because i wanted to draw
> attention to the fact that runtime code generation is an
> important privilege that should be carefully managed (as it
> happens to be also one of the exploit techniques). [...]
i think here we are in a fundamental disagreement. To take it to the
extreme, being able to 'generate code' [ie. allow an application to write
code, etc.] is one of the fundamental properties of any Linux user
account, and hopefully remains so in the future. If you take that
'privilege' away you'll take away what drives Linux forward - a constantly
growing pool of programmers. I dont want good security to rely on the
system's insistence to remove the ability to generate code from as many
codepaths as possible. There's got to be another way to secure those damn
apps ... the price you are willing to pay is i believe way too high.
i find your approach interesting nevertheless, and i wish you good luck in
bringing it to completion.
> about PaX breaking specs: i urge Ingo and others saying this to
> point me to the precise location in SUSv3 or POSIX 1003.1-2001
> that PaX conflicts with. [...]
many areas of PaX conflict with one of the most basic rule of Linux:
http://lwn.net/Articles/32980/
[ that i was part of that discussion is only an annoying accident, ending
up in an API/ABI discussion again was unintended. ]
> about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could
> be changed (if one can live with a more limited range for executable
> mappings), [...]
i'm not sure it's acceptable to put _any_ restriction on the layout of the
user VM. The rule exec-shield follows is this: whenever the kernel gets a
chance to chose it will group mappings smartly, but it will follow
requests for executability no matter what. So while this doesnt _force_
good protection, for most apps it provides a pretty acceptable layout.
i guess this is a hard-to-solve philosophy difference again.
> [...] yes, it would need some userland tagging, yes, i have
> ideas for it, no, it's got nothing to do with PT_GNU_STACK. the
> longer story is that the majority of users don't need to care about
> this address space limit, it's mainly databases and some scientific
> applications that run into. mind you, they already had this problem
> before when people were using 1-2 GB userlands (which back then
> was the way to allow the kernel to use more than 1 GB RAM, and even
> these days it's the only way to go if you don't want HIGHMEM).
a fair number of users got real happy when we extended the x86 user VM
from 3GB to 4GB. Going from 3 GB to 1.5 GB is really not an option i'm
afraid. It's also not an option to say that "your app is secure only as
long as it fits into 1.5 GB". It also not an option to say "this box is
pretty secure, except for your huge database server".
and it's not an issue on all the sane architectures, fortunately. So i
think having the non-exact protection method of exec-shield will slowly be
obsoleted by ia64/amd64 systems anyway. But i'd hate to lose users to
Windows just because distros only support 1.5GB of VM.
> as for userland tagging: i'd like to have much more control over
> what userland can request from the kernel than what PT_GNU_STACK
> allows. [...]
agreed. But the process stack is arguably a special thing so PT_GNU_STACK
isnt incorrect per se. But we'd like to know and say more, i agree fully.
> [...] for one, requesting executable stacks is irrelevant, it
> should be about requesting permission to generate code at runtime
> (or just use my proposed mmap() interface changes), request
> randomization, etc. [...]
i really dont think we can realistically isolate the code generation
capability and still have a nice and flexible system. I dont see anything
wrong in apps executing scripts. Or apps writing scripts and executing
them. Or apps doing JIT stuff, or just doing some quick runtime fixup.
It's quite widely done and it would not be Linux anymore if we try to
exterminate or second-class such techniques. And it's even more common in
the Windows world, and i really hope those Windows apps continue to come
over to Linuxland.
randomization is something that is still open. How we solved it in
exec-shield is via personalities: it's something that can be set runtime,
is inherited across fork() and exec(). If you do "i386 gdb ./a.out" under
exec-shield then you'll get a non-randomized ordinary VM layout with
static predictable addresses. I dont think this should be tagged via the
binary itself - that is too inflexible. There's already one 'VM size bit'
in the personality mask in the upstream 2.6 kernel: the 3GB flag for
amd64.
> [...] i'd also like to have control over the placement of the stack
> [...]
this wouldnt be too hard, but on x86 it's not a good idea i think. But we
can definitely do it on 64-bit platforms, where there's much less danger
of vmas crossing each other.
as you might have noticed, in recent 2.6.0-test kernels there's already
one mprotect() extension that we added to support non-executable stacks:
the addition of PROT_GROWSDOWN and PROT_GROWSUP. This new syscall variant
enables the dynamic linker to change the process stack's permission
without having to know the precise edge of the stack. So the direction is
definitely towards having a more flexible layout for processes.
> [...] and the userland address space size in
> the future. for now chpax is the quick & dirty solution for
> tagging, although users of complete systems with ACLs (grsec
> or RSBAC in Adamantix) can control the PaX flags via ACLs,
> no need for binary modifications. mind you, it's somewhat
> misleading to state that PT_GNU_STACK is a better solution
> than chpax, after all, someone HAS to decide whether a given
> module needs it or not (before someone points it out, trampolines
> are only a small and least important part of the problem), the
> toolchain cannot automatically determine it, so it needs the
> exact same manual work as chpax.
no, this is not how PT_GNU_STACK works. PT_GNU_STACK not only detects
trampolines, but all those techniques that _might_ point in the direction
of process-stack executability. Such as the use of inline assembly. So the
toolchain pessimistically turns on executability and guarantees that _if_
the object is marked non-executable, that it certainly needs no executable
stack.
even the above conservative scheme gave a very high coverage rates, with
just a couple of (well below 10% of all) important apps/libs falling out
of the nonexecutability umbrella.
To solve these cases, application writers/packagers can further improve
the accuracy of this scheme by declaring said pieces of code as permitting
non-executable, but it's the right place and the best way to document it:
in the source. It cannot get lost, it will be updated when the code is
changed, etc. Tags tend to get lost, or tend to get incorrect over time.
this approach saved tons of work and the system was fully usable all
along.
Ingo
Ingo Molnar
On Tue, 4 Nov 2003 page...@freemail.hu wrote:
> second, paxtest had some bugs which Exec-Shield exposed and made
> Exec-Shield appear better than it is. i've fixed them here and
> expect to release 0.9.5 today or so. the results now look like:
i downloaded the new 0.9.5 paxtest package and amongst other changes it
has the following oneliner change:
--- paxtest-0.9.4/body.c
+++ paxtest-0.9.5/body.c
@@ -29,6 +29,7 @@
fflush( stdout );
if( fork() == 0 ) {
+ do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC);
doit();
} else {
wait( &status );
this intentionally calls mprotect(PROT_EXEC) for the highest possible
address one can think of. This call has no useful purpose at all. In other
words, this is a specific, underhand cheat to trigger 'Vulnerable'
messages for all items when running paxtest on exec-shield kernels.
Bravo!
frankly, i've never experienced anything like this in my many years in the
Linux world. You so far gave the impression of a reasonable and balanced
person but this is as low as it gets. Shame on you.
here are the paxtest-0.9.5 results with that single purpose-less line
removed, for the categories that matter to me:
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Anonymous mapping randomisation test : 8 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 13 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 12 bits (guessed)
Shared library randomisation test : 12 bits (guessed)
Stack randomisation test (SEGMEXEC) : 17 bits (guessed)
Stack randomisation test (PAGEEXEC) : 17 bits (guessed)
Executable shared library bss : Vulnerable
Executable shared library data : Vulnerable
Ingo
Graham Wilson
> On Tue, 4 Nov 2003 page...@freemail.hu wrote:
> [...]
Please, guys, don't have your discussion here. I don't think we really
care about the differences between PaX and exec-shield. Debian is not,
and, to the best of my knowledge, will not, choose one for its kernels,
so there is no need to prove that one or the other is better.
--
gram
Cameron Patrick
| Please, guys, don't have your discussion here. I don't think we really
| care about the differences between PaX and exec-shield. Debian is not,
| and, to the best of my knowledge, will not, choose one for its kernels,
| so there is no need to prove that one or the other is better.
Why should it not? If Pax or Exec-shield can be added to the kernel
without breaking things, and provide better protection against some
types of security holes than a default kernel, then surely there is a
case to be made for including one or the other in the stock Debian
kernel.
("Without breaking things" is the tricky bit here, of course.)
Cameron.
Francesco P. Lovergine
The requested debian-kernels new ML will be the perfect place to
start this kind of flame wars :) In the meantime I'm afraid there is not
another list, but for d-d, where discussion on this kind of things can
be accepted.
--
Francesco P. Lovergine
page...@freemail.hu
and i can very well understand that it's of little if any interest
to most you (that includes me btw), so i'll try not to post more
here except maybe to discuss technical issues]
> > 1. 'It seems that exec-shield does 99% of what PaX does'
>
> this is not the case and i'm not claiming it. If you feel attacked, please
> dont - i'll stipulate that PaX gives better security than exec-shield, ok?
in case you didn't realize it, it was not directed at you either.
> > - PaX implements perfect non-executable pages on amd64, i386,
> > ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has
> > some imitation of it only on i386 (it's not true per-page).
>
> non-executable pages on anything else but i386 is a triviality, as the
> hardware and the kernel supports it. There's virtually nothing that PaX or
> exec-shield has to add to enable them - they are there.
that's what you say because apparently you have never checked
it let alone tried. here's a few of these 'trivial' questions
for you to answer:
1. how do you do per page non-exec pages on ppc/ppc64? hint,
there's no NX bit in their PTE format. try to answer that
without looking at PaX first ;-)
2. how do you do per page non-exec pages on mips/mips64? hint,
there's no split TLB (let alone NX PTE bit) in the base
architecture definition.
3. how do you do per page non-exec pages on sparc64 under
linux 2.6? hint, you've reused the last free bit in the PTE.
and linux didn't support NX on sparc64 even before 2.6.
4. how do you do per page non-exec pages on sh[34]? hint, there's
at most a 'half' split TLB only and no NX PTE bit.
5. how do you do per page non-exec pages without a TLB/MMU
(you did claim 'trivial' support for anything but i386)?
next, what will you do with the archs where the .plt is in the
rwx ELF segment and hence under your scheme would force all of
.data/.bss to become executable as well?
> lets also point out that exec-shield offers relative randomization of DSOs
> to each other, while PaX only randomizes a single base of the DSOs, their
> relative addresses remain constant. This way the randomization bits of
> exec-shield add up for brute-force attacks. Lets add it that if a limited
> exploit can be turned into an information leak then relative randomization
> does not help - but it does help if the first exploit itself needs precise
> addresses from multiple DSOs.
all correct, except for the fact that the whole exercise of per-library
randomization is pointless. i say that based on my experience in analyzing
bugs and writing exploits for them - admittedly something i can't share
with you, so feel free to think otherwise. what i can offer however is
a simple observation: if an attacker needs code addresses from more than
one library, then he can get them even under Exec-Shield. this is because
he can just use the .plt entries of the library whose base address he
learned via info-leaking. also, the most likely information leaks that
contain library addresses are on the stack - and you can imagine that
the stack will likely contain such addresses from more than one region,
hence there's little if any advantage of separate randomization.
in any case, you're missing the point behind randomization. it's an
obscurity feature, however efficient it may turn out to be in certain
cases. i did it because it was extremely cheap (speaking of the PaX
implementation, not Exec-Shield) so i said 'why not'. randomization
serves NO purpose in the grand scheme, it does not provide guaranteed
protection against the PaX attack model (arbitrary read/write access
to the address space). you don't have an attack model so you can say
whatever you want about the details of your randomization, they will
of course be 'true' by definition.
> > second, paxtest had some bugs which Exec-Shield exposed and made
> > Exec-Shield appear better than it is. i've fixed them here and
> > expect to release 0.9.5 today or so. the results now look like:
>
> ( how fair that you give me a chance to run it ... not. )
from the email headers of your answer:
Date: Wed, 5 Nov 2003 00:58:30 +0100 (CET)
From: Ingo Molnar <mi...@elte.hu>
paxtest 0.9.5 was released hours (!) before that, what are you talking
about?
> > (1) introduce/execute arbitrary code
> > (2) execute existing code out of original program order
> > (3) execute existing code in original program order with arbitrary data
>
> no.
no what? are you telling me you know of an exploit technique against
a memory corruption bug that does not belong to any of the above
categories? because that's what my statement was about.
> No offense meant, but i say so because right now i dont see the way to
> have a generic and usable Linux system with all the restrictions you are
> talking about. If you complete your project and everything works and it's
> still the same live, flexible and kicking Linux system that we all know
> and love then i was clearly wrong.
http://gentoo.oregonstate.edu/experimental/x86/stages/
(i apologize for the inadvertant advocacy here, it's just to show a
point, i don't want to start a distro war)
the above is the beginning of such work with full PIE and propolice
support. or if you're into server-land, check out Adamantix [1] (it
was released before Exec-Shield).
> Right now it seems to be heading more
> in the direction of a prison - but this is just my judgement. In any case,
> i did not want to add any of that to exec-shield. I'll leave the prison
> guard work to selinux.
you're mixing up intrusion prevention (PaX) with access control. see
more below for the 'prison' argument.
> you do realise that most of those 'exploit techniques' overlap with some
> programming concepts, and you think that those concepts are flawed by
> design and should be eliminated - i dont agree with this characterisation.
putting words into my mouth or can you actually quote me on that?
what i'm saying is that there are programming techniques (runtime
code generation in this case) that should be handled more carefully
than they have been. what PaX does by default FOR NOW is the result
of me being cautious (and i have not heard of a single PaX user yet
who did not appreciate it) and not having the resources to fix up
userland all by myself. this also brings me back to your 'prison'
argument and a bigger issue you seem to be not talking about:
you said a lot about what you don't agree with in PaX, what
exactly prevented you from changing it *yourself*? what prevents
*you* from disabling MPROTECT by default for example?
speaking further about the 'prison' thing, you said this earlier
in another thread:
> if you could get rid of the 1.5 GB VM limitation of PaX and if you could
> change it to use PT_GNU_STACK to set the process stack's protection bits
> then i think there's no need for exec-shield - PaX will provide better
> protection at no cost and no tradeoffs.
have you changed your mind since then?
> > - apps that by their nature want to generate code runtime (e.g.,
> > java). they're broken for good which many people noticed by now.
> > that's good, that was my purpose because i wanted to draw
> > attention to the fact that runtime code generation is an
> > important privilege that should be carefully managed (as it
> > happens to be also one of the exploit techniques). [...]
>
> i think here we are in a fundamental disagreement. To take it to the
> extreme, being able to 'generate code' [ie. allow an application to write
> code, etc.] is one of the fundamental properties of any Linux user
> account, and hopefully remains so in the future.
the ability to create/execute one's own binaries is a privilege
too, that's what ACL and Trusted Path Execution systems allow you
to control (before you talk about 'fundamental properties' please
ask some administrators of user accounts in a corporate or
government/military environment). in any case, this is no longer
about PaX but how a secure system is to be created - there are
as many approaches as many people tried, PaX is only one (piece)
of them.
> If you take that 'privilege' away you'll take away what drives
> Linux forward - a constantly growing pool of programmers.
i have the impression that you believe i'm trying to promote PaX
to enter the 'main' kernels in its current from. to be clear about
it: i am *not*. if someone wanted to do it, i'd have several
suggestions before that should happen. such as deciding what is
acceptable to be default, how it should be controlled (configure
or runtime, etc), how and to what extent buggy userland should
be fixed, etc. all these concerns are irrelevant in the current
discussion because we're talking about technical merits (or
their lack of) of different approaches, not how they should be
deployed in the 'real world' - that's a whole another problem
and requires more parties to participate.
> I dont want good security to rely on the
> system's insistence to remove the ability to generate code from as many
> codepaths as possible.
again, nothing is removed, it's just taken under control (as i said
above, don't mistake current PaX defaults with how it should be done
when the other building blocks are done).
> There's got to be another way to secure those damn
> apps ... the price you are willing to pay is i believe way too high.
good luck in your trying to fix the problem (speaking of the PaX attack
model again here), you'd be the first one to do it without the measures
that PaX takes.
> > about PaX breaking specs: i urge Ingo and others saying this to
> > point me to the precise location in SUSv3 or POSIX 1003.1-2001
> > that PaX conflicts with. [...]
>
> many areas of PaX conflict with one of the most basic rule of Linux:
>
> http://lwn.net/Articles/32980/
i hope you realize that Linus's declaration is not on the same level
as internationally accepted standards, don't mix them up. as for not
breaking userland: sure, that's what i'd like to have as well, but
i have only so many hours in a day to work on that. also, you did
break userland yourself as well, otherwise how would you explain the
patches RedHat made to the XFree86 server? see, there're just cases
when userland is plain wrong and must be fixed. on another note, how
did you get java to work under Exec-Shield while maintaining all those
non-executable regions (see more on this below)?
> > about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could
> > be changed (if one can live with a more limited range for executable
> > mappings), [...]
>
> i'm not sure it's acceptable to put _any_ restriction on the layout of the
> user VM.
no problem, PaX as it is makes no restrictions on the layout, we'll just
be stuck with the 1.5 GB task size on i386 (or the usual 3 GB if you can
take the performance hit of PAGEEXEC on i386).
> The rule exec-shield follows is this: whenever the kernel gets a
> chance to chose it will group mappings smartly, but it will follow
> requests for executability no matter what. So while this doesnt _force_
> good protection, for most apps it provides a pretty acceptable layout.
>
> i guess this is a hard-to-solve philosophy difference again.
indeed, especially since your philosophy seems to be 'do something
while breaking absolutely no apps' where 'something' is yet to be
explained and whatever it is, you still broke apps with it (such
as XFree86).
> a fair number of users got real happy when we extended the x86 user VM
> from 3GB to 4GB. Going from 3 GB to 1.5 GB is really not an option i'm
> afraid. It's also not an option to say that "your app is secure only as
> long as it fits into 1.5 GB". It also not an option to say "this box is
> pretty secure, except for your huge database server".
that's your personal opinion. others (e.g., PaX users) have the
exact opposite as their personal opinions, so be it ;-). since
you've talked so much about what does not fit into 1.5 GB, could
you please provide us with a list of applications that are used by
the majority of users and fail when run in a 1.5 GB address space?
> obsoleted by ia64/amd64 systems anyway. But i'd hate to lose users to
> Windows just because distros only support 1.5GB of VM.
Windows has a 2 GB userland, seems to be closer to 1.5 than 3. other
than that, Microsoft is moving into the PaX direction [2] (i'm referring
to runtime code generation and memory protection in particular).
> i really dont think we can realistically isolate the code generation
> capability and still have a nice and flexible system.
it's not about 'isolation' (did you mean 'removal'?) but control.
control by the distro maker, system administrator or the end user.
what is subject to discussion how it should best be done. you say
it should not be done at all, that's your opinion and is in
complete disagreement with experts in the information security field.
> I dont see anything wrong in apps executing scripts. Or apps writing
> scripts and executing them. Or apps doing JIT stuff, or just doing
> some quick runtime fixup.
there's nothing wrong with it as long as you write bugfree code or
don't want guaranteed security from certain exploit methods. there
are people who want the latter because they have much at stake and
know that the former is not true.
> It's quite widely done and it would not be Linux anymore if we try to
> exterminate or second-class such techniques. And it's even more common in
> the Windows world, and i really hope those Windows apps continue to come
> over to Linuxland.
i know i'm repeating myself, but i'll say it again: there's no problem
with runtime code generation as long as it's under control. let's do it,
but be aware of it when it's done because it's a dangerous privilege
when abused. come up with a system that allows one to easily define and
maintain defaults and policies, and i'll be the happiest person.
> static predictable addresses. I dont think this should be tagged via the
> binary itself - that is too inflexible. There's already one 'VM size bit'
> in the personality mask in the upstream 2.6 kernel: the 3GB flag for
> amd64.
personalities are something i was thinking of before, but i had a
problem which i forget now, i'll take another look at it later.
> no, this is not how PT_GNU_STACK works. PT_GNU_STACK not only detects
> trampolines, but all those techniques that _might_ point in the direction
> of process-stack executability. Such as the use of inline assembly. So the
> toolchain pessimistically turns on executability and guarantees that _if_
> the object is marked non-executable, that it certainly needs no executable
> stack.
i was referring to this patch [3] which deals with trampolines only,
thanks for clarifying it.
> even the above conservative scheme gave a very high coverage rates, with
> just a couple of (well below 10% of all) important apps/libs falling out
> of the nonexecutability umbrella.
what about code not compiled by gcc? are all those users running with
an unsafe default (executable stack) or have broken binaries?
> To solve these cases, application writers/packagers can further improve
> the accuracy of this scheme by declaring said pieces of code as permitting
> non-executable, but it's the right place and the best way to document it:
> in the source. It cannot get lost, it will be updated when the code is
> changed, etc. Tags tend to get lost, or tend to get incorrect over time.
doing it in the source code is what i suggested as well, read the
proposal in mprotect.txt.
[now in order to save some round-trip time, i'll answer your second
mail here as well]
> i downloaded the new 0.9.5 paxtest package and amongst other changes it
> has the following oneliner change:
>
> --- paxtest-0.9.4/body.c
> +++ paxtest-0.9.5/body.c
> @@ -29,6 +29,7 @@
> fflush( stdout );
>
> if( fork() == 0 ) {
> + do_mprotect((unsigned long)argv & ~4095U, 4096,
> +PROT_READ|PROT_WRITE|PROT_EXEC);
> doit();
> } else {
> wait( &status );
>
> this intentionally calls mprotect(PROT_EXEC) for the highest possible
> address one can think of. This call has no useful purpose at all. In other
> words, this is a specific, underhand cheat to trigger 'Vulnerable'
> messages for all items when running paxtest on exec-shield kernels. Bravo!
> frankly, i've never experienced anything like this in my many years in the
> Linux world. You so far gave the impression of a reasonable and balanced
> person but this is as low as it gets. Shame on you.
several things come to my mind.
1. it's called paxtest for a reason. it's a regression test suite that
demonstrates basic exploit techniques and how PaX foils them (or not,
as the case may be). in case you don't understand 'regression', it's
not about what works, but what does not, therefore it is entirely
appropriate for PaX to show its strengths even under circumstances
where Exec-Shield fails. as i explain below, chosing between mprotect()
and threads came down to the usual question: what takes less time yet
demonstrates the effect (one line vs. a hundred or so in my case).
beyond all this, feel free to write your own suite.
2. did you miss this in my first post:
> Executable anonymous mapping : Vulnerable
> Executable bss : Vulnerable
> Executable data : Vulnerable
> Executable heap : Vulnerable
> Executable stack : Vulnerable
> the above changes are the result of Ingo's approach to create
> non-executable memory on i386, they're not per page as a simple
> mprotect on the top of the stack shows. before i get accused of
> specifically rigging the tests, i'll tell you that running
> multithreaded apps would have almost the same effect (only the
> main stack would stay non-exec under Exec-Shield). needless to
> say, PaX passes all the above as before.
do you understand what i'm saying there? did you also check the
changelog which says this:
* Non-executable page tests expose incomplete implementations
do you disagree that paxtest exposes a weakness in Exec-Shield
or not? do you disagree that the exposed weakness can very well
occur in real life or not?
let me get back to the topic of java as i promised above. java
is a nice animal as it shows several issues with Exec-Shield.
first of all, it's multithreaded. glibc creates executable
thread stacks by default. unfortunately for Exec-Shield, when
such stacks are created, everything below them becomes
executable as well, even if it was not requested by the
application. you call that a feature i assume, i call it a bug
(if i mmap() something without PROT_EXEC i don't want the OS
to change it to executable behind my back - *that* is really
not compliant with standards).
second, java has a small piece of executable code in its
.data segment - that should break it quite early during
startup. how come you never run into it if, as you claim,
.data is non-executable?
3. you and others have (ab)used paxtest long enough to justify
the approach taken by Exec-Shield while 'forgetting' to point
out the weaknesses/limitations (e.g., show me a single post
of yours where you discuss the problem with multithreaded
apps, or the more generic issue of unexpected and standard
breaking memory protection changes). forgive me if i'm not
willing to assist to this any longer, but *that* would make
me feel really ashamed.
[1] http://adamantix.org
[2] http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnwxp/html/securityinxpsp2.asp
[3] http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00302.html
Ingo Molnar
On Wed, 5 Nov 2003 page...@freemail.hu wrote:
> > i downloaded the new 0.9.5 paxtest package and amongst other changes it
> > has the following oneliner change:
[...]
> > + do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC);
> first of all, it's multithreaded. [...]
paxtest does not link to libpthread, nor does it create threads, at all.
How can you claim it's multithreaded?
> glibc creates executable thread stacks by default. [...]
to the contrary, glibc does this:
00594000-005a1000 r-xp 00000000 09:00 735400 /lib/tls/libpthread-0.60.so
005a1000-005a2000 rw-p 0000c000 09:00 735400 /lib/tls/libpthread-0.60.so
005a2000-005a4000 rw-p 00000000 00:00 0
0063b000-00650000 r-xp 00000000 09:00 730361 /lib/ld-2.3.2.so
00650000-00651000 rw-p 00015000 09:00 730361 /lib/ld-2.3.2.so
00e25000-00f58000 r-xp 00000000 09:00 735396 /lib/tls/libc-2.3.2.so
00f58000-00f5b000 rw-p 00132000 09:00 735396 /lib/tls/libc-2.3.2.so
00f5b000-00f5e000 rw-p 00000000 00:00 0
08048000-08049000 r-xp 00000000 09:02 5226629 /tmp/test
08049000-0804a000 rw-p 00000000 09:02 5226629 /tmp/test
09e9c000-09ebd000 rw-p 00000000 00:00 0
beba6000-beba7000 ---p 00000000 00:00 0 <== thread stack guard page
beba7000-bf5a8000 rw-p 00001000 00:00 0 <== non-exec thread stack
bf5be000-bf5bf000 rw-p 00000000 00:00 0
bfe79000-c0000000 rw-p fff5d000 00:00 0
$ rpm -q glibc
glibc-2.3.2-101
Ingo
page...@freemail.hu
>
> paxtest does not link to libpthread, nor does it create threads, at all.
> How can you claim it's multithreaded?
i did not. if you quote my post like this:
> let me get back to the topic of java as i promised above. java
> is a nice animal as it shows several issues with Exec-Shield.
>
> first of all, it's multithreaded. glibc creates executable
> thread stacks by default. [...]
it will be clear that i was referring to java.
> > glibc creates executable thread stacks by default. [...]
>
> to the contrary, glibc does this:
> [snip]
> $ rpm -q glibc
> glibc-2.3.2-101
that's what RedHat's glibc does. and this is what i get on gentoo
(again, sorry for the plug, although i think other distros like
debian would show the same as well):
$ epm -q glibc
glibc-2.3.2-r8
excerpt from the maps file of /opt/blackdown-jdk-1.4.1/bin/java
(running under PaX but without non-exec pages, randomization
was still on):
b7b7f000-b7b80000 +++p 00000000 00:00 0
b7b80000-b7b8e000 RWXp 00001000 00:00 0
b7b8e000-b7b91000 +++p 0000f000 00:00 0
b7b91000-b7c00000 RWXp 00012000 00:00 0
b7d7f000-b7d80000 +++p 00000000 00:00 0
b7d80000-b7d8e000 RWXp 00001000 00:00 0
b7d8e000-b7d91000 +++p 0000f000 00:00 0
b7d91000-b7e00000 RWXp 00012000 00:00 0
b7f7f000-b7f80000 +++p 00000000 00:00 0
b7f80000-b8000000 RWXp 00001000 00:00 0
b8500000-b850a000 RWXp 00000000 00:00 0
b850a000-b850d000 +++p 00000000 00:00 0
b86f2000-b86fb000 RWXp ffff8000 00:00 0
regardless of whether RedHat fixed this or not (i hope it will enter
the main glibc tree btw), the fundemantal problem of changing memory
protections without asking stays there (LinuxThreads was just one
known way to trigger it).
Peter Busser
> > this intentionally calls mprotect(PROT_EXEC) for the highest possible
> > address one can think of. This call has no useful purpose at all. In other
> > words, this is a specific, underhand cheat to trigger 'Vulnerable'
> > messages for all items when running paxtest on exec-shield kernels. Bravo!
If you get bad grades on school, don't work harder, blame the teacher.
Other people have been asking for such a test, because there was speculation
about this vulnerability in exec-shield. It is in fact a simulation of a
multithreaded application. I objected to adding tests that include a multi-
threaded library, because the library might interfere with the results of the
test. So instead of adding a library that would perform the mprotect(), the
mprotect() itself was added. Since multi-threaded applications are not that
uncommon. Therefore the results are quite relevant I think.
People deserve to know what the limitations the security products they use
have. That is why the return to function tests have been included, to show that
PaX is good but not perfect. Paxtest simply shows if people tell the truth
about memory protection patches. I wrote it to see if what pageexec told me
about it was true or not, so I wouldn't lie to people when I tell them
Adamantix has good memory protection. There are already too many lies in the
security world that there is no need for even more.
And after all, if exec-shield is being included in the Debian default kernel
source, then you are talking about the pride of a 1000 developers that are at
stake here. That is not something you should take lightly if you ask me. :-)
> > frankly, i've never experienced anything like this in my many years in the
> > Linux world. You so far gave the impression of a reasonable and balanced
> > person but this is as low as it gets. Shame on you.
Do you have the detailed specification of exec-shield somewhere? That would
make it easier to evaluate the completeness of the test suite. Feel free to
submit tests yourself, I'll add any sensible test.
Groetjes,
Peter Busser
--
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/
Adam Heath
> And after all, if exec-shield is being included in the Debian default kernel
> source, then you are talking about the pride of a 1000 developers that are at
> stake here. That is not something you should take lightly if you ask me. :-)
You mean the single developer who maintains the standard debian kernel, or the
single developer who maintains the execshield or pax patches.
Ingo Molnar
On Wed, 5 Nov 2003 page...@freemail.hu wrote:
> > > glibc creates executable thread stacks by default. [...]
> >
> > to the contrary, glibc does this:
> > [snip]
> > $ rpm -q glibc
> > glibc-2.3.2-101
>
> that's what RedHat's glibc does. [...]
yes. The changes are in mainline glibc, everyone will pick those changes
up with time.
Ingo
Ingo Molnar
On Wed, 5 Nov 2003, Peter Busser wrote:
> It is in fact a simulation of a multithreaded application. [...]
The test incorrectly assumes that thread stacks are executable. I suspect
we both agree that it's desirable to have thread stacks non-executable as
well.
> I objected to adding tests that include a multi- threaded library,
> because the library might interfere with the results of the test.
in fact it's desirable to properly have the same 'effect' a pthread
library has - after all that 'effect' might have security relevance. The
best way to do that is to use the threading library used by virtually all
applications on the box where the test is running: -lpthread.
> [...] Feel free to submit tests yourself, I'll add any sensible test.
yep, proper threaded test added. This should put this episode to rest.
Ingo
diff -rNu paxtest-0.9.5/body.c paxtest-0.9.5/body.c
--- paxtest-0.9.5/body.c
+++ paxtest-0.9.5/body.c
@@ -13,6 +13,13 @@
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
+#include <pthread.h>
+
+static void *test_thread(void *p)
+{
+ pause();
+ return NULL;
+}
#ifndef PAGESIZE
#define PAGESIZE (4096)
@@ -29,8 +36,13 @@
fflush( stdout );
if( fork() == 0 ) {
- do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC);
+ pthread_t thread;
+
+ pthread_create(&thread, NULL, test_thread, NULL);
+
doit();
+
+ pthread_kill(&thread, SIGTERM);
} else {
wait( &status );
if( WIFEXITED(status) == 0 ) {
diff -rNu paxtest-0.9.5/Makefile.generic paxtest-0.9.5/Makefile.generic
--- paxtest-0.9.5/Makefile.generic
+++ paxtest-0.9.5/Makefile.generic
@@ -2,7 +2,7 @@
CC=gcc
CFLAGS=-O2
-LDFLAGS=
+LDFLAGS=-lpthread
ifndef RUNDIR
RUNDIR=.
endif
Ingo Molnar
On Wed, 5 Nov 2003 page...@freemail.hu wrote:
> > non-executable pages on anything else but i386 is a triviality, as the
> > hardware and the kernel supports it. There's virtually nothing that PaX or
> > exec-shield has to add to enable them - they are there.
You are right that the other architectures you listed need alot of
nontrivial work and PaX did it very nicely. The two architectures that
will likely capture more than 90% of the CPU market in the next 10 years,
ia64 and amd64 both have executable bits in their pte formats. These need
no extra work. My sentence above should be "any of the x86 successors",
instead of "anything else".
[ i accept your points wrt. relative randomization. ]
> [...] randomization serves NO purpose in the grand scheme, it does not
> provide guaranteed protection against the PaX attack model (arbitrary
> read/write access to the address space). [...]
there's another, practical aspect of address-space randomization which i
find to be the most important: to make worms uneconomic in network
bandwidth terms. The most effective worm in recent history was a
single-packet exploit-and-infect attack, with a high likelyhood to infect
a machine via that single packet. If the worm has to guess certain exploit
parameters then the introduction of just one other packet can make or
break the dynamics of worm propagation - let alone the need for 1024 or
32K packets for a single infection. So randomization does have an
important longterm significance.
i agree that it's near worthless against local attacks or directed
attacks. It might help in eventually bringing more attention to the attack
itself but that's not a guarantee.
> > > second, paxtest had some bugs which Exec-Shield exposed and made
> > > Exec-Shield appear better than it is. i've fixed them here and
> > > expect to release 0.9.5 today or so. the results now look like:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > ( how fair that you give me a chance to run it ... not. )
i take this back - you did offer it for download. (I was parsing 'today or
so' as 'sometime later' and didnt check your site. I did check it after
sending the mail and discovered the new package. Obviously my points wrt.
the 'threading change' remain.)
> > you do realise that most of those 'exploit techniques' overlap with some
> > programming concepts, and you think that those concepts are flawed by
> > design and should be eliminated - i dont agree with this characterisation.
>
> putting words into my mouth or can you actually quote me on that?
i did not intend to put anything in your mouth - this is how i understood
your paragraph below:
> - apps that by their nature want to generate code runtime (e.g.,
> java). they're broken for good which many people noticed by now.
> that's good, that was my purpose because i wanted to draw
> attention to the fact that runtime code generation is an
> important privilege that should be carefully managed (as it
> happens to be also one of the exploit techniques).
i took the 'they are broken for good' as equivalent to 'concepts flawed by
design', and 'important privilege that should be carefully managed' as a
signal of your belief that the ability to generate code should be
restricted. I do not agree with this direction. The moment you start to
'manage' stuff that you believe is 'broken for good' it ends up being less
accessible to people.
(let me know if you think this is an unfair/inaccurate characterisation of
your words.)
> what i'm saying is that there are programming techniques (runtime code
> generation in this case) that should be handled more carefully than they
> have been. what PaX does by default FOR NOW is the result of me being
> cautious (and i have not heard of a single PaX user yet who did not
> appreciate it) and not having the resources to fix up userland all by
> myself. [...]
my experience is that resources that get 'managed' manually tend to be
much less accessible to the average user. Scripting (which is a form of
code generation) and generally writing code is the heart of Linux.
I would like to see all these security technologies to show up on Joe
Average's desktop, so government-style manual need-to-know access control
just doesnt cut it. It might work if packaged very very carefully with
lots of care towards making it simple, but i see zero efforts in that
direction. In fact i got flamed for even mentioning PT_GNU_STACK which i
believe is one careful step in that direction.
> you said a lot about what you don't agree with in PaX, what exactly
> prevented you from changing it *yourself*? what prevents *you* from
> disabling MPROTECT by default for example?
we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did
seem to be a reasonable person with tons of experience and this matters
alot when considering patches) and the killer at that time was the 1.5 GB
VM limitation on x86. Exec-shield, as coarse as it might be, does here and
today offer quite acceptable non-executability coverage of all actual apps
we checked, and this is what counts. (Nobody puts bogus mprotect(argv)
calls into these apps to disable exec-shield so exec-shield just works.)
If you ask any user about security they'll just nod and say it's very
important. But when facing them with the cost of security they'll just
shout at administration difficulties and broken apps and performance
impact, so only a careful and evolutionary approach suffices. Stuff can
only be added piece by piece, with frequent backtracks.
(Having said that, there's no reason why exec-shield couldnt be exchanged
for PaX in the future - most of the security features in Fedora are not
related to the dynamic-segmentation-limit thing of exec-shield at all,
what precise mechanism enforces the executability permission expressed in
the vma is irrelevant, as long as it works.)
the mprotect argument came not from my ability to enable or disable it in
PaX, but from the claim/impression that the (mprotect) tests in paxtest
constitude actual 'Vulnerabilities'. So i simply said i dont intend to
restrict mprotect semantics in exec-shield and explained my reasons for
doing so.
> speaking further about the 'prison' thing, you said this earlier
> in another thread:
>
> > if you could get rid of the 1.5 GB VM limitation of PaX and if you could
> > change it to use PT_GNU_STACK to set the process stack's protection bits
> > then i think there's no need for exec-shield - PaX will provide better
> > protection at no cost and no tradeoffs.
>
> have you changed your mind since then?
no, i havent. PaX is fundamentally finer grained than exec-shield. Eg.
exec-shield will never make library data/bss non-executable. The other
problems, like thread stacks or apps doing mprotect()s were solved, so all
the other exploitable areas are non-executable.
> > If you take that 'privilege' away you'll take away what drives
> > Linux forward - a constantly growing pool of programmers.
>
> i have the impression that you believe i'm trying to promote PaX to
> enter the 'main' kernels in its current from. [...]
this impression of yours is incorrect. PaX as a whole has no chance to get
into the kernel in the near future. Nor does exec-shield. (Linus is quite
strongly against security related restrictions.)
but i'd love it if you could start pushing eg. the arch exec-bit PTE
changes into the kernel - those would be very nice to have.
> [...] also, you did break userland yourself as well, otherwise how would
> you explain the patches RedHat made to the XFree86 server? [...]
that was a bugfix - X relied on executability of a non-executable area.
The x86 kernel just didnt enforce it. X would crash the same way on amd64
when running in x86 mode, without exec-shield.
(in fact X did properly use an executable area on other architectures -
just not x86 - the code was #ifdef-ed out on x86.)
it's not a bugfix to break apps that rely on an executable stack - the
stack _is_ executable.
> [...] see, there're just cases when userland is plain wrong and must be
> fixed. [...]
there's nothing wrong about an executable stack though. It's been part of
Linux ever since.
Ingo
Ingo Molnar
On Wed, 5 Nov 2003 page...@freemail.hu wrote:
> [...] also, you did break userland yourself as well, otherwise how would
> you explain the patches RedHat made to the XFree86 server?
actually, unmodified XFree86 works just fine. It will have an executable
stack but it will work out of box - so no app was broken. tuxracer works
out of box as well.
X does break if you force exec-shield=2, and it did break even with
exec-shield=1 in earlier iterations of exec-shield, but that bug has been
fixed.
the XFree86 patching you refer to above we did was to enable non-exec
stack. But this was an iterative thing to enhance security, not something
we had to do because X broke due to exec-shield itself.
Ingo
page...@freemail.hu
> > you explain the patches RedHat made to the XFree86 server?
>
> actually, unmodified XFree86 works just fine. It will have an executable
> stack but it will work out of box - so no app was broken.
false! my unmodified X server (gentoo) dies with the following core
when trying to run it under [1]:
(gdb) bt
#0 0x00caf471 in kill () from /lib/libc.so.6
#1 0x00caf215 in raise () from /lib/libc.so.6
#2 0x00cb07bb in abort () from /lib/libc.so.6
#3 0x0806eb99 in AbortDDX ()
#4 0x080ed43a in FatalError ()
#5 0x0808522c in xf86SigHandler ()
#6 <signal handler called>
#7 0x0a226000 in ?? ()
#8 0x080a6f98 in LoadModule ()
#9 0x0806fa3c in xf86LoadModules ()
#10 0x0806db2a in InitOutput ()
#11 0x080d36c1 in main ()
does LoadModule() ring a bell? why don't you realize that there's a
world beyond RedHat and that you *do* break those people's system?
heck, you did break RedHat users' systems as well, you say so yourself:
[2] or [3]. every time you suggest that a user upgrade X means that
you have broken his existing binary - a clear no-no by your own rules.
> X does break if you force exec-shield=2, and it did break even with
> exec-shield=1 in earlier iterations of exec-shield, but that bug has been
> fixed.
excerpt from [1]:
--- linux/kernel/sysctl.c.orig
+++ linux/kernel/sysctl.c
@@ -52,6 +52,9 @@ extern int core_uses_pid;
extern char core_pattern[];
extern int cad_pid;
+int exec_shield = 2;
+int exec_shield_randomize = 1;
that to me means that *everyone* will have his *existing* binary
broken, by your own admission. it also means that you have
violated the very rule of Linus you had referred to before.
> the XFree86 patching you refer to above we did was to enable non-exec
> stack. But this was an iterative thing to enhance security, not something
> we had to do because X broke due to exec-shield itself.
XFree86 never needed an executable stack as far as i know, what was
there to 'enhance' then? it is clear that XFree86 did break because
of Exec-Shield and you had to modify both to get it to work and be
able to claim that it works out of the box. incidentally, if i were
to make use of PT_GNU_STACK in PaX, i could claim the same - now what
was your point of fighting this silly issue?
by the way, on another look at your patch i noticed the following:
1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables()
but don't make use of it, probably it's not needed at all now.
2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state
between mpnt->vm_page_prot and mpnt->vm_flags, the former should
be derived from the latter, just like do_mmap_pgoff() does it.
[1] http://people.redhat.com/mingo/exec-shield/exec-shield-2.4.22-G4
[2] http://marc.theaimsgroup.com/?l=linux-kernel&m=106482772021534&w=2
[3] http://marc.theaimsgroup.com/?l=linux-kernel&m=106502603232695&w=2
Ingo Molnar
On Thu, 6 Nov 2003 page...@freemail.hu wrote:
> > actually, unmodified XFree86 works just fine. It will have an executable
> > stack but it will work out of box - so no app was broken.
>
> false! my unmodified X server (gentoo) dies with the following core
> when trying to run it under [1]:
you need to update your gcc, glibc and binutils chain and change
exec-shield=1 (all the code is available under the GPL) to get a fully
compatible exec-shield solution.
the patches on my site default to exec-shield=2. exec-shield=2 means
blanket non-exec stacks for _every_ binary. You are trying to make a big
fuss about this for no good reason. My patches default to 2 to get wider
testing without having to recompile all of userspace. (but recompiling all
of userspace shouldnt be an issue on your gentoo box.)
> > X does break if you force exec-shield=2, and it did break even with
> > exec-shield=1 in earlier iterations of exec-shield, but that bug has been
> > fixed.
>
> excerpt from [1]:
> +int exec_shield = 2;
Look at the Fedora Core 1 distribution released yesterday to see the
complete solution - there exec-shield defaults to 1. You need PT_GNU_STACK
markings for all apps to work under exec-shield. It cannot be solved via a
single kernel patch. If exec-shield is to be added to Debian then this
should be done too.
Ingo
page...@freemail.hu
Ingo, please. it was *you* who objected to PaX's default enforcement
policy because it broke Linus's rule. yet you did the same with your
own default *and* contested the fact that you hadn't broken anything.
i don't have a problem with your choice for default policies, i have
a problem when you have a double standard ('kettos merce' in your
mother tongue).
Ingo Molnar
On Thu, 6 Nov 2003 page...@freemail.hu wrote:
> [...] incidentally, if i were to make use of PT_GNU_STACK in PaX, i
> could claim the same - now what was your point of fighting this silly
> issue?
yes, this was precisely my point to discuss this issue. Executability of
the stack is not some divine privilege given to the sacred few,
distributed via matters of public policy determined by the ruler of the
system, it's simply a property of the code written. The system ought to
detect it automatically and not stand in the way. We implemented the code
for this - and the compiler, toolchain and glibc supports it all across.
If PaX makes use of PT_GNU_STACK [just take the binfmt_elf.c bits] then
this portion of PaX will conform to the Linus rule too. This is not some
magic property only attached to exec-shield.
this is i believe the main goal, in the quest to bring security to the
average user. The only way to do that is to concentrate all technology on
making security as automatic and hassle-free as possible.
i hope we've finally settled this issue, right? You might still think of
me in unfavorable terms but i've got to live with that :-)
> by the way, on another look at your patch i noticed the following:
>
> 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables()
> but don't make use of it, probably it's not needed at all now.
>
> 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state
> between mpnt->vm_page_prot and mpnt->vm_flags, the former should
> be derived from the latter, just like do_mmap_pgoff() does it.
thanks, i'll fix these!
Ingo
Ingo Molnar
On Thu, 6 Nov 2003 page...@freemail.hu wrote:
> > there's nothing wrong about an executable stack though. It's been part of
> > Linux ever since.
>
> the brk() managed heap has also been executable. yet you break apps that
> assume so (the ominous XFree86 server would also use the brk() managed
> heap if you were to tell malloc() to not use mmap() at all or for 'big'
> areas only, well beyond the default 128k. actually, for 'small' modules
> XFree86 does use the brk() heap).
yes. This is one reason why exec-shield isnt ready for the mainline kernel
(and might never be). Fortunately, executable malloc() assumptions seem to
be much less widespread than the reliance on an executable stack. But you
are right of course, exec-shield breaks the 'Linus rule' too.
Ingo
page...@freemail.hu
> > provide guaranteed protection against the PaX attack model (arbitrary
> > read/write access to the address space). [...]
>
> there's another, practical aspect of address-space randomization which i
> find to be the most important: to make worms uneconomic in network
> bandwidth terms.
having non-executable pages achieves the same *and* guarantees failure
(vs. the probabilistic failure/success rate of randomization), that's
why i said that randomization played no role 'in the grand scheme'. the
fact it's still useful these days is the consequence of our inability
to effectively protect against the attack methods 2 and 3 i had referred
to earlier (luckily for the defense side, existing worms have used
attack method 1 but i would not rely on that in the future).
> i took the 'they are broken for good' as equivalent to 'concepts flawed by
> design', and 'important privilege that should be carefully managed' as a
> signal of your belief that the ability to generate code should be
> restricted. I do not agree with this direction.
'they are broken for good' means just that, they are no longer able
to run under PaX without tagging (at least not when PaX is configured
in its optimal form, that is, with non-exec pages and MPROTECT on).
you're correct with what i meant by 'managed' although i think you
may not like it because of the choice of my wording, not because what
i meant. if i say 'we need an API to allow userland to generate
code at runtime', will you still disagree with that (meaning 'disagree
on principles', not the suggested implementation)?
> The moment you start to 'manage' stuff that you believe is
> 'broken for good' it ends up being less accessible to people.
'root for everyone!' - isn't that concept 'broken for good' (in the
sense you originally interpreted it, i.e., 'flawed by design')? see,
we do change systems to be able to 'manage stuff' even if that means
that we'll make that stuff 'less accessible to people' (how many times
do system admins have to do things on behalf of their users because
said users are now not allowed to do it themselves?). so what am i
getting at here? the fact that secure (heck, even just usable) systems
should follow the principle of 'least privilege'. in the multi-user
system case, it says (among others) that if a user does not need to
have the privilege of root (read: complete system control), then he
should not have it, hence we have the concept of UIDs (and capabilites,
as the case may be). in the PaX memory protection case it means that
if an application does not need the privilege to generate code at
runtime, then it should not have it.
interestingly enough, this is exactly what i say in [3] - did you
read/understand it? if you did, then you should have realized that
you can argue only about whether you want to follow a least privilege
policy in this case, you cannot argue about how to do it because
there's just one way (the memory protection concept of PaX).
> I would like to see all these security technologies to show up on Joe
> Average's desktop, so government-style manual need-to-know access control
> just doesnt cut it. It might work if packaged very very carefully with
> lots of care towards making it simple, but i see zero efforts in that
> direction.
i would not call [1] or [2] 'zero efforts'.
> > you said a lot about what you don't agree with in PaX, what exactly
> > prevented you from changing it *yourself*? what prevents *you* from
> > disabling MPROTECT by default for example?
>
> we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did
> seem to be a reasonable person with tons of experience and this matters
> alot when considering patches) and the killer at that time was the 1.5 GB
> VM limitation on x86. Exec-shield, as coarse as it might be, does here and
> today offer quite acceptable non-executability coverage of all actual apps
> we checked, and this is what counts. (Nobody puts bogus mprotect(argv)
> calls into these apps to disable exec-shield so exec-shield just works.)
[...]
> the mprotect argument came not from my ability to enable or disable it in
> PaX, but from the claim/impression that the (mprotect) tests in paxtest
> constitude actual 'Vulnerabilities'. So i simply said i dont intend to
> restrict mprotect semantics in exec-shield and explained my reasons for
> doing so.
i'm sorry that you still haven't realized what PaX/paxtest are about.
PaX works against *exploit*methods* and paxtest simulates the core
steps of those methods to determine to what extent they work on a
given system. what you call 'bogus' again shows your misunderstanding
of how one writes exploits. let's do some thinking:
why did you write Exec-Shield (non-exec pages, randomization)? to
make exploit methods non-working. now the question is, have you
achieved that goal or not? or a bit harder question: what did you
achieve exactly? my answers are below:
Exec-Shield prevents existing exploits that rely on injecting/executing
their own payload from working (well, more or less, there can be cases
like with multithreaded apps on a non-RedHat system where such payload
shows up in a writable/executable part of the address space since such
does exist under Exec-Shield, unlike PaX).
i'd like to stress *existing* in the above because it leads to the
next question: what can you say about *future* exploits? what can
you say about the *possibility* of creating exploits that circumvent
Exec-Shield? you cannot make any generic claim either way because of
the lack of design in Exec-Shield. you can make claims about what
is needed to circumvent it, like the attacker needs to do a
return-to-libc style exploit to call mmap/mprotect and elevate the
executable region limit so that he can simply execute his payload
just like he did so in the past. however you cannot claim whether
this is possible for a given bug or not, at least not until you or
someone examines the precise circumstances and determines whether
it's possible or not. who's gonna do this every time a new bug
becomes public? why do we even have to ask this question and waste
precious human resources to answer it? see, that's the difference
between PaX and everything else i know of: PaX gives you guarantees
and you can sleep a bit better because you can rest assured as to
what an attacker can do with a bug (in the future that 'what' will
be 'nothing beyond denial of service'). you don't understand/care
about such assurance - that's your personal choice but there are
people who think otherwise and don't appreciate your calling PaX
methods 'bogus'.
> > [...] see, there're just cases when userland is plain wrong and must be
> > fixed. [...]
>
> there's nothing wrong about an executable stack though. It's been part of
> Linux ever since.
the brk() managed heap has also been executable. yet you break apps
that assume so (the ominous XFree86 server would also use the brk()
managed heap if you were to tell malloc() to not use mmap() at all
or for 'big' areas only, well beyond the default 128k. actually, for
'small' modules XFree86 does use the brk() heap).
speaking of breakage, you didn't not react on Exec-Shield breaking
POSIX/SUSv3 - any comments?
[1] http://adamantix.org
[2] http://www.gentoo.org/proj/en/hardened
[3] http://pageexec.virtualave.net/docs/noexec.txt
page...@freemail.hu
>
> The test incorrectly assumes that thread stacks are executable. I suspect
> we both agree that it's desirable to have thread stacks non-executable as
> well.
while i agree with you on this one, it is in stark contrast to what you
said earlier:
> there's nothing wrong about an executable stack though. It's been part of
> Linux ever since.
also, the test does not only demonstrate that thread stacks are executable
or not, it demonstrates a fundemental design flaw in Exec-Shield: whenever
an executable region is created in the address space, *everything* below
that becomes executable as well. i believe it is important that Exec-Shield
users are aware of this flaw, could you write a test for this as well please?
Ingo Molnar
On Thu, 6 Nov 2003 page...@freemail.hu wrote:
> > The test incorrectly assumes that thread stacks are executable. I suspect
> > we both agree that it's desirable to have thread stacks non-executable as
> > well.
>
> while i agree with you on this one, it is in stark contrast to what you
> said earlier:
>
> > there's nothing wrong about an executable stack though. It's been part of
> > Linux ever since.
sorry but i really have to say that your logic is flawed. (It's sad to see
when a discussion deteriorates to such a stage and i've decided to stop it
from my side, see more below. [ thousands of debian-devel readers rejoice
:-) ] )
"The test incorrectly assumes that thread stacks are executable" is not
equivalent to "thread stacks are non-executable". And there's no conflict
in what i say above.
all i'm saying is that each and every application has a fair right to
assume an executable stack. _If_ tools find (or developer asserts it, in
the source) that a particular application does _not_ need an executable
stack then it's perfectly fine for the OS to go for it and enable a
non-executable stack!
you should not do this decision for the application/library in one way or
another.
> also, the test does not only demonstrate that thread stacks are
> executable or not, it demonstrates a fundemental design flaw in
> Exec-Shield: whenever an executable region is created in the address
> space, *everything* below that becomes executable as well. [...]
thanks, the cat is finally out of the bag - you admit here that the
incriminating paxtest code is there to demonstrate what you characterise
as a flaw in exec-shield. Note that none of your arguments tries to claim
that any real application indeed does "mprotect(argv)", which is pretty
telling by itself.
As i have explained it a hundred times, this behavior is a well-known
property of exec-shield, and that we've done a quite good job of reducing
this effect. In fact i've put it into my exec-shield announcement:
# Limitations:
# ------------
#
# also, if the overflow is within the exec-shield itself (e.g. within the
# data section of one of the shared library objects in the ASCII-armor)
# then the overflow might be possible to exploit.
#
# [...]
# All in one, exec-shield is one barrier against attacks, not blanket 100%
# protection in any way. The most efficient security can be provided by
# installing as many layers as possible.
But you dont have to believe me, you can try it yourself, install an
exec-shield distro and measure the effect of this exec-shield property.
( sorry, but i'm going to stop contributing to this thread. You are
getting increasingly irrational and emotional, there's nothing more i
could add to this thread. I do acknowledge that PaX is more secure, but i
also say that exec-shield is a hell alot of a difference from a stock
distro. You expressed your feelings that exec-shield is insecure in one
area and apparently you conclude that it's thus useless. There's nothing i
can do to change this irrational bad logic of yours. )
Ingo
ps. for those who'd like to get rid of this thread too, put this into
your .procmailrc:
:0:
* ^Subject:.*Exec-Shield vs. PaX
/dev/null
Yven Johannes Leist
Well, I for one would love to see a security announcement one day, which
contains something like:
"All users running the standard Debian kernel are not affected, since the
special security features the Debian kernel contains prevent the
exploit/attack in question." :)
Cheers,
Yven
--
Yven Johannes Leist - le...@xnap.org
http://www.xnap.org/leist/
Henning Makholm
> Well, I for one would love to see a security announcement one day, which
> contains something like:
>
> "All users running the standard Debian kernel are not affected, since the
> special security features the Debian kernel contains prevent the
> exploit/attack in question." :)
Hm, what I've been able to glean from the discussions seems to imply
that any software that's vulnerable to a remote access exploit
*without* the kernel-level protection in question, would still at
least be vulneable to a DoS attack, killing the server (or whatever)
process instead of giving the attacker actual control. So we'd still
want to provide security updates to the same extent as without.
--
Henning Makholm "Hele toget raslede imens Sjælland fór forbi."
page...@freemail.hu
> equivalent to "thread stacks are non-executable". And there's no conflict
> in what i say above.
ok, i was quoting too much and you interpreted the wrong part. the bit
i was referring to is this:
> I suspect we both agree that it's desirable to have thread stacks
> non-executable as well.
on one hand you acknowledge that it's better to have non-exec thread
stacks but on the other hand you argued that
> it's not a bugfix to break apps that rely on an executable stack - the
> stack _is_ executable.
^^^^^^^^^^^^^^^^^^^^^
as they say, you can't have it both ways.
> > also, the test does not only demonstrate that thread stacks are
> > executable or not, it demonstrates a fundemental design flaw in
> > Exec-Shield: whenever an executable region is created in the address
> > space, *everything* below that becomes executable as well. [...]
>
> thanks, the cat is finally out of the bag - you admit here that the
> incriminating paxtest code is there to demonstrate what you characterise
> as a flaw in exec-shield.
the cat has always been out of the bag, way back in my very first mail
in this thread (and it's now the second time i've quoted this bit):
> Executable anonymous mapping : Vulnerable
> Executable bss : Vulnerable
> Executable data : Vulnerable
> Executable heap : Vulnerable
> Executable stack : Vulnerable
>
> the above changes are the result of Ingo's approach to create
> non-executable memory on i386, they're not per page as a simple
> mprotect on the top of the stack shows. before i get accused of
> specifically rigging the tests, i'll tell you that running
> multithreaded apps would have almost the same effect (only the
> main stack would stay non-exec under Exec-Shield). needless to
> say, PaX passes all the above as before.
since you have such a problem with paxtest doing the explicit
mprotect() itself i decided to change it to a simple nested
function, it will achieve the same and hopefully satisfy you
as well.
> Note that none of your arguments tries to claim
> that any real application indeed does "mprotect(argv)", which is pretty
> telling by itself.
indeed. if you read my mails again (i'm getting tired of quoting
myself all over again), i told you explicitly what paxtest is for:
testing for regressions, situations when stuff fails. Exec-Shield
fails under the above mentioned situation. it also fails when gcc
nested functions are used, you'll see that in 0.9.6. i hope you
won't argue that no real application uses nested functions (and
before you object even to that, as you said yourself, nested functions
are just one way to trigger the heuristics in gcc, other code
constructs from real life would do the same as well).
> As i have explained it a hundred times, this behavior is a well-known
> property of exec-shield, and that we've done a quite good job of reducing
> this effect. In fact i've put it into my exec-shield announcement:
*none* of your public postings discusses the inherent problem with
memory regions becoming executable when something above them does.
the quote from your README talks about the ascii-armor region and
data being executable in there. it does not talk about how the main
application's data or the heap or even the entire stack can become
unexpectedly executable. on a related note, PT_GNU_STACK support
as implemented in Exec-Shield suffers from the same problem: you
make not only the stack executable but *everything* else below it,
i could not find a note from you talking about it.
> ( sorry, but i'm going to stop contributing to this thread. You are
> getting increasingly irrational and emotional, there's nothing more i
> could add to this thread. I do acknowledge that PaX is more secure, but i
> also say that exec-shield is a hell alot of a difference from a stock
> distro. You expressed your feelings that exec-shield is insecure in one
> area and apparently you conclude that it's thus useless. There's nothing i
> can do to change this irrational bad logic of yours. )
Ingo, if you read one of my previous posts, you will realize that
i did say that Exec-Shield was mostly good enough against current
exploit methods (which blindly expect their injected payload to be
executable). what it's not good enough for is protecting against
future attacks which will (because they can) adapt and circumvent
Exec-Shield in certain cases. this is not true for PaX and obviously
that decides what i'm going to use (and have been for all these
past 3 years). and finally on a personal note: you're quick to
call people by names, that's not professional especially when none
of the facts support your position.
-------------------------------------------------------------------
i was not cc'd on this, but i'd still like to reply here:
Henning Makholm said:
> Hm, what I've been able to glean from the discussions seems to imply
> that any software that's vulnerable to a remote access exploit
> *without* the kernel-level protection in question, would still at
> least be vulneable to a DoS attack, killing the server (or whatever)
> process instead of giving the attacker actual control. So we'd still
> want to provide security updates to the same extent as without.
you're absolutely correct, there is *no* substitute to using correct
software. intrusion prevention systems exist for the purpose to
provide some level of protection until such an update can be made
and installed. there are many reasons why it may not always happen
in a timely manner. for one, there are bugs which are simply not
known publicly (the 0-day exploit case), or there're services/servers
which cannot be taken down in certain hours of the day (and the risk
of a DoS is still more acceptable than the risk of getting compromised),
or the system admin is simply too busy to install the update as soon
as it's released (full automation of software updates carries its
risks as well as i'm sure many admins can tell).
Cameron Patrick
| > I suspect we both agree that it's desirable to have thread stacks
| > non-executable as well.
|
| on one hand you acknowledge that it's better to have non-exec thread
| stacks but on the other hand you argued that
|
| > it's not a bugfix to break apps that rely on an executable stack - the
| > stack _is_ executable.
| ^^^^^^^^^^^^^^^^^^^^^
|
| as they say, you can't have it both ways.
He's saying that there's no reason to have an executable stack for
programs which never attempt to execute code on the stack---and having a
non-executable stack in such circumstances gives you a security
advantage---but it is not okay for the operating system to break those
programs which /do/ rely on the stack being executable.
Now could you please stop wasting everybody's time by continuing this
thread? Ingo has already stated that he won't continue arguing with
you, and I don't intend to continue posting in this thread after this
message either.
Cameron.
Russell Coker
> Well, I for one would love to see a security announcement one day, which
> contains something like:
>
> "All users running the standard Debian kernel are not affected, since the
> special security features the Debian kernel contains prevent the
> exploit/attack in question." :)
To get this we need support for PIE executables, and preferrably something
like ProPolice as well.
Currently Debian is behind Fedora and is not showing any signs of catching
up...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Daniel Jacobowitz
> On Fri, 7 Nov 2003 12:57, Yven Johannes Leist wrote:
> > Well, I for one would love to see a security announcement one day, which
> > contains something like:
> >
> > "All users running the standard Debian kernel are not affected, since the
> > special security features the Debian kernel contains prevent the
> > exploit/attack in question." :)
>
> To get this we need support for PIE executables, and preferrably something
> like ProPolice as well.
>
> Currently Debian is behind Fedora and is not showing any signs of catching
> up...
We'd need a hell of a lot more evidence of PIE's value before I'd let
anyone inflict that on Debian by default. It's both dubious and a
nuisance to developers, since it increases irreproducibility. It's
also still what I would consider experimental.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer