Past days I wrote about a regression test suite which i used to explain
why a grsecurity-like security improvement could be good for mainline
inclusion, and also, that at least the 50% of the faults it shows on
Vanilla sources could be solved without major blocking issues (aka big
deals, whatever else).
I've released the code, so, everybody could mess it up and send me
patches with fixes, enhancements, extra features or better source
The source code is available at
An example results log dumped by it when running on a default Vanilla
kernel (no security patches, etc) can be found at:
In the forthcoming days i will try to add more tests to it, mainly
related with capabilities and such, for SELinux and LSM testing.
Also, maybe an ExecShield specific test (see  and ) and possibly a
few other tests related with BSD Jails.
I would like to have feedback about it, but it's main goal is to show
that there are still some security "faults" that affect users of Vanilla
sources that can be solved without a lot of pain and could represent a
start for those who want better security worked on many time before me
and have been ignored or just left working alone and independently.
The suite has some tests related with "toolchain" hardening, but most
stuff is kernel-related.
Hopefully it will be useful, so, enjoy.
Lorenzo Hernández García-Hierro <lor...@gnu.org> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager
Thanks, I'll take a look. Do you categorize the faults in any way?
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
There are separators to make sections of similar tests, but still not a
nifty "per-type" sections organization.
I would like to improve it and use percents and such instead of simple
"Vulnerable" and "Not vulnerable" results, so, you can have a global
idea of the current security status.
Patches are welcome, as I don't have a lot of time now (school "normal"
rhythm started this week).
Right, that's a point I forgot to talk about.
> The first makes it really hard to write generic exploits (but means you
> can do a local based attack within 2 weeks), the second means that the
> exploit technique only works for a subset of programs; in Fedora most
> (if not all) network daemons and a bunch of other things are PIE, and
> there even is an entire gentoo distribution which is entirely PIE.
Yes, the address space layout randomization (ASLR) as PaX calls it,
makes really difficult to get done the so-called ret2libc attacks, but
anyway it could be interesting to write some tests trying to achieve it,
most for fun than an useful thing, as (unexpected) results might be as
randomized as the address space can be ;D
PIE is, hopefully, also being introduced in Debian-based systems by the
Hardened Debian project.
Gentoo has the Hardened Gentoo official sub project, which is doing (and
has did) a great work around this stuff, among the deployment of other
Cheers and thanks for the comments,