exec-shield (maybe ITP kernel-patch-exec-shield)
Russell Coker
http://kerneltrap.org/node/view/913
It seems that exec-shield does 99% of what PaX does (PaX is the most desirable
feature in GRSec). Exec-shield also has support for 2.6 and looks like it
will be a standard feature in Red Hat.
I have just built a kernel from the Debian kernel-source-2.4.22 package with
exec-shield, the patch applied cleanly and it appears to work well.
Maybe we should solve the debate about grsec and standard kernels by adding
exec-shield to the standard Debian kernel source? Then people who use a
kernel.org kernel can apply the grsec patch (which will not apply to a Debian
kernel source tree), and people who use the Debian kernel source will get
exec-shield by default?
If adding exec-shield to the Debian kernel is not considered a good idea then
I'll create a kernel-patch package for exec-shield, which will still remove
the need to make grsec work with the Debian kernel.
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Ablassmeier
Hash: SHA1
On Mon, Nov 03, 2003 at 02:49:37AM +1100, Russell Coker wrote:
> It seems that exec-shield does 99% of what PaX does (PaX is the most desirable
> feature in GRSec). Exec-shield also has support for 2.6 and looks like it
> will be a standard feature in Red Hat.
I don't know exec-shield that good, but i think it may be better to not
only test it one or 2 days. So, let's look how it works for RedHat and
provide an kernel-patch package (my suggestion).
> If adding exec-shield to the Debian kernel is not considered a good idea then
> I'll create a kernel-patch package for exec-shield, which will still remove
> the need to make grsec work with the Debian kernel.
Even if it has some features which are nice, grsec provides a few more.
It would be nice to have a working grsec Patch in Debian.
bye,
- michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/pVeYEFV7g4B8rCURAvaUAKCoB0TcKQbuWZzq6U1uZnllsYODpgCfePaE
T8/Ge9Z8FL9olSRZCXcAMxg=
=Aznc
-----END PGP SIGNATURE-----
Russell Coker
> On Mon, Nov 03, 2003 at 02:49:37AM +1100, Russell Coker wrote:
> > It seems that exec-shield does 99% of what PaX does (PaX is the most
> > desirable feature in GRSec). Exec-shield also has support for 2.6 and
> > looks like it will be a standard feature in Red Hat.
>
> I don't know exec-shield that good, but i think it may be better to not
> only test it one or 2 days. So, let's look how it works for RedHat and
> provide an kernel-patch package (my suggestion).
Exec-shield is apparently in Fedora already, and has been tested extensively
inside Red Hat.
The plan is to get Linus to accept it as a feature for 2.6, but to do this we
need to get it tested more. It is being tested in Fedora, I think that we
should do the same for Debian. Getting this patch deployed on large numbers
of Debian machines is what is necessary to get it accepted by Linus.
I will make a kernel-patch package.
> > If adding exec-shield to the Debian kernel is not considered a good idea
> > then I'll create a kernel-patch package for exec-shield, which will still
> > remove the need to make grsec work with the Debian kernel.
>
> Even if it has some features which are nice, grsec provides a few more.
> It would be nice to have a working grsec Patch in Debian.
We have recently discussed grsec, and it seems that we will not get grsec as
either a default part of the Debian kernel, or as a patch that can be applied
to a Debian kernel.
PS I am employed by Red Hat, but this has no direct connection to my work.
--
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
Michael Ablassmeier
Hash: SHA1
hi Russell,
On Mon, Nov 03, 2003 at 07:45:38AM +1100, Russell Coker wrote:
> The plan is to get Linus to accept it as a feature for 2.6, but to do this we
> need to get it tested more. It is being tested in Fedora, I think that we
> should do the same for Debian. Getting this patch deployed on large numbers
> of Debian machines is what is necessary to get it accepted by Linus.
Okey.
> We have recently discussed grsec, and it seems that we will not get grsec as
> either a default part of the Debian kernel, or as a patch that can be applied
> to a Debian kernel.
Jap, i hope to see the GRSecurity options provided by "make menuconfig"
at the "Security Options" section in newer Kernels (like SELinux). Are there any
plans?
bye,
- michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/pXGFEFV7g4B8rCURAgUzAKCNbUrx2phPRP3xBdv5FPL7XwakTwCfWaCw
J8wJr0qDxH8yrUscoW/OH/A=
=/bWe
-----END PGP SIGNATURE-----
Russell Coker
> > We have recently discussed grsec, and it seems that we will not get grsec
> > as either a default part of the Debian kernel, or as a patch that can be
> > applied to a Debian kernel.
>
> Jap, i hope to see the GRSecurity options provided by "make menuconfig"
> at the "Security Options" section in newer Kernels (like SELinux). Are
> there any plans?
LSM is in the kernel.org kernels in 2.6. So if GRSec is ported to LSM then it
should be possible to get it included in a standard kernel.org kernel.
--
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
Gustavo Franco
>http://people.redhat.com/mingo/exec-shield/
>http://kerneltrap.org/node/view/913
>
>It seems that exec-shield does 99% of what PaX does (PaX is the most desirable
>feature in GRSec). Exec-shield also has support for 2.6 and looks like it
>will be a standard feature in Red Hat.
>
>
>
I believe that exec-shield doesn't 99% of what PaX does, do some tests
with paxtest[1], but
i like the idea of merge the patch with "debian kernel" in the future.
[1] = http://pageexec.virtualave.net/paxtest-0.9.4.tar.gz
Bye,
Gustavo Franco -- <str...@acm.org>
Russell Coker
> Russell Coker wrote:
> >http://people.redhat.com/mingo/exec-shield/
> >http://kerneltrap.org/node/view/913
> >
> >It seems that exec-shield does 99% of what PaX does (PaX is the most
> > desirable feature in GRSec). Exec-shield also has support for 2.6 and
> > looks like it will be a standard feature in Red Hat.
>
> I believe that exec-shield doesn't 99% of what PaX does, do some tests
> with paxtest[1], but
> i like the idea of merge the patch with "debian kernel" in the future.
I quickly checked out paxtest, there are a number of issues listed as
"Vulnerable", but I believe that some of those are necessary for full
functionality of programs such as X servers. The aim of exec-shield is to
have no need of a "chpax" type program. Also exec-shield will do even better
when we have a tool chain supporting PIE, this is already in Fedora, and will
be in Debian by gcc 3.4 if not before.
--
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
Michael Ablassmeier
> LSM is in the kernel.org kernels in 2.6. So if GRSec is ported to LSM then it
> should be possible to get it included in a standard kernel.org kernel.
hm,
http://www.grsecurity.net/lsm.php:
[...]
The amount of work required to port to LSM is very large,
and could be spent on solving real problems rather than porting
pre-existing code to a framework that is likely to change (as
they realize it is unsuitable for most purposes)
[...]
bye,
- michael
spe...@grsecurity.net
> It seems that exec-shield does 99% of what PaX does (PaX is the most desirable
> feature in GRSec). Exec-shield also has support for 2.6 and looks like it
> will be a standard feature in Red Hat.
This comment is false, unfounded, and a slap in the face of both me and
the PaX team. Apparently you've not read my presentation slides here:
http://grsecurity.net/PaX-presentation_files/frame.htm
comparing PaX to W^X and Exec-shield. Had you read it, you would
understand that Exec-shield doesn't even do 50% of what PaX does.
Exec-shield doesn't support the architectures PaX does. Exec-shield
doesn't do kernel stack randomization or non-executable kernel pages.
It can't guarantee that when a task is fully loaded, that its mappings
are W^X, even if it didn't request such mappings. It has less
randomization than PaX in all areas. HOW do you figure that exec-shield
does 99% of what PaX does? Where's your research? You have clearly
done no research whatsoever, so please spare the debian users of your
ignorant tripe.
> Maybe we should solve the debate about grsec and standard kernels by adding
> exec-shield to the standard Debian kernel source?
Go ahead and do it. I could frankly care less if your users get owned.
Give them a false sense of security by telling them that Exec-shield
is a substitute for grsecurity and PaX.
> Exec-shield is apparently in Fedora already, and has been tested extensively
> inside Red Hat.
Apparently not too extensively. Maybe you forgot a few weeks ago an
exploitable bug was fixed in Exec-shield. It had been in the code since
it was first written. Was this found by the "extensive testing" by
RedHat? No, they were just lucky that someone ran paxtest on it, and
found the 4k of writable and executable bss/data. There's another
exploitable bug in Exec-shield that I've known of for months. Maybe
you'll find it after you put it into Debian. Maybe not. This is what
happens when you make rush judgements and choose to use something based
solely on who developed it. Where's the attack model? Where's the
explanation of why the randomization is done the way it is? They don't
exist. How do you expect to make any kind of informed decision if
you have no idea what you're talking about? Why should anyone listen to
what you have to say when you've done no research? "It works for
RedHat" and "I've been using it for 2 days" is not research.
> We have recently discussed grsec, and it seems that we will not get grsec as
> either a default part of the Debian kernel, or as a patch that can be applied
> to a Debian kernel.
I've read the post regarding grsecurity and Debian, and I must say
that I've never seen a bigger bunch of lazy whiners in my life. Maybe if you
actually put a kernel hacker in charge of these patches, you'd realize
you have been whining for months for no reason. Did you ever think that
putting someone in charge who can code in C might help? Or were you
planning on relying on diff fuzz for the next couple years?
> I quickly checked out paxtest, there are a number of issues listed as
> "Vulnerable", but I believe that some of those are necessary for full
> functionality of programs such as X servers.
You believe incorrectly. You work at RedHat. You must know they've
modified X so that it works properly with Exec-shield. You must know
that PaX doesn't break X, but rather that the bug in X causing the
problem is only visible when PaX is used. Stop spreading these lies,
and blowing off the ineffectiveness of Exec-shield.
XFree86-4.3.0-elfloader-linux-non-exec-stack-v2.patch
XFree86-4.3.0-redhat-libGL-exec-shield-fixes-v2.patch
Since this is probably the fourth time I've had to correct you on making
false, unresearched statements publicly, I'm cc'ing this one to the
list, to show your users who's making their security decisions for them.
I've tried to do it in a more professional manner before by not
embarrassing you in front of your peers, however you don't seem to want
to stop this habit, which at this point I believe verges on
maliciousness.
I'm going to point out your mails to the PaX team, and they will comment
on them as well if they see fit.
Feel free to reply after you have done the research I've done on the
subject and can make a factual counter-argument.
-Brad
Theodore Ts'o
does seem to be one, major advantage of Exec-shield over PaX, and that
is that PaX takes the pathetically small, undersized space available
to userspace applications on 32-bit architectures (i.e., only 3GB) and
cuts it down into half (i.e, 1.5 GB). Given the fragmentation of how
the userspace memory has to be used (for shared libraries, mmap'ed
regious both for files and for large malloc allocations, stack,
program text), etc, this is could be a major problem for some
applications.
Randomizing the shared libraries, as PaX does, for every single
invocation, also comes with some tradeoffs. In particular this would
mean that it is incompatible with prelink, which speeds up the loading
of applications with large numbers of shared libraries. (Some
systems/distro's run "prelink -afR" out of cron to re-randomize the
layout every day, which seems to be a nice compromise.)
Discalimer: I've only read the technical docs, and haven't had time to
do a detailed examination of the sources, so if the descriptions are
wrong or misleading, some details in this note might be incorrect. I
apologize in advance if I've gotten any of the details wrong.
- Ted
Peter Busser
I am project leader of Adamantix (which was previously called Trusted Debian),
a Debian based distribution created especially to provide a high level of
security. I am also author of the paxtest program. I started writing paxtest,
to answer the question: ``Does PaX really work as advertised?''. Adding a patch
to the kernel is one thing. Proving that it does anything useful is a different
thing.
Everyone can download paxtest[1] and compile and run it. Adamantix users can
simply apt-get install it. The design and implementation of PaX[2] can be found
on the PaX site[3], where you can also download the latest version of the
patch. The paxtest test programs are small enough to be understandable for
those who have some knowledge of low-level stuff. So it should take a couple
of hours to do proper research. It is much better to gather your own facts
than to take Mr. Coker's, Mr. Spender's or my word for granted.
If exec-shield would be better than PaX, it would be a matter of reverse
patching PaX and patching in exec-shield plus a kernel compilation to switch
Adamantix to exec-shield. The reason this hasn't happened is simple,
exec-shield does not even come close. Exec-shield is also believed to be
slower than PaX (although I have not seen hard evidence to support that).
So far I have not been able to think of any technical reason why exec-shield
exists at all, let alone a reason why people would want to use it.
[1] http://mail.adamantix.org/paxtest-0.9.4.tar.gz.
[2] http://pageexec.virtualave.net/doc/
[3] http://pageexec.virtualave.net/
Groetjes,
Peter Busser
--
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/
Russell Coker
> > Maybe we should solve the debate about grsec and standard kernels by
> > adding exec-shield to the standard Debian kernel source?
>
> Go ahead and do it. I could frankly care less if your users get owned.
> Give them a false sense of security by telling them that Exec-shield
> is a substitute for grsecurity and PaX.
The problem is that we don't have anyone who has the time and ability to merge
PaX with the Debian kernel patches.
The exec-shield patch applies with the Debian patches and with LSM. I am
prepared to maintain it. Unless someone volunteers to maintain PaX support
for Debian kernels then the best available option for Debian users will be
exec-shield.
> > We have recently discussed grsec, and it seems that we will not get grsec
> > as either a default part of the Debian kernel, or as a patch that can be
> > applied to a Debian kernel.
>
> I've read the post regarding grsecurity and Debian, and I must say
> that I've never seen a bigger bunch of lazy whiners in my life. Maybe if
> you actually put a kernel hacker in charge of these patches, you'd realize
> you have been whining for months for no reason. Did you ever think that
> putting someone in charge who can code in C might help? Or were you
> planning on relying on diff fuzz for the next couple years?
Debian is not a company, we can't "put someone in charge", we rely on
volunteers. If you wish to volunteer to become a Debian developer and
maintain such things then your contributions would be welcome.
> > I quickly checked out paxtest, there are a number of issues listed as
> > "Vulnerable", but I believe that some of those are necessary for full
> > functionality of programs such as X servers.
>
> You believe incorrectly. You work at RedHat. You must know they've
> modified X so that it works properly with Exec-shield. You must know
Actually I didn't know about the details of X modifications.
The X server does some unusual things and therefore does not get protected in
a default configuration. We can get such changes into Debian, but I think
that we need the kernel patch first.
> Since this is probably the fourth time I've had to correct you on making
> false, unresearched statements publicly, I'm cc'ing this one to the
> list, to show your users who's making their security decisions for them.
Actually I don't want to make security decisions for users. This is why I
initially maintained the Debian patch package for grsec, I have promoted
OpenWall, I packaged RSBAC (but had to dump it because I didn't have the
resources to test it and no-one else was interested), and now I'm working on
SE Linux.
I want the users to have as many choices as possible.
But in the case of memory protection I think that we need to have the default
kernel offer something. Surely you will agree that adding exec-shield is
significantly better than the current situation.
> I've tried to do it in a more professional manner before by not
> embarrassing you in front of your peers, however you don't seem to want
> to stop this habit, which at this point I believe verges on
> maliciousness.
The Debian social contract specifies that we will not hide problems. The
project is based on free and open discussion.
I have no problems with matters such as this being discussed publically. If
someone believes that they can maintain a package better than an existing
Debian developer then they are welcome to join in. If you volunteer to do
PaX work for Debian then I am sure that you can make a good case for PaX in
the default Debian kernel.
If you choose not to do such work and no-one else who has appropriate skills
volunteers then I guess that exec-shield will be likely to become default in
Debian.
This is nothing personal, it's a matter of practicality.
--
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
Andrew Suffield
> There's another
> exploitable bug in Exec-shield that I've known of for months. Maybe
> you'll find it after you put it into Debian. Maybe not.
Suddenly I don't feel inclined to believe *anything* this guy says.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Manoj Srivastava
> Go ahead and do it. I could frankly care less if your users get
> owned.
> There's another exploitable bug in Exec-shield that I've known of
> for months. Maybe you'll find it after you put it into Debian.
> Maybe not. This is what happens when you make rush judgements and
> choose to use something based solely on who developed it.
> I've read the post regarding grsecurity and Debian, and I must say
> that I've never seen a bigger bunch of lazy whiners in my life.
> Maybe if you actually put a kernel hacker in charge of these
> patches, you'd realize you have been whining for months for no
> reason. Did you ever think that putting someone in charge who can
> code in C might help?
Hmm. Comparing the above rants to the emails from Russell
Coker and Ted Ts'o, I would not lend any credence to whatever the
poster is saying. Such an abysmal lack of judgement in one area
leads one to doubt that good judgement can be exercised by him.
manoj
--
He who has transcended the treacherous mire of samsara and ignorance,
who has crossed over, reached the other shore, meditating, motionless
of mind, free from uncertainty, and who is at peace by not clinging to
anything - that is what I call a brahmin. 414
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Richard Braakman
In that case it seems safer to avoid using any software you helped
to develop.
Richard Braakman
cobaco
Hash: SHA1
On 2003-11-03 17:20, Russell Coker wrote:
> On Mon, 3 Nov 2003 23:42, spe...@grsecurity.net wrote:
> > > Maybe we should solve the debate about grsec and standard kernels by
> > > adding exec-shield to the standard Debian kernel source?
> >
> > Go ahead and do it. I could frankly care less if your users get owned.
> > Give them a false sense of security by telling them that Exec-shield
> > is a substitute for grsecurity and PaX.
>
> The problem is that we don't have anyone who has the time and ability to
> merge PaX with the Debian kernel patches.
>
> The exec-shield patch applies with the Debian patches and with LSM. I am
> prepared to maintain it. Unless someone volunteers to maintain PaX
> support for Debian kernels then the best available option for Debian users
> will be exec-shield.
hm, the adamantix guys use PaX, maybe they ought to be pinged about this?
> Actually I don't want to make security decisions for users. This is why I
> initially maintained the Debian patch package for grsec, I have promoted
> OpenWall, I packaged RSBAC (but had to dump it because I didn't have the
> resources to test it and no-one else was interested), and now I'm working
> on SE Linux.
>
> I want the users to have as many choices as possible.
adamantix also uses RSBAC if I'm not mistaken
- --
Cheers, cobaco
/"\ ASCII Ribbon Campaign
\ / No proprietary formats in attachments without request
X i.e. *NO* WORD, POWERPOINT or EXCEL documents
/ \ Respect Open Standards
http://www.fsf.org/philosophy/no-word-attachments.html
http://www.goldmark.org/netrants/no-word/attach.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/p3+I5ihPJ4ZiSrsRAsCaAJ4004STNUj9aYpTNfek8VzbD7YLFgCfa+85
toqP6RWRqp2GO9KYpURkJiQ=
=glf9
-----END PGP SIGNATURE-----
Russell Coker
> > The exec-shield patch applies with the Debian patches and with LSM. I am
> > prepared to maintain it. Unless someone volunteers to maintain PaX
> > support for Debian kernels then the best available option for Debian
> > users will be exec-shield.
>
> hm, the adamantix guys use PaX, maybe they ought to be pinged about this?
Peter Busser is THE Adamantix guy. I have suggested to him that he maintain
such packages in Debian, but he does not seem interested.
> > I want the users to have as many choices as possible.
>
> adamantix also uses RSBAC if I'm not mistaken
Yes. I made some RSBAC kernel-patch packages for Debian once, but never
uploaded them because no-one was interested in helping to test them. When
no-one wants to test a package you have to assume that there is not much
interest in using it either...
--
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