From: Peter Busser <busser@m-privacy.de>
To: linux-kernel@vger.kernel.org
Cc: Arjan van de Ven <arjan@infradead.org>
Subject: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
Date: Mon, 31 Jan 2005 13:57:59 +0100 [thread overview]
Message-ID: <200501311357.59630.busser@m-privacy.de> (raw)
In-Reply-To: <200501311015.20964.arjan@infradead.org>
Hi!
> I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> it's way better than what you get in your tests (this is the
> desabotaged
> 0.9.6 version fwiw)
As you may or may not know, I am the author of PaXtest. Please tell me what a
``desabotaged'' version of PaXtest exactly is. I've never seen a
``sabotaged'' PaXtest and I'm interested in finding out who sabotaged it and
for what purpose.
Come to think of it, sabotaging a test program seems to be a rather stupid
concept. I mean, if you don't like the results, then don't run it. For me the
integrity of PaXtest is very important. I mean, who would trust a test-suite
if it produces manipulated results? Right, noone! Why would I want to write a
test-suite noone uses? Right, I wouldn't, it is a waste of time! It is boring
to write a test-suite. So it better not be a waste of time! I'm sincerely
flattered by the fact that someone as famous as you uses PaXtest.
Well, PaXtest was designed to dig up hard facts about how well a system
protects process integrity. So, if someone sabotages PaXtest and releases a
changed version, that means that person clearly has the opposite intention,
which is producing false information.
The whole concept of sabotaging PaXtest and rigging results doesn't make sense
to me. People who do that must not be happy with the results and gain
something by rigging them. But to think that it would go unnoticed...? First
of all, if you don't like the results, don't run it! Second, run kiddie mode
if you want to use PaXtest to feel warm and cozy. Third, the code is out
there, anyone can download, compile, run and dissect it. Fourth, it is only a
few lines of code per test. In other words, it is trivial to understand for
anyone who is worth his salt. Therefore anyone who would want to sabotage it,
can easily be publicly exposed and dealt with accordingly. Only stupid people
would not be able to figure this out right away or be stupid enough to do it
anyway. I honestly can't think of anyone that stupid... But then, you never
know, I've been surprised before.
Anyways, I know there are some problems with PaXtest on Fedora, caused by
PT_GNU_STACK stuff AFAIK. Unfortunately I don't have access to a Fedora
machine and therefore am not able to fix and test it. But I would love to
have PaXtest working on Fedora. So if you have it working on Fedora, feel
free to send in a patch. There are probably more people who use Fedora who
want to check their system's security, so you would really help those people.
I'm sorry to have to bother the people on this list, as you have much more
important things to do. But for me personally, the integrity of PaXtest (and
related to that, my personal integrity) matters a great deal. So I'd like to
get to the bottom of this, even if that means bothering lkml. I hope Arjan
can provide facts soon, so I can take action against this sabotage. If anyone
else on this mailing list has information on this sabotaged PaXtest matter,
then please speak up.
As a side note, I am really glad that this code goes into the kernel. It is
good to finally see some security being added to the Linux kernel. Big thumbs
up for the good work!
Groetjes,
Peter.
next parent reply other threads:[~2005-01-31 12:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200501311015.20964.arjan@infradead.org>
2005-01-31 12:57 ` Peter Busser [this message]
2005-01-31 16:41 ` Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer) Arjan van de Ven
2005-02-01 9:44 ` Peter Busser
2005-02-01 11:46 ` Ingo Molnar
2005-02-01 14:48 ` Peter Busser
2005-02-01 21:39 ` Diego Calleja
2005-02-02 0:15 ` Theodore Ts'o
2005-02-02 8:26 ` Theodore Ts'o
2005-02-02 9:55 ` Peter Busser
2005-02-02 9:35 ` Peter Busser
2005-02-02 9:52 ` Arjan van de Ven
2005-02-02 12:18 ` pageexec
2005-02-02 13:13 ` Peter Busser
2005-02-02 14:12 ` Ingo Molnar
2005-02-02 18:02 ` Olivier Galibert
2005-02-07 18:35 ` Sabotaged PaXtest John Richard Moser
2005-02-02 16:51 Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer) Ingo Molnar
2005-02-02 22:08 ` pageexec
2005-02-03 9:44 ` Ingo Molnar
2005-02-03 14:20 ` pageexec
2005-02-03 20:20 ` Ingo Molnar
2005-02-07 14:23 ` pageexec
2005-02-07 21:08 ` Ingo Molnar
2005-02-08 12:27 ` pageexec
2005-02-08 21:23 ` Ingo Molnar
2005-02-07 22:36 ` Ingo Molnar
2005-02-08 12:27 ` pageexec
2005-02-08 13:41 ` Ingo Molnar
2005-02-08 14:25 ` Julien TINNES
2005-02-08 16:56 ` Ingo Molnar
2005-02-03 13:55 ` Peter Busser
2005-02-03 14:39 ` Roman Zippel
2005-02-07 12:23 ` pageexec
2005-02-07 18:31 ` John Richard Moser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200501311357.59630.busser@m-privacy.de \
--to=busser@m-privacy.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.