lkml.org 
[lkml]   [2005]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patch 4/6 randomize the stack pointer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alright, I'll bite.

Someone told me to bring this up after reading all the complaints about
breakage, so again we get back to PaX. I'm more interested in "this
patch is bad" than "PaX is better" for this argument, but whatever.


Compatibility has been repetedly mentioned here. Breaking things has
been mentioned. Things inside the distro won't break becaues the distro
maintainers mark them; third party vendors should mark them too. If
they don't, they STILL won't break, if the distribution is crafted to do
really ugly things I hate to enter ultimate-global-super-compatibility-mode.

Last year I started on my master's thesis for computer security.
Granted, next semester i'm *hoping* to get my AS in computer science,
but I wanted to start writing early. So out of the 18 pages, I'll pull
one little bit from section 4 (Deployment) subsection 2 (Executable
Space Protections). This'll be a big read.

- ---CUT---
2. Executable Space Protections

Executable Space Protections can be deployed on many architectures using
PaX. A number of methods of deployment could be used, each ranging its
own ratio of security vs. compatibility. The recommended course of
action is to allow the administrator to control how protections are
applied, either by setting an automatic default method or by being asked
where protections should be applied on a case by case basis.

Any binary which may function under full restrictions should be set to
function under full restrictions automatically, without asking. There
may be an option to ask the administrator in every case including those
where the greatest security is used by default; but in most cases, the
administrator will not want to be bothered unless a security concern is
raised.

There are three states for restrictions. In the Default state, the
restriction is not explicitly enabled or disabled; PaX decides whether
to use the restriction based on the Softmode setting. If the system is
in Softmode, PaX does not enable restrictions in the Default state; if
the system is not in Softmode, PaX enables restrictions in the Default
state. Contrastingly, restrictions in the Enabled state are enabled
under PaX regardless of Softmode, while restrictions in the Disabled
state are disabled under PaX regardless of Softmode.

Here, the term "compatibility" is used to indicate how much software
doesn't work. A system with low compatibility will have software that
does not run due to security restrictions; while a system with high
compatibility will run most if not all software, including third party
software.

There are four basic methods of PaX flag control, each detailed briefly
below. As stated above, the administrator should choose which method to
employ.

A. Manual Control

Manual Control is not recommended as a default. Under Manual Control,
all restrictions remain in the Default state on all binaries at
installation time. This imposes the most added administrative duty
and the least compatibility.

B. Selective Disable

Selective Disable is the most basic form of control, allowing the
implementation to ship with everything working. Under Selective
Disable, binaries known to break due to PaX restrictions have those
restrictions set to the Disabled state when installed, leaving the
rest in the Default state. This relieves most administrative duty and
increases compatibility, although third party binaries may not come
marked.

C. Inheritive Selective Disable

Inheritive Selective Disable is similar to Selective Disable, except
that libraries are also marked and tabs are kept on these. When
software is installed which uses a library, the Disabled features of
the executable and each library are masked together to come up with
the final mask to apply to the executable. These masks can later be
generated for third party programs with an administrative tool in
order to enhance compatibility further; although third party programs
and libraries requiring other markings in themselves not also needed
by other libraries will still break.

D. Selective Enable

Selective Enable is the only method leveraging Softmode to enhance
compatibility. It is also the only method which will leave third
party binaries completely exposed with no reason aside from that they
are not explicitly packaged with a set of listed restrictions. Under
Selective Enable, executable binaries have all restrictions except
those known to break them set to Enabled, leaving the rest in the
Default state. Third party binaries which come with no markings will
have no restrictions in Softmode, and so full compatibility is reached
with the maximum justifiable trade-off in the range of executables
protected by PaX.

The above methods become progressively more compatible, but at the same
time less secure. Both the standard and Inheritive variations of the
Selective Disable method are about on par in principle; the
administrator will obviously disable protections on third party software
that breaks, so attempting to preempt this by identifying what
absolutely will break the software may prevent shotgunning (disabling
everything that could possibly cause a problem). This is a best-effort
compatibility model; anything obviously incompatible is adjusted, but
some things may be missed.

The Selective Enable method, on the other hand, will take compatibility
out to its edge and switch completely to a best-effort security model,
where anything obviously compatible is secured, but anything not defined
is left alone to avoid breakage. Microsoft's implementation of NX
protections on 64 bit Windows XP SP2 allows a mode which is akin to
this, in which only core system software is protected[24].

In any protection method, third party vendors can mark their binaries to
explicitly enable and disable protections to be compatible under any
method. If this additional information could be guaranteed from third
party vendors, the Inheritive Selective Disable method could be
completed by masking the still Enabled protections with the inherited
Disabled protections to produce the final mask, giving guaranteed
compatibility with least privileges.
- ---CUT---

Blah blah blah blah with softmode, PaX can be made to function only on
the programs that the distribution maintainers have touched. This
provides better protection for the base system, and removes all
protection for third party binaries, which makes the system infinitely
compatible with third party software.

Reminder, I hate option (D). You take the security away from the huge
realm of third party software to save yourself 3 seconds of `chpax
- -psemrx` or `paxctl -psemrx` which would do the same thing to most lkely
exactly one or at least less than ten special cases.

I believe that if you want your product to work, you should mark it for
PaX, since (hey!) the kernel ignores EI_PAX and PT_PAX_FLAGS anyway
unless it has PaX (I've tested this, and in fact Gentoo I believe
compiles with PT_PAX_FLAGS regardless of kernel used, but I'm not sure).

Now of course if vendors are forced to "release a patch" and continue to
maintain their product with a little extra command in the build/package
process, they'll just have to do it; but we wouldn't want to burden them
with 5 seconds more work (somebody always clips me on this one with "and
another 5 seconds, and another, until it takes 1000 years to release a
product").

Then again, a quick google will probably turn up "Oracle breaks on
<insert OS with protection that breaks oracle here>" "This is easy,
there's a command called 'paxctl'....." I mean hell, how many "tweaks"
are there that idiots put into there computer that start with "Microsoft
packages a tool with Windows called 'regedit'"?

This thread and this argument isn't about PaX. My point is that coarse,
mid, and fine-grained control should all be available to let a large
bane of power be weielded with respect. PaX does this by allowing you
to completely disable PaX (kernel compilation, not runtime; I'd love to
see runtime as well); set its exec protections into "softmode" where it
only goes for explicit "On" tristates for options on individual
binaries; explicitly disable protections on individual binaries; or
disable ASLR for the entire system.

Maybe I just like being able to fiddle with little knobs too much, but
it seems to me that I don't have to fiddle with them just because
they're there; my distribution can do it for me, and that's important to
me. *I* want to toy with them, but *you* shouldn't have to.

. . . what was my point? Oh yeah. it's possible to deploy huge
randomization and VM splitting and crap without breaking third party
software, see above for explaination.

Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>>What the hell?
>
>
> John. Stop frothing at the mouth already!
>
> Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
> ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
> with usable virtual memory areas etc.
>
>
>>Red Hat is all smoke and mirrors anyway when it comes to security, just
>>like Microsoft. This just reaffirms that.
>
>
> No. This just re-affirms that you are an inflexible person who cannot see
> the big picture. You concentrate on your issues to the point where
> everybody elses issues don't matter to you at all. That's a bad thing, in
> case you haven't realized.
>
> Intelligent people are able to work constructively in a world with many
> different (and often contradictory) requirements.
>
> A person who cannot see outside his own sphere of interest can be very
> driven, and can be very useful - in the "please keep uncle Fred tinkering
> in the basement, but don't show him to any guests" kind of way.
>
> I have a clue for you: until PaX people can work with the rest of the
> world, PaX is _never_ going to matter in the real world. Rigidity is a
> total failure at all levels.
>
> Real engineering is about doing a good job balancing different issues.
>
> Please remove me from the Cc when you start going off the deep end, btw.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+z9ShDd4aOud5P8RAgOBAJ9ABXCQQDMKL2rcxDTZbAMKiGP8/QCfQ8HS
Pp3qP1W1Mi2CD9V1OgC61J8=
=i2Bl
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.214 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site