|
Home > Archive > Debian Developers > July 2004 > PaX on Debian
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm interested in discussing the viability of PaX on Debian. I'd like
to discuss the changes to the base system that would be made, the costs
in terms of overhead and compatibility, the gains in terms of security,
and the mutability (elimination) of the costs.
A PaX protected base system would be best compiled ET_DYN, which can be
done by using modified spec files or a specially patched gcc to make
pies-by-default binaries. Certain things don't compile this way; and
thus would need this functionality disabled (modified spec, -fno-pic
- -nopie). This will be discussed in greater detail later.
A PaX protected base would also benefit from Stack Smash Protection,
which can be done via the gcc patch ProPolice. This imposes minimal
overhead, which will be discussed in greater detail later. It overlaps
and extends many of the protections PaX offers, but catches earlier on;
and is thus a good system to pair with PaX.
PaX is a kernel level patch, so certain kernel settings would be needed.
~ Some of the settings available in PaX are high-overhead or break
things in a way which cannot be worked around, and should thus be off.
These will be discussed later.
The costs in terms of overhead of PaX (on legacy x86 systems where it
must emulate an NX bit) and ProPolice are both very minimal. With
PAGEEXEC on hardware NX supported systems such as AMD64, there is no
measurable overhead from PaX. ProPolice brings no significant overhead;
measurements taken for StackGuard (a similar system which puts the
canaries in a different place, but is otherwise identical) are available
for this. This will be discussed in detail later.
The costs in terms of compatibility with PaX and ProPolice are also
minimal, and mutable. PaX breaks a handful of packages; but all of
these can easily be marked via the chpax and/or paxctl tools to disable
the protections that break them. ProPolice is set off by some programs
(firefox for one), which simply must be compiled without ProPolice
(-fno-stack-protector -fno-stack-protector-all).
Neither of these systems delivers a cost in terms of complexity of use
to the user; these are both 100% transparent to the user. Added
complexity in the form of configuring the PaX kernel; setting up the
binary markings for packages that break; and disabling the gcc
modifications for things that break are taken up by the distribution.
Both of these systems bring a significant security gain. ProPolice
prevents buffer overflow attacks, turning them into program crashes (DoS
attacks). Some buffer overflows, especially for buffers in structures
adjacent to function pointers or other pointers, can escape the
ProPolice logic, however; thus PaX is also needed. This will be
explained in greater detail later.
A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX
and makes a good read for this. Likewise, one for Stack Smash
Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to
look over.
Please reply and cite specific concepts you would like to discuss
further. I would rather not write up a 10 page paper by explaining all
of these at once; but if demanded, I'll do just that. Be ready to
swallow a large pill though.
- --John
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBA+Z4hDd4aOud5P8RAqTjAJ45bMPCCW04
EeDjX+NZP9m3UmC3rgCfSzt2
78Qydi7ZCMdO6vdRXuH/ZMw=
=2QiO
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jerome Warnier 2004-07-28, 6:23 pm |
| You would probably be interested in Adamantix, which used to be called
TrustedDebian.
http://www.adamantix.org/
Thought you could be interested...
--
Jerome Warnier <jwarnier@beeznest.net>
BeezNest s.a r.l.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-07-28, 6:23 pm |
| On Sun, Jul 25, 2004 at 12:57:29PM -0400, John Richard Moser wrote:
> A PaX protected base would also benefit from Stack Smash Protection,
> which can be done via the gcc patch ProPolice.
I have been flirting with SSP for months now, but the most recent
patches included with GCC do not apply cleanly. Watch for a bug
against GCC shortly with updated SSP patches.
> This imposes minimal overhead, which will be discussed in
> greater detail later. It overlaps and extends many of the protections
> PaX offers, but catches earlier on; and is thus a good system to pair
> with PaX.
I've not looked at the combination, but there is already a patched
binutils for PaX available unofficially for unstable, and I have
gcc patched with SSP (lags behind unstable releases - currently
a little out of date due to the breakages recently).
http://people.debian.org/~skx/ssp.html
> PaX is a kernel level patch, so certain kernel settings would be needed.
> ~ Some of the settings available in PaX are high-overhead or break
> things in a way which cannot be worked around, and should thus be off.
> These will be discussed later.
SSP is remarkably simple to apply and works with all packages I've
been able to test on x86.
> The costs in terms of compatibility with PaX and ProPolice are also
Probably less confusing to all if you refer to ProPolice by
its new name, SSP, exclusively.
> the protections that break them. ProPolice is set off by some programs
> (firefox for one), which simply must be compiled without ProPolice
> (-fno-stack-protector -fno-stack-protector-all).
I've not noticed this - Mozilla certainly seems fine with SSP
compilers. I've been using it on my own unstable boxes for some
time. What, specifically, breaks?
> Both of these systems bring a significant security gain. ProPolice
> prevents buffer overflow attacks, turning them into program crashes (DoS
> attacks). Some buffer overflows, especially for buffers in structures
> adjacent to function pointers or other pointers, can escape the
> ProPolice logic, however; thus PaX is also needed. This will be
> explained in greater detail later.
I've keep a running log of all the security holes I've discovered,
and more recently those by other members and a note as to whether
SSP protects against them.
This is available here:
http://shellcode.org/Advisories/
As you can see many, but not all, attacks are protected against
with SSP. SELinux would almost certainly do better ... (Because
the things that aren't protected against are failure to drop
privileges when using popen/system - SELinux could protect against
this, SSP cannot).
> Please reply and cite specific concepts you would like to discuss
> further. I would rather not write up a 10 page paper by explaining all
> of these at once; but if demanded, I'll do just that. Be ready to
> swallow a large pill though.
Looking forward to it already!
Steve
--
# The Debian Security Audit Project.
http://www.debian.org/security/audit
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Kemp wrote:
| On Sun, Jul 25, 2004 at 12:57:29PM -0400, John Richard Moser wrote:
|
|
|>A PaX protected base would also benefit from Stack Smash Protection,
|>which can be done via the gcc patch ProPolice.
|
|
| I have been flirting with SSP for months now, but the most recent
| patches included with GCC do not apply cleanly. Watch for a bug
| against GCC shortly with updated SSP patches.
|
Yeah I think on 3.3.4 on Gentoo has SSP
|
|> This imposes minimal overhead, which will be discussed in
|>greater detail later. It overlaps and extends many of the protections
|>PaX offers, but catches earlier on; and is thus a good system to pair
|>with PaX.
|
|
| I've not looked at the combination, but there is already a patched
| binutils for PaX available unofficially for unstable, and I have
| gcc patched with SSP (lags behind unstable releases - currently
| a little out of date due to the breakages recently).
|
The binutils adds the header field needed for the PaX flags for paxctl.
~ This is important, because chpax uses an "unused" area in the header,
which is depricated. Also, tools like strip will zero the chpax flags,
making them extremely volitile.
|
| http://people.debian.org/~skx/ssp.html
|
|
|>PaX is a kernel level patch, so certain kernel settings would be needed.
|>~ Some of the settings available in PaX are high-overhead or break
|>things in a way which cannot be worked around, and should thus be off.
|>These will be discussed later.
|
|
| SSP is remarkably simple to apply and works with all packages I've
| been able to test on x86.
|
Firefox sets off SSP itself on load.
|
|>The costs in terms of compatibility with PaX and ProPolice are also
|
|
| Probably less confusing to all if you refer to ProPolice by
| its new name, SSP, exclusively.
|
"Stack Smash Protection" is the new name of ProPolice? o_o Thought
that was the name of the concept.
|
|>the protections that break them. ProPolice is set off by some programs
|>(firefox for one), which simply must be compiled without ProPolice
|>(-fno-stack-protector -fno-stack-protector-all).
|
|
| I've not noticed this - Mozilla certainly seems fine with SSP
| compilers. I've been using it on my own unstable boxes for some
| time. What, specifically, breaks?
|
Not sure. I'm going by what I've been told by the Gentoo devs; I'm a
Hardened Gentoo user.
|
|>Both of these systems bring a significant security gain. ProPolice
|>prevents buffer overflow attacks, turning them into program crashes (DoS
|>attacks). Some buffer overflows, especially for buffers in structures
|>adjacent to function pointers or other pointers, can escape the
|>ProPolice logic, however; thus PaX is also needed. This will be
|>explained in greater detail later.
|
|
| I've keep a running log of all the security holes I've discovered,
| and more recently those by other members and a note as to whether
| SSP protects against them.
|
| This is available here:
|
| http://shellcode.org/Advisories/
|
cool.
| As you can see many, but not all, attacks are protected against
| with SSP. SELinux would almost certainly do better ... (Because
| the things that aren't protected against are failure to drop
| privileges when using popen/system - SELinux could protect against
| this, SSP cannot).
|
SELinux and SSP do two different things. SSP prevents the program from
being exploited; SELinux contains the exploit.
PaX also aims to prevent the program from being exploited.
|
|>Please reply and cite specific concepts you would like to discuss
|>further. I would rather not write up a 10 page paper by explaining all
|>of these at once; but if demanded, I'll do just that. Be ready to
|>swallow a large pill though.
|
|
| Looking forward to it already!
|
| Steve
| --
| # The Debian Security Audit Project.
| http://www.debian.org/security/audit
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBA/tFhDd4aOud5P8RAibQAJ9ybg/PKG6OslYh4EbFKBRVP/N+zQCeOu8E
TYorBgIvKO35LMneplcdjbs=
=BbdL
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jerome Warnier wrote:
| You would probably be interested in Adamantix, which used to be called
| TrustedDebian.
| http://www.adamantix.org/
|
Not interested.
I know what Adamantix is. It is a full blown secured distribution which
tacks on ACL systems and other things. This creates a non-transparent,
complex environment.
I'm suggesting that the most transparent and easy to implement features
of systems such as Adamantix and Hardened Gentoo be used on the base of
Debian, because they offer great security gains with little overhead and
no added complexity to the end user.
Think of it this way: Adamantix prevents really really determined
crackers from breaking into your system and doing damage; and a simple
PaX/pie/ssp base prevents immature 12 year old skr1pt33k1dd13z h4x0rz
who think they're l33t from making Sasser or MSBlast type worms that
actually work on these systems.
On the whole, nobody cares about you. You don't need a USB stick with
your 4096 bit RSA key to boot your drive. You don't need 5 extra
passwords for your SELinux roles. You don't need to mess with Prelude.
~ There are still situations where things are made just to spread,
regardless of who you are or what you do. You need protection; and an
antivirus program isn't ideal for this.
| Thought you could be interested...
Thanks. Seen it though, not interested. It's way too excessive for
just home users.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBA/ zMhDd4aOud5P8RAlf1AJ9euGjUBSA6bBmcfQKqfG
1sADmjsQCfe5IL
2s4rKZV1E5V/ElOuBu38u3s=
=zI3d
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-07-28, 6:23 pm |
| On Sun, Jul 25, 2004 at 02:26:15PM -0400, John Richard Moser wrote:
> | I have been flirting with SSP for months now, but the most recent
> | patches included with GCC do not apply cleanly. Watch for a bug
> | against GCC shortly with updated SSP patches.
> |
>
> Yeah I think on 3.3.4 on Gentoo has SSP
It does.
> The binutils adds the header field needed for the PaX flags for paxctl.
> ~ This is important, because chpax uses an "unused" area in the header,
> which is depricated. Also, tools like strip will zero the chpax flags,
> making them extremely volitile.
Shouldn't strip be updated to ignore this 'unused' field, or
would it be more sensible to set aside a real area for the flag? ELF
is simple to update with new sections and maybe adding support for
the runtime loader/linker would be more future proof..
> | SSP is remarkably simple to apply and works with all packages I've
> | been able to test on x86.
> |
>
> Firefox sets off SSP itself on load.
When you say 'sets of' do you mean disable? I find that unlikely,
as it's not the kind of thing that can be disabled when all the
canary checking code is incorporated into the binary...
> "Stack Smash Protection" is the new name of ProPolice? o_o Thought
> that was the name of the concept.
SSP is the name for one implementation of stack smashing protection
which was previously known as ProPolice.
It's available from IBM at the following URL:
http://www.trl.ibm.com/projects/security/ssp/
> | I've not noticed this - Mozilla certainly seems fine with SSP
> | compilers. I've been using it on my own unstable boxes for some
> | time. What, specifically, breaks?
> |
>
> Not sure. I'm going by what I've been told by the Gentoo devs; I'm a
> Hardened Gentoo user.
But interested in Debian?
> SELinux and SSP do two different things. SSP prevents the program from
> being exploited; SELinux contains the exploit.
That's a simplistic explaination .. but it's not too far from
the truth ;)
> PaX also aims to prevent the program from being exploited.
The randomization is an interesting technique and it seems
sufficiently simple concept that it would be interesting to
see how well it works.
Steve
--
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Kemp wrote:
| On Sun, Jul 25, 2004 at 02:26:15PM -0400, John Richard Moser wrote:
|
|
|>| I have been flirting with SSP for months now, but the most recent
|>| patches included with GCC do not apply cleanly. Watch for a bug
|>| against GCC shortly with updated SSP patches.
|>|
|>
|>Yeah I think on 3.3.4 on Gentoo has SSP
|
|
| It does.
|
|
|>The binutils adds the header field needed for the PaX flags for paxctl.
|>~ This is important, because chpax uses an "unused" area in the header,
|>which is depricated. Also, tools like strip will zero the chpax flags,
|>making them extremely volitile.
|
|
| Shouldn't strip be updated to ignore this 'unused' field, or
| would it be more sensible to set aside a real area for the flag?
Read again
"The binutils adds the header field needed for the PaX flags for paxctl"
| ELF
| is simple to update with new sections and maybe adding support for
| the runtime loader/linker would be more future proof..
|
|
|>| SSP is remarkably simple to apply and works with all packages I've
|>| been able to test on x86.
|>|
|>
|>Firefox sets off SSP itself on load.
|
|
| When you say 'sets of' do you mean disable? I find that unlikely,
| as it's not the kind of thing that can be disabled when all the
| canary checking code is incorporated into the binary...
|
I mean firefox DIES due to a segfault. SSP segfaults when it detects an
overflow.
If you know something we don't, I think the Hardened Gentoo team would
like to know
|
|>"Stack Smash Protection" is the new name of ProPolice? o_o Thought
|>that was the name of the concept.
|
|
| SSP is the name for one implementation of stack smashing protection
| which was previously known as ProPolice.
| It's available from IBM at the following URL:
|
| http://www.trl.ibm.com/projects/security/ssp/
|
|
|>| I've not noticed this - Mozilla certainly seems fine with SSP
|>| compilers. I've been using it on my own unstable boxes for some
|>| time. What, specifically, breaks?
|>|
|>
|>Not sure. I'm going by what I've been told by the Gentoo devs; I'm a
|>Hardened Gentoo user.
|
|
| But interested in Debian?
|
I'm interested in getting transparent (i.e. no extra passwords, no extra
user configuration, no extra user hassle) security enhancements like PaX
and SSP into the base distributions of regular Linux distros, as I
believe they are appropriate for machines not operating in a secure
environment. I've went at Mandrake and SuSE too, but they ignore me.
Machines in a secure environment will be interested in Adamantix or full
Hardened Gentoo, or whatever Red Hat Enterprise Server or whatever it's
called that has 10000 security features comes out. This is because they
will host sensitive data, and probably be faced with more direct attacks.
Machines *NOT* in a secure environment, however, will benefit from the
simpler, transparent subset of features that a secure system provides.
They won't be up for containing a security breach; but they'll be safely
protected from any weird Sasser or MSBlast type worms and other annoyances.
As it stands now, every little security hole in MS RPC or other system
services on Windows needs a patch to fix it. Before these patches come
out, millions of machines get infected with worms that use the security
holes to get into the machines.
Linux is not immune; if we had 98% of the market share, every little
hole in everything would result in millions of desktop users getting
flooded with these things too. There's no harm in BLOCKING THIS CRAP
from ever happening. It's not going to bug the users with 5000 extra
passwords, it's not going to require a USB stick with an RSA key on it
to boot, and it's not going to eat up 50% of your CPU's processing power.
Furthermore, using these systems NOW will bring them further into the
field, exposing more attacks that get around them. There is no security
in obscurity; we're simply faced with what we can and can't stop, and
from this we fix things so we CAN stop them, or we tell everyone when
there's a SEVERE security issue that we can't deflect.
|
|>SELinux and SSP do two different things. SSP prevents the program from
|>being exploited; SELinux contains the exploit.
|
|
| That's a simplistic explaination .. but it's not too far from
| the truth ;)
|
Hey. Simple is good.
|
|>PaX also aims to prevent the program from being exploited.
|
|
| The randomization is an interesting technique and it seems
| sufficiently simple concept that it would be interesting to
| see how well it works.
|
Did you read the wikipedia article and the docs? :P
The restriction of mprotect() is also an interesting technique, as it
lets you force programs to listen to you. In fact, I've had issues with
things like Flash and Java plug-ins demanding an executable stack, and
I've simply used execstack -c to turn that off. PaX can emulate
trampolines, which is why the executable stack is needed in the first
place; and these libraries DON'T actually have trampolines in them, so I
don't even need emutramp enabled without an executable stack. It seems
that alsalib did need emutramp (so I disabled the executable stack and
enabled emutramp); but that's going to be fixed soon.
An executable stack is a quick way to make your programs 100%
exploitable; there's no protection offered once the stack is PROT_EXEC.
The randomization is more of a probabilistic approach than a guarantee.
~ You'll probably want to combine it with the obscurity patch:
http://cr0.org/pax-obscure/
It also breaks wine in a probablistic percentage of the time The
devs of Wine have gotten around this: Make sure to paxctl -x the wine
binary, and its preloader will load the .exe before other libs are
mmap()ed in. They're great people.
| Steve
| --
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBDeehDd4aOud5P8RAsywAKCOivQMWl7f
2d3K1DhUD+MbUZmLYgCZAbWP
u0VahfMo6HEnoSAVKXbhV/U=
=TDQd
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Kemp wrote:
[...]
|>Firefox sets off SSP itself on load.
|
|
| When you say 'sets of' do you mean disable? I find that unlikely,
| as it's not the kind of thing that can be disabled when all the
| canary checking code is incorporated into the binary...
|
|
http://bugs.gentoo.org/show_bug.cgi?id=45671
Ok so not on load, more like on competant use.
|>"Stack Smash Protection" is the new name of ProPolice? o_o Thought
|>that was the name of the concept.
|
|
| SSP is the name for one implementation of stack smashing protection
| which was previously known as ProPolice.
| It's available from IBM at the following URL:
|
| http://www.trl.ibm.com/projects/security/ssp/
|
|
[...]
|
| Steve
| --
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBDlRhDd4aOud5P8RAtNhAJ9aXKEKyl0w
8oNk64NKXQTVJ54VawCfdCQV
YLGFa1P8V2hn0F8wClDmkS0=
=KIyO
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andres Salomon 2004-07-28, 6:23 pm |
| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm interested in discussing the viability of PaX on Debian. I'd like
> to discuss the changes to the base system that would be made, the costs
> in terms of overhead and compatibility, the gains in terms of security,
> and the mutability (elimination) of the costs.
>
I think debian-kernel would be a better place to discuss this (at least,
the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
been very pleased with it. I would love to be able to include it in
debian 2.6 kernels, but we need to make sure that:
a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
I've also heard reports of various grsec problems on 2.6; I don't know how
many of those are PAX issues)
b) it doesn't introduce significant overhead (we need *real*, up-to-date
benchmarks here); i'm told that there have been optimizations to PAGEEXEC
that make it comparable in speed to SEGMEXEC, but I haven't tried it.
c) it doesn't introduce limitations (SEGMEXEC isn't an option, for
example, since it splits the process address space in half, and can't be
turned off to reclaim address space) that aren't easily disabled.
> A PaX protected base system would be best compiled
ET_DYN, which can be
> done by using modified spec files or a specially patched gcc to make
> pies-by-default binaries. Certain things don't compile this way; and
> thus would need this functionality disabled (modified spec, -fno-pic -
> -nopie). This will be discussed in greater detail later.
>
> A PaX protected base would also benefit from Stack Smash Protection,
> which can be done via the gcc patch ProPolice. This imposes minimal
> overhead, which will be discussed in greater detail later. It overlaps
> and extends many of the protections PaX offers, but catches earlier on;
> and is thus a good system to pair with PaX.
>
I haven't tried SSP yet, but I've heard good things about it. I'll have
to do research on it when I have more free time.
> PaX is a kernel level
patch, so certain kernel settings would be needed.
> ~ Some of the settings available in PaX are high-overhead or break
> things in a way which cannot be worked around, and should thus be off.
> These will be discussed later.
>
Yes. We cannot have major regressions in the kernel, with the
introduction of something like this.
> The costs in terms of overhead of PaX (on legacy x86 systems where it
> must emulate an NX bit) and ProPolice are both very minimal. With
> PAGEEXEC on hardware NX supported systems such as AMD64, there is no
> measurable overhead from PaX. ProPolice brings no significant overhead;
> measurements taken for StackGuard (a similar system which puts the
> canaries in a different place, but is otherwise identical) are available
> for this. This will be discussed in detail later.
>
Do you have any real benchmarks showing exactly how much overheard is
added on common hardware (i386, powerpc, and amd64)? I'm merely
interested in 2.6.
> The costs in terms of compatibility with PaX and ProPolice are also
> minimal, and mutable. PaX breaks a handful of packages; but all of
> these can easily be marked via the chpax and/or paxctl tools to disable
> the protections that break them. ProPolice is set off by some programs
> (firefox for one), which simply must be compiled without ProPolice
> (-fno-stack-protector -fno-stack-protector-all).
In terms of the packages that are known to break, how many of them are
fixable? Do you have a list of the packages that break?
>
> Neither of these systems delivers a cost in terms of complexity of use
> to the user; these are both 100% transparent to the user. Added
I disagree with that; we don't know how many 3rd-party binary apps PAX
will kill. However, I'm not overly concerned with that right now, as it's
the sort of thing that we won't be able to measure without actually having
people using PAX.
> complexity in the form of configuring the PaX kernel; setting up the
> binary markings for packages that break; and disabling the gcc
> modifications for things that break are taken up by the distribution.
>
> Both of these systems bring a significant security gain. ProPolice
Agreed. I've seen PAX/grsec stop numerous attacks on our boxes.
> prevents buffer overflow
attacks, turning them into program crashes (DoS
> attacks). Some buffer overflows, especially for buffers in structures
> adjacent to function pointers or other pointers, can escape the
> ProPolice logic, however; thus PaX is also needed. This will be
> explained in greater detail later.
>
> A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX
> and makes a good read for this. Likewise, one for Stack Smash
> Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to
> look over.
>
> Please reply and cite specific concepts you would like to discuss
> further. I would rather not write up a 10 page paper by explaining all
> of these at once; but if demanded, I'll do just that. Be ready to
> swallow a large pill though.
>
> - --John
>
> - --
> All content of all messages exchanged herein are left in the Public
> Domain, unless otherwise explicitely stated.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBA+Z4hDd4aOud5P8RAqTjAJ45bMPCCW04
EeDjX+NZP9m3UmC3rgCfSzt2
> 78Qydi7ZCMdO6vdRXuH/ZMw=
> =2QiO
> -----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
.. . . .thunderbird is being weird. It's giving me > where >> should be,
and >> wehre > should be. EH.
Andres Salomon wrote:
| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
|
|
| I'm interested in discussing the viability of PaX on Debian. I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
|
|
|
|> I think debian-kernel would be a better place to discuss this (at least,
|> the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
|> been very pleased with it. I would love to be able to include it in
|> debian 2.6 kernels, but we need to make sure that:
|
|> a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
|> I've also heard reports of various grsec problems on 2.6; I don't
know how
|> many of those are PAX issues)
PaX is stable, grsecurity I can't comment on.
I'm only suggesting PaX. PaX is interestingly enough hosted by
grsecurity; PaX' previous hosting cost money.
http://pax.grsecurity.net/
|> b) it doesn't introduce significant overhead (we need *real*, up-to-date
|> benchmarks here); i'm told that there have been optimizations to PAGEEXEC
|> that make it comparable in speed to SEGMEXEC, but I haven't tried it.
Anything that gives you an executable area existing above data will lose
the PAGEEXEC speedup. This speedup is the same kind of thing Exec
Shield does; except that when data exists in the code segment, it falls
back to old PAGEEXEC rather than becoming executable like Exec Shield does.
On 64 bit (amd64 for example) and other hardware NX supporting
processors, there will be *no* overhead imposed by PAGEEXEC.
|> c) it doesn't introduce limitations (SEGMEXEC isn't an option, for
|> example, since it splits the process address space in half, and can't be
|> turned off to reclaim address space) that aren't easily disabled.
I can give a patch that will allow pax_defaultnx={segm|page}exec on the
kernel command line.
Also, paxctl/chpax can mark binaries to disable segmexec/pageexec.
|
|
|
| A PaX protected base system would be best compiled
|
|> ET_DYN, which can be
|
| done by using modified spec files or a specially patched gcc to make
| pies-by-default binaries. Certain things don't compile this way; and
| thus would need this functionality disabled (modified spec, -fno-pic -
| -nopie). This will be discussed in greater detail later.
|
| A PaX protected base would also benefit from Stack Smash Protection,
| which can be done via the gcc patch ProPolice. This imposes minimal
| overhead, which will be discussed in greater detail later. It overlaps
| and extends many of the protections PaX offers, but catches earlier on;
| and is thus a good system to pair with PaX.
|
|
|
|> I haven't tried SSP yet, but I've heard good things about it. I'll have
|> to do research on it when I have more free time.
|
http://en.wikipedia.org/wiki/Stack_smash_protection (same as the
ProPolice article, which is a redirect) shows how this works.
|
|
| PaX is a kernel level
|
|> patch, so certain kernel settings would be needed.
|
| ~ Some of the settings available in PaX are high-overhead or break
| things in a way which cannot be worked around, and should thus be off.
| These will be discussed later.
|
|
|
|> Yes. We cannot have major regressions in the kernel, with the
|> introduction of something like this.
|
|
There will be breakage in places; but I can point out the settings that
cause permenant breakage. All of the other breakage will be solvable
simply by using paxctl/chpax to mark the affected binaries. These can
be distributed marked up properly in their .deb packages.
|
| The costs in terms of overhead of PaX (on legacy x86 systems where it
| must emulate an NX bit) and ProPolice are both very minimal. With
| PAGEEXEC on hardware NX supported systems such as AMD64, there is no
| measurable overhead from PaX. ProPolice brings no significant overhead;
| measurements taken for StackGuard (a similar system which puts the
| canaries in a different place, but is otherwise identical) are available
| for this. This will be discussed in detail later.
|
|
|
|> Do you have any real benchmarks showing exactly how much overheard is
|> added on common hardware (i386, powerpc, and amd64)? I'm merely
|> interested in 2.6.
|
No real benchmarks. I did a SEGMEXEC test on 2.6 that showed a scalar
0.6% overhead from full PaX (aslr and SEGMEXEC emulation), by compiling
the same kernel twice:
1. Compile a kernel, install it
2. Patch the source tree with PaX, and repete 1
3. `make clean` in the original source tree
4. `make menuconfig` in the original source tree to regenerate
dependency data
5. Reboot into the non-PaX kernel
6. `time -p make all` in the source tree (makes bzImage and modules)
7. Repete steps 3 through 6 with the PaX kernel
8. Divide the time gathered in the PaX kernel test into the time
gathered in the non-pax test (noPaX/PaX) and subtract 1
This gives how much excess overhead is incurred by PaX (the other way
round gives how much overhead is saved by removing PaX).
I recall that my highest difference was the 0.6% (I believe 0.67% was
about it) "Realtime" measurment; the other two (user and system) were
significantly lower in proportional difference.
Thus, I can say with WEAK CONFIDENCE that full PaX with SEGMEXEC based
on a 32 bit Athlon XP supplies about 0.7% (I tend to say 0.6% off the
record) scalar overhead. We'll be safe and call this a <1% scalar
overhead, which assumedly will hold true because it sholud be
significantly higher than the overhead PaX incurs.
I say that 1% is "Significantly higher" assuming that the large number
of operations performed in the course of a kernel compile narrow the
variation down to a very small area, and thus allow me to theoretically
claim high confidence. I claim weak confidence because I don't have a
lot of numbers behind me to back this up.
On amd64, PAGEEXEC won't add the emulation costs. You can assume less
overhead with PAGEEXEC safely; but I will for my own sake assume EQUAL
OR LESS overhead. I may still be wrong, but it should hold true. Do a
test yourself, is all I can suggest.
I can't comment on PowerPC.
|
|
| The costs in terms of compatibility with PaX and ProPolice are also
| minimal, and mutable. PaX breaks a handful of packages; but all of
| these can easily be marked via the chpax and/or paxctl tools to disable
| the protections that break them. ProPolice is set off by some programs
| (firefox for one), which simply must be compiled without ProPolice
| (-fno-stack-protector -fno-stack-protector-all).
|
|
|> In terms of the packages that are known to break, how many of them are
|> fixable? Do you have a list of the packages that break?
|
|
Of course. Check Gentoo Bug #40665 at
http://bugs.gentoo.org/show_bug.cgi?id=40665 for the init.d script that
is used in Gentoo to mark up binaries for PaX compatibility. There is
an attachment titled conf.d/chpax that is updated when I or someone else
finds an app that breaks and brings the fixes. This list is currently
spawned from experiences on x86 CPUs and does not reflect other
architectures. Do your own tests before committing your work.
Of all apps that are known to break, 100% are fixable thusfar. The
current list at the time of this writing is
http://bugs.gentoo.org/attachment.c...971&action=view in the form
of a configuration file to the chpax init.d script.
In the worst case, PaX can usually be fully disabled for a binary via
paxctl -pemrxs or chpax -pemrxs. Only paxctl should be relied on; but
binary-only packages such as Yahoo Messenger or Java may come in a form
without the new PT_PAX_FLAGS ELF header fields. In these cases, you'll
need to fall back to chpax and the EI_PAX, which is both depricated and
non-integral (i.e. strip will zero EI_PAX out on some systems or such,
removing the markings).
| Neither of these systems delivers a cost in terms of complexity of use
| to the user; these are both 100% transparent to the user. Added
|
|
|> I disagree with that; we don't know how many 3rd-party binary apps PAX
|> will kill. However, I'm not overly concerned with that right now, as
it's
|> the sort of thing that we won't be able to measure without actually
having
|> people using PAX.
|
Alright, you win. Third party .deb packages will indeed come unmarked.
~ Of course, once the vendor realizes you're using PaX in your default
base system, he may or may not begin marking these. Also, you could
feed dpkg a bit of a clue about known 3rd party apps that need markings,
if it really becomes a problem.
Very little breaks, but it's entirely possible that 3rd party packages
will fall into that category.
|
|
| complexity in the form of configuring the PaX kernel; setting up the
| binary markings for packages that break; and disabling the gcc
| modifications for things that break are taken up by the distribution.
|
| Both of these systems bring a significant security gain. ProPolice
|
|
|> Agreed. I've seen PAX/grsec stop numerous attacks on our boxes.
|
|
Just imagine if we had Sasser to deal with -.- "numerous" would be
quite high.
|
| prevents buffer overflow
|
|> attacks, turning them into program crashes (DoS
|
| attacks). Some buffer overflows, especially for buffers in structures
| adjacent to function pointers or other pointers, can escape the
| ProPolice logic, however; thus PaX is also needed. This will be
| explained in greater detail later.
|
| A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX
| and makes a good read for this. Likewise, one for Stack Smash
| Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to
| look over.
|
| Please reply and cite specific concepts you would like to discuss
| further. I would rather not write up a 10 page paper by explaining all
| of these at once; but if demanded, I'll do just that. Be ready to
| swallow a large pill though.
|
| --John
|
| --
| All content of all messages exchanged herein are left in the Public
| Domain, unless otherwise explicitely stated.
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBEcThDd4aOud5P8RAop8AJwKjqtWEHwx
EYhyMt5+kEognqQPwQCcDmwM
Wbm/cpCwQV934i8d6hdoj8o=
=aRcW
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-07-28, 6:23 pm |
| On Mon, 26 Jul 2004 02:57, John Richard Moser <nigelenki@comcast.net> wrote:
> I'm interested in discussing the viability of PaX on Debian. I'd like
> to discuss the changes to the base system that would be made, the costs
> in terms of overhead and compatibility, the gains in terms of security,
> and the mutability (elimination) of the costs.
Before we can even start thinking about PaX on Debian we need to find a
maintainer for the kernel patch who will package new versions of the patch
which apply to the Debian kernel source tree. We have had a few flame-wars
about this in the past which have had no positive result because no-one has
volunteered to do the kernel coding work.
> A PaX protected base system would be best compiled ET_DYN, which can be
> done by using modified spec files or a specially patched gcc to make
> pies-by-default binaries. Certain things don't compile this way; and
> thus would need this functionality disabled (modified spec, -fno-pic
> -nopie). This will be discussed in greater detail later.
Debian does not use spec files, spec files are for RPM based distributions.
It would have to be a modification to debian/rules in all the packages, or a
modification to gcc and/or dpkg-buildpackage.
> A PaX protected base would also benefit from Stack Smash Protection,
> which can be done via the gcc patch ProPolice. This imposes minimal
> overhead, which will be discussed in greater detail later. It overlaps
> and extends many of the protections PaX offers, but catches earlier on;
> and is thus a good system to pair with PaX.
We have recently discussed this on at least one of the lists you posted to.
The end result of the discussion is that GCC is getting another SSP type
technology known as "mudflap". Mudflap depends on some major new features of
GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
Debian GCC people don't want to merge in other patches which have no apparent
chance of being included upstream.
--
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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Russell Coker wrote:
| On Mon, 26 Jul 2004 02:57, John Richard Moser <nigelenki@comcast.net>
wrote:
|
|>I'm interested in discussing the viability of PaX on Debian. I'd like
|>to discuss the changes to the base system that would be made, the costs
|>in terms of overhead and compatibility, the gains in terms of security,
|>and the mutability (elimination) of the costs.
|
|
| Before we can even start thinking about PaX on Debian we need to find a
| maintainer for the kernel patch who will package new versions of the
patch
| which apply to the Debian kernel source tree. We have had a few
flame-wars
| about this in the past which have had no positive result because
no-one has
| volunteered to do the kernel coding work.
|
|
Are you talking PaX or grsecurity? PaX is significantly less invasive
than grsecurity. There will still be issues, of course.
Where would I see debian's 2.6.7 source tree? I'm not a deb user,
remember, so I'll need a tarball or something.
|>A PaX protected base system would be best compiled ET_DYN, which can be
|>done by using modified spec files or a specially patched gcc to make
|>pies-by-default binaries. Certain things don't compile this way; and
|>thus would need this functionality disabled (modified spec, -fno-pic
|>-nopie). This will be discussed in greater detail later.
|
|
| Debian does not use spec files, spec files are for RPM based
distributions.
| It would have to be a modification to debian/rules in all the
packages, or a
| modification to gcc and/or dpkg-buildpackage.
|
No, gcc spec files, that tell gcc how to behave. This was used on
gentoo to mess with gcc's default behavior for a while.
try the command:
gcc -dumpspecs
Also try looking at:
/usr/lib/gcc-lib/<Target>/<version>/specs
You'd need to fudge that file I believe to alter gcc's default behavior.
~ This was done by the Hardened Gentoo project, but was dropped in favor
of a gcc patch. Either way, it's been done before.
|
|>A PaX protected base would also benefit from Stack Smash Protection,
|>which can be done via the gcc patch ProPolice. This imposes minimal
|>overhead, which will be discussed in greater detail later. It overlaps
|>and extends many of the protections PaX offers, but catches earlier on;
|>and is thus a good system to pair with PaX.
|
|
| We have recently discussed this on at least one of the lists you
posted to.
| The end result of the discussion is that GCC is getting another SSP type
| technology known as "mudflap". Mudflap depends on some major new
features of
| GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
| Debian GCC people don't want to merge in other patches which have no
apparent
| chance of being included upstream.
|
Then don't use ProPolice/SSP for now.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBH75hDd4aOud5P8RAvATAJ4p+Kfut/en14Dwenv7UDez86O2KgCeIJcG
kP7jnKii7eDGHwiO39MpJjI=
=P617
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-07-28, 6:23 pm |
| On Mon, 26 Jul 2004 13:48, John Richard Moser <nigelenki@comcast.net> wrote:
> | Before we can even start thinking about PaX on Debian we need to find a
> | maintainer for the kernel patch who will package new versions of the
> | patch which apply to the Debian kernel source tree. We have had a few
>
> Are you talking PaX or grsecurity? PaX is significantly less invasive
> than grsecurity. There will still be issues, of course.
PaX. AFAIK the only PaX kernel-patch package in Debian is the Adamantix
kernel source, which has RSBAC and a bunch of other stuff, and the GRSec
patch. Neither of them apply to the Debian kernel source tree.
> Where would I see debian's 2.6.7 source tree? I'm not a deb user,
> remember, so I'll need a tarball or something.
http://ftp.debian.org/debian/pool/main/k/
> | We have recently discussed this on at least one of the lists you
> | posted to.
>
> | The end result of the discussion is that GCC is getting another SSP type
> | technology known as "mudflap". Mudflap depends on some major new
> | features of
> | GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
> | Debian GCC people don't want to merge in other patches which have no
> | apparent chance of being included upstream.
>
> Then don't use ProPolice/SSP for now.
That seems to be what will happen. I'd rather see SSP included sooner, but I
guess it won't happen.
--
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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Russell Coker wrote:
| On Mon, 26 Jul 2004 13:48, John Richard Moser <nigelenki@comcast.net>
wrote:
|
|>| Before we can even start thinking about PaX on Debian we need to find a
|>| maintainer for the kernel patch who will package new versions of the
|>| patch which apply to the Debian kernel source tree. We have had a few
|>
|>Are you talking PaX or grsecurity? PaX is significantly less invasive
|>than grsecurity. There will still be issues, of course.
|
|
| PaX. AFAIK the only PaX kernel-patch package in Debian is the Adamantix
| kernel source, which has RSBAC and a bunch of other stuff, and the GRSec
| patch. Neither of them apply to the Debian kernel source tree.
|
|
I'm pretty much proposing that all your sources include PaX; your
binaries can have it compiled out. I've got a working PaX patch for
2.6.7-ck* It was only a 1 miss issue. I'll see if Deb sources are
kind or if they rape my XXX. . .
|>Where would I see debian's 2.6.7 source tree? I'm not a deb user,
|>remember, so I'll need a tarball or something.
|
|
| http://ftp.debian.org/debian/pool/main/k/
|
OK how the hell does this work? What's this supposed to apply to?
kernel-source-2.6.7_2.6.7-3_all.deb ?
ahh, 2.6.7 + kernel-source-2.6.7_2.6.7-3.diff.gz
I'll get on this right away. . . . I don't really see anything that
stands out in my brain, so I think PaX will apply pretty cleanly to this.
icebox linux-2.6.7-deb # patch -p1 < ../kernel-source-2.6.7_2.6.7-3.diff
patching file debian/changelog
patching file debian/control
patching file debian/apply
patching file debian/patches/drivers-sb-pnp_unregister.dpatch
patching file debian/patches/fs-cramfs-constify.dpatch
patching file debian/patches/fs-jfs-compile.dpatch
patching file debian/patches/netlink-macro-fixups.dpatch
patching file debian/patches/acpi-typo.dpatch
patching file debian/patches/envp.dpatch
patching file debian/patches/include-linux-mca.h-fixups.dpatch
patching file debian/patches/x86-i486_emu.dpatch
patching file debian/patches/doc-post_halloween.dpatch
patching file debian/patches/fs-isofs-acorn.dpatch
patching file debian/patches/drivers-scsi-advansys-dma_api.dpatch
patching file debian/patches/modular-ide-pnp.dpatch
patching file debian/patches/include-missing-includes.dpatch
patching file debian/patches/include-thread_info-ifdefs.dpatch
patching file debian/patches/modular-ide.dpatch
patching file debian/patches/fs-isofs-dont-check-period.dpatch
patching file
debian/patches/dont-dereference-netdev.name-before-register_netdev.dpatch
patching file debian/patches/drivers-net-tg3-readd.dpatch
patching file debian/patches/DPATCH
patching file debian/patches/drivers-usb-net-pegasus-startstop_queue.dpatch
patching file debian/patches/drivers-net-via_rhine-avoid_bitfield.dpatch
patching file debian/patches/remove-references-to-removed-drivers.dpatch
patching file debian/patches/drivers-ide-dma-blacklist-toshiba.dpatch
patching file debian/patches/alpha-epoch-comment.dpatch
patching file debian/patches/ipsec-missing_wakeup.dpatch
patching file debian/patches/00list-1
patching file debian/patches/drivers-scsi-generic_proc_info.dpatch
patching file debian/patches/drivers-isdn-io_funcs-fixup.dpatch
patching file debian/patches/drivers-scsi-sd-NO_SENSE.dpatch
patching file debian/patches/extraversion.dpatch
patching file debian/patches/alpha-tembits.dpatch
patching file debian/patches/drivers-input-psaux-hacks.dpatch
patching file debian/patches/drivers-input-hiddev-HIDIOCGUCODE.dpatch
patching file debian/patches/drivers-atkbd-quiten.dpatch
patching file debian/patches/drivers-scsi_changer.dpatch
patching file debian/patches/modular-swsusp.dpatch
patching file debian/patches/drivers-dpt_i2o-fixup.dpatch
patching file debian/patches/drivers-net-8139too-locking.dpatch
patching file debian/patches/drivers-net-irda-dma_api.dpatch
patching file debian/patches/modular-vesafb.dpatch
patching file debian/patches/chown-gid-check.dpatch
patching file debian/patches/drivers-ftape.dpatch
patching file debian/patches/fs-asfs.dpatch
patching file debian/patches/00list-2
patching file debian/patches/fs-asfs-2.dpatch
patching file debian/patches/00list-3
patching file debian/patches/chown-procfs.dpatch
patching file debian/patches/3w-9xxx.dpatch
patching file debian/patches/marvell-pegasos.dpatch
patching file debian/patches/xfs-update.dpatch
patching file debian/patches/marvell-mm.dpatch
patching file debian/patches/netfilter-signedcharbug.dpatch
patching file debian/README.NMU
patching file debian/rules
patching file debian/make-kernel-patch-pkgs
patching file debian/ChangeLog-2.6.7
patching file debian/substvars
patching file debian/prune-non-free
patching file debian/list-patches
patching file debian/unpatch
patching file debian/make-substvars
patching file debian/copyright
patching file debian/substvars.safe
patching file debian/official
patching file debian/README.Debian
So far so good, PaX next, dry run test real quick.
icebox linux-2.6.7-deb # patch -p1 --dry-run <
.../pax-linux-2.6.7-200406252135.patch
patching file arch/alpha/kernel/osf_sys.c
patching file arch/alpha/mm/fault.c
patching file arch/i386/Kconfig
patching file arch/i386/kernel/apm.c
patching file arch/i386/kernel/cpu/common.c
patching file arch/i386/kernel/entry.S
patching file arch/i386/kernel/head.S
patching file arch/i386/kernel/ldt.c
patching file arch/i386/kernel/process.c
patching file arch/i386/kernel/reboot.c
patching file arch/i386/kernel/setup.c
patching file arch/i386/kernel/signal.c
patching file arch/i386/kernel/sys_i386.c
patching file arch/i386/kernel/sysenter.c
patching file arch/i386/kernel/trampoline.S
patching file arch/i386/kernel/traps.c
patching file arch/i386/kernel/vmlinux.lds.S
patching file arch/i386/mm/fault.c
patching file arch/i386/mm/init.c
patching file arch/i386/pci/pcbios.c
patching file arch/ia64/ia32/binfmt_elf32.c
patching file arch/ia64/ia32/ia32priv.h
patching file arch/ia64/ia32/sys_ia32.c
patching file arch/ia64/kernel/sys_ia64.c
patching file arch/ia64/mm/fault.c
patching file arch/mips/kernel/binfmt_elfn32.c
patching file arch/mips/kernel/binfmt_elfo32.c
patching file arch/mips/kernel/syscall.c
patching file arch/mips/mm/fault.c
patching file arch/parisc/kernel/sys_parisc.c
patching file arch/parisc/kernel/traps.c
patching file arch/parisc/mm/fault.c
patching file arch/ppc/kernel/syscalls.c
patching file arch/ppc/mm/fault.c
patching file arch/ppc64/kernel/syscalls.c
patching file arch/ppc64/mm/fault.c
patching file arch/sparc/kernel/sys_sparc.c
patching file arch/sparc/kernel/sys_sunos.c
patching file arch/sparc/mm/fault.c
patching file arch/sparc/mm/init.c
patching file arch/sparc/mm/srmmu.c
patching file arch/sparc64/kernel/itlb_base.S
patching file arch/sparc64/kernel/sys_sparc.c
patching file arch/sparc64/kernel/sys_sunos32.c
patching file arch/sparc64/mm/fault.c
patching file arch/sparc64/solaris/misc.c
patching file arch/x86_64/ia32/ia32_binfmt.c
patching file arch/x86_64/ia32/sys_ia32.c
patching file arch/x86_64/kernel/setup64.c
patching file arch/x86_64/kernel/sys_x86_64.c
patching file arch/x86_64/mm/fault.c
patching file drivers/char/mem.c
patching file drivers/char/random.c
patching file drivers/pnp/pnpbios/bioscalls.c
patching file drivers/scsi/scsi_devinfo.c
patching file drivers/video/vesafb.c
patching file fs/binfmt_aout.c
patching file fs/binfmt_elf.c
patching file fs/binfmt_flat.c
patching file fs/binfmt_misc.c
patching file fs/exec.c
patching file fs/proc/array.c
patching file fs/proc/task_mmu.c
patching file include/asm-alpha/a.out.h
patching file include/asm-alpha/elf.h
patching file include/asm-alpha/mman.h
patching file include/asm-alpha/page.h
patching file include/asm-alpha/pgtable.h
patching file include/asm-i386/a.out.h
patching file include/asm-i386/desc.h
patching file include/asm-i386/elf.h
patching file include/asm-i386/mach-default/apm.h
patching file include/asm-i386/mach-pc9800/apm.h
patching file include/asm-i386/mman.h
patching file include/asm-i386/mmu.h
patching file include/asm-i386/mmu_context.h
patching file include/asm-i386/page.h
patching file include/asm-i386/pgalloc.h
patching file include/asm-i386/pgtable.h
patching file include/asm-i386/processor.h
patching file include/asm-i386/system.h
patching file include/asm-ia64/elf.h
patching file include/asm-ia64/mman.h
patching file include/asm-ia64/page.h
patching file include/asm-ia64/pgtable.h
patching file include/asm-ia64/ustack.h
patching file include/asm-mips/a.out.h
patching file include/asm-mips/elf.h
patching file include/asm-mips/page.h
patching file include/asm-parisc/a.out.h
patching file include/asm-parisc/elf.h
patching file include/asm-parisc/mman.h
patching file include/asm-parisc/page.h
patching file include/asm-parisc/pgtable.h
patching file include/asm-ppc/a.out.h
patching file include/asm-ppc/elf.h
patching file include/asm-ppc/mman.h
patching file include/asm-ppc/page.h
patching file include/asm-ppc/pgtable.h
patching file include/asm-ppc64/a.out.h
patching file include/asm-ppc64/elf.h
patching file include/asm-ppc64/mman.h
patching file include/asm-ppc64/page.h
patching file include/asm-ppc64/pgtable.h
patching file include/asm-sparc/a.out.h
patching file include/asm-sparc/elf.h
patching file include/asm-sparc/mman.h
patching file include/asm-sparc/page.h
patching file include/asm-sparc/pgtable.h
patching file include/asm-sparc/pgtsrmmu.h
patching file include/asm-sparc/uaccess.h
patching file include/asm-sparc64/a.out.h
patching file include/asm-sparc64/elf.h
patching file include/asm-sparc64/mman.h
patching file include/asm-sparc64/page.h
patching file include/asm-sparc64/pgtable.h
patching file include/asm-x86_64/a.out.h
patching file include/asm-x86_64/elf.h
patching file include/asm-x86_64/mman.h
patching file include/asm-x86_64/page.h
patching file include/asm-x86_64/pgalloc.h
patching file include/asm-x86_64/pgtable.h
patching file include/linux/a.out.h
patching file include/linux/binfmts.h
patching file include/linux/elf.h
patching file include/linux/mm.h
patching file include/linux/mman.h
patching file include/linux/random.h
patching file include/linux/sched.h
patching file include/linux/sysctl.h
patching file kernel/fork.c
patching file kernel/sysctl.c
patching file mm/filemap.c
patching file mm/madvise.c
patching file mm/memory.c
patching file mm/mlock.c
patching file mm/mmap.c
patching file mm/mprotect.c
patching file mm/mremap.c
patching file mm/rmap.c
patching file security/Kconfig
icebox linux-2.6.7-deb #
.. . . . what maintainer? You just need a packager for now; the patch
applies cleanly to the debian sources for 2.6.7.
|
|>| We have recently discussed this on at least one of the lists you
|>| posted to.
|>
|>| The end result of the discussion is that GCC is getting another SSP type
|>| technology known as "mudflap". Mudflap depends on some major new
|>| features of
|>| GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
|>| Debian GCC people don't want to merge in other patches which have no
|>| apparent chance of being included upstream.
|>
|>Then don't use ProPolice/SSP for now.
|
|
| That seems to be what will happen. I'd rather see SSP included
sooner, but I
| guess it won't happen.
|
I'm glad to see somebody's sane
Now, read this very carefully, as it's important.
http://pax.grsecurity.net/binutils-...402042140.patch
http://pax.grsecurity.net/binutils-...405291420.patch
These two binutils patches are on pax.grsecurity.net. They affect
binutils-2.14.90.0.8 and 2.15.91.0.1, respectively.
These add PT_PAX_FLAGS to the elf headers that binutils produces. These
ELF files are compatible with non-PaX Linux systems. It is HIGHLY
recommended that you use the corresponding patch for the version of
binutils used to build Debian's base system, rather than use the
depricated EI_PAX field used by chpax.
Even if you're not interested in patches that won't necessarily go to
mainline, this is HIGHLY recommended. The EI_PAX field is an unused
field, while PT_PAX_FLAGS is created specifically for PaX. This means
you can't predict what else might use EI_PAX (including other
experimental patches end users find/create). That field is volitile
under certain conditions; for example, in at least some versions of
strip, strip clears the EI_PAX flags. All versions of strip I'm aware
of leave PT_PAX_FLAGS untouched.
Also, by using this and PaX, you could very well influence the mainline
for the toolchain
That's a strong recommendation for if you go with PaX. You can ignore
it, but be ready to face any consequences that are incurred, if any.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBIXehDd4aOud5P8RAkMJAJ4+m/W+Bw1AkHp2+lsJ4QNGfJIjBwCghY2I
D8Z9hnzvRPe4Nw0a78GHlGk=
=qlsd
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Found a problem.
Russell Coker wrote:
| On Mon, 26 Jul 2004 02:57, John Richard Moser <nigelenki@comcast.net>
wrote:
[...]
|
| We have recently discussed this on at least one of the lists you
posted to.
| The end result of the discussion is that GCC is getting another SSP type
| technology known as "mudflap". Mudflap depends on some major new
features of
| GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
| Debian GCC people don't want to merge in other patches which have no
apparent
| chance of being included upstream.
|
- ----cut----
| Upstream has already decided to support mudflap in GCC 3.5, which is
| even more far-reaching than SSP.
I'm not sure whether all users of SSP would he happy with mudflap as a
replacement. It has a different focus; it was designed as debugging
tool. For example it probably incurs a much larger performance
overhead, since basically every pointer dereference goes through a
hash table.
- ----cut----
http://lists.debian.org/debian-deve...7/msg01154.html
It's a high-overhead debugging tool? I can understand this: The GCC
team would be more concerned with helping you FIX security issues than
blocking them at exploit time. It shouldn't interfere with ProPolice
anyway, I've been told, so you may want to go with SSP/ProPolice for
security reasons. Either way, moving to mudflap is going to require a
full system recompile on your end, so what do you really lose?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBIvNhDd4aOud5P8RAlZKAKCIQ1bhrB6N
kQMl36TBBXMD8ypyjwCfVhC8
+HS4a3waTxdgclEdfsmGPqc=
=la0p
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andres Salomon wrote:
| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
|
|
| I'm interested in discussing the viability of PaX on Debian. I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
|
|
|
|> I think debian-kernel would be a better place to discuss this (at least,
|> the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
|> been very pleased with it. I would love to be able to include it in
|> debian 2.6 kernels, but we need to make sure that:
|
|> a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
|> I've also heard reports of various grsec problems on 2.6; I don't
know how
|> many of those are PAX issues)
Did some digging. pipacs said that PAGEEXEC force-enables the 'disable
vsyscall' option, so you'd be forced to use SEGMEXEC on x86 to avoid
#245563, if I'm reading this right. On amd64, it should be fine; he
said that vsyscall is force disabled because having a high page
executable area will cause PAGEEXEC performance to fall through the
ground, due to the workings of the recent speed-up (which follows the
same method Exec Shield uses as a speed boost, and falls back to the old
way when that fails). Because amd64 has hardware NX, there's no
emulation issue, thus I'm supposing no breakage due to vsyscall.
: Tags added: fixed-upstream Request was from GOTO Masanori
: <gotom@debian.or.jp> to control@bugs.debian.org. Full text available.
Fixed in upstream. Either use an updated glibc in the next debian
release (I know there's no way you're going to suddenly shift STABLE to
PaX/pie/ssp, and I'm even going to recommend AGAINST that due to
Debian's development model), or backport the changes to whatever glibc
you use.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBU97hDd4aOud5P8RAjRuAJ9k3EiS+zVn
EFmLoCM8KnTOZehe8ACgh7FC
a9PyG2GbEkpMi17HlrUcyTY=
=3Mtk
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andres Salomon 2004-07-28, 6:23 pm |
| On Mon, 2004-07-26 at 14:37 -0400, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Andres Salomon wrote:
> | On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
> |
[...]
>
> Did some digging. pipacs said that PAGEEXEC force-enables the 'disable
> vsyscall' option, so you'd be forced to use SEGMEXEC on x86 to avoid
> #245563, if I'm reading this right. On amd64, it should be fine; he
Yep, that's right. I've talked to both ian and pipacs about it.
Spender and pipacs both agree that upstream glibc fixes will work.
[...]
> : Tags added: fixed-upstream Request was from GOTO Masanori
> : <gotom@debian.or.jp> to control@bugs.debian.org. Full text available.
>
> Fixed in upstream. Either use an updated glibc in the next debian
> release (I know there's no way you're going to suddenly shift STABLE to
> PaX/pie/ssp, and I'm even going to recommend AGAINST that due to
> Debian's development model), or backport the changes to whatever glibc
> you use.
The plan is to backport changes; I was hoping to make the next (debian)
glibc release, but no one else seems interested in fixing the bug, and
I'm lacking free time right now.
--
Andres Salomon <dilinger@voxel.net>
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andres Salomon wrote:
| On Mon, 2004-07-26 at 14:37 -0400, John Richard Moser wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>
|>
|>Andres Salomon wrote:
|>| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
|>|
|
| [...]
|
|>Did some digging. pipacs said that PAGEEXEC force-enables the 'disable
|>vsyscall' option, so you'd be forced to use SEGMEXEC on x86 to avoid
|>#245563, if I'm reading this right. On amd64, it should be fine; he
|
|
| Yep, that's right. I've talked to both ian and pipacs about it.
| Spender and pipacs both agree that upstream glibc fixes will work.
|
Cool.
| [...]
|
|>: Tags added: fixed-upstream Request was from GOTO Masanori
|>: <gotom@debian.or.jp> to control@bugs.debian.org. Full text available.
|>
|>Fixed in upstream. Either use an updated glibc in the next debian
|>release (I know there's no way you're going to suddenly shift STABLE to
|>PaX/pie/ssp, and I'm even going to recommend AGAINST that due to
|>Debian's development model), or backport the changes to whatever glibc
|>you use.
|
|
| The plan is to backport changes; I was hoping to make the next (debian)
| glibc release, but no one else seems interested in fixing the bug, and
| I'm lacking free time right now.
|
Check to see if someone else did it. I know it works on Gentoo, for a
few months now; but I don't know if it's just a newer version of glibc
or if there was also a backport for some of the older versions. I'm
using 2.3.4 pre-relases of glibc, so obviously I'm on a fixed version,
not an old one with a backported patch.
Never do work you don't have to do; gpl code can be freely yanked back
and forth.
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBV27hDd4aOud5P8RAlGSAKCQePuNYj3E
sEPMwGKi9O2WpaxbdwCfSlOF
4WuNZtKqaIkRVrO/xRNZewE=
=9fzL
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| GOTO Masanori 2004-07-28, 6:23 pm |
| At Mon, 26 Jul 2004 15:38:37 -0400,
John Richard Moser wrote:
> |>: Tags added: fixed-upstream Request was from GOTO Masanori
> |>: <gotom@debian.or.jp> to control@bugs.debian.org. Full text available.
> |>
> |>Fixed in upstream. Either use an updated glibc in the next debian
> |>release (I know there's no way you're going to suddenly shift STABLE to
> |>PaX/pie/ssp, and I'm even going to recommend AGAINST that due to
> |>Debian's development model), or backport the changes to whatever glibc
> |>you use.
> |
> |
> | The plan is to backport changes; I was hoping to make the next (debian)
> | glibc release, but no one else seems interested in fixing the bug, and
> | I'm lacking free time right now.
> |
>
> Check to see if someone else did it. I know it works on Gentoo, for a
> few months now; but I don't know if it's just a newer version of glibc
> or if there was also a backport for some of the older versions. I'm
> using 2.3.4 pre-relases of glibc, so obviously I'm on a fixed version,
> not an old one with a backported patch.
Is this VSYSCALL issue? I guess we can backport it without large
obstacle, but I have no spare time within a few days to work this bug
because there're a lot of other remained stuff. But I also think it's
good idea to fix this bug before releasing sarge.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-28, 6:23 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GOTO Masanori wrote:
| At Mon, 26 Jul 2004 15:38:37 -0400,
| John Richard Moser wrote:
|
[...]
|
|
| Is this VSYSCALL issue? I guess we can backport it without large
| obstacle, but I have no spare time within a few days to work this bug
| because there're a lot of other remained stuff. But I also think it's
| good idea to fix this bug before releasing sarge.
|
Yeah, that would be it.
| Regards,
| -- gotom
|
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBbAohDd4aOud5P8RAhy0AKCI1TVYqlLk
VizmLZgrbRBFvcT3rACggSEQ
S8Ww3wTtEBItkzEoWihXsR8=
=/jEe
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| GOTO Masanori 2004-07-29, 7:53 am |
| At Mon, 26 Jul 2004 21:30:17 -0400,
John Richard Moser wrote:
> | Is this VSYSCALL issue? I guess we can backport it without large
> | obstacle, but I have no spare time within a few days to work this bug
> | because there're a lot of other remained stuff. But I also think it's
> | good idea to fix this bug before releasing sarge.
> |
>
> Yeah, that would be it.
OK, I put debian/patches/glibc232-remove-vsyscall.dpatch to
debian-glibc cvs. It should be fixed for this problem. I created the
glibc 2.3.2.ds1-14 with this patch, at:
http://gotom.jp/~gotom/debian/glibc/2.3.2.ds1-14/
Could you test it with PaX, and confirm #245563 fixed?
Regards,
-- gotom
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John Richard Moser 2004-07-29, 6:02 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sure I'll test this out right away.
umm. Which? I'm gonna try libc6_2.3.2.ds1-14_i386.deb out I guess. If
you'd like me to test others, please list the debs. I'm just taking a
shot in the dark here
iceslab:~# cat /proc/pax_status
Available NX Modes: PAGEEXEC SEGMEXEC
Default NX Mode: PAGEEXEC
Softmode: No
iceslab:~#
Teh win!
Commit that for SID . . . hang on. *logs into Gnome and runs
Mozilla* OK nothing's breaking offhand, so it should be OK for SID I guess.
GOTO Masanori wrote:
| At Mon, 26 Jul 2004 21:30:17 -0400,
| John Richard Moser wrote:
|
|>| Is this VSYSCALL issue? I guess we can backport it without large
|>| obstacle, but I have no spare time within a few days to work this bug
|>| because there're a lot of other remained stuff. But I also think it's
|>| good idea to fix this bug before releasing sarge.
|>|
|>
|>Yeah, that would be it.
|
|
| OK, I put debian/patches/glibc232-remove-vsyscall.dpatch to
| debian-glibc cvs. It should be fixed for this problem. I created the
| glibc 2.3.2.ds1-14 with this patch, at:
|
| http://gotom.jp/~gotom/debian/glibc/2.3.2.ds1-14/
|
| Could you test it with PaX, and confirm #245563 fixed?
|
| Regards,
| -- gotom
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBCTx2hDd4aOud5P8RAkYfAJ9CKi70xTLw
t4DEGHBCwYZ0ShxrngCfcWDW
ox2Q7/sY3kPWazEJbu0jJHM=
=SMFo
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|