Re: [Full-Disclosure] Re: Buffer overflow prevention

> Yet, persistantly we have been flooded by PAX supporters demanding
> that we should give credit to the PAX people for the ideas in W^X.
> When we had NOT known about PAX, and when W^X does NOT technically do
> what PAX does.
>
> How is it that out of one side of the mouth PAX people say that things
> which I say are not possible on i386 using W^X (full per-page X bit) are
> possible using PAX, and then the other side of the mouth says that W^X
> is just derived from PAX ideas?
[...]
> Oh? So to get their reward, they send out their drones to assault other
> projects, and get credit that is not theirs?
[...]
> I urge the PAX authors to get their community's rabid foaming under control.

Damn, this looks like textbook OpenBSD methodology for getting a vendor
to release hardware documentation or otherwise do what OpenBSD wants.

I guess it's a methodology that's only acceptable when it's being done
for the "noble" goals of the OpenBSD project and not when it is being
targetted at OpenBSD itself.

I suppose you might say this is a case of OpenBSD getting back what it
dishes out to others.

I sincerely doubt that this will have any impact, however, on the behaviour
of the OpenBSD drones. But one can still hope.

Now if I could think of a security-related angle, this email might even
have a chance of ending up being sent to the bugtraq list...

(o)

>I agree whole heartedly. It is interesting to see OpenBSD transition
>from a stance of "audit is the only way" to actually employing access
>control [...]

I persist in my belief that policy-based mechanisms do not improve
security. If you cannot make a default policy that everyone can live
under, you are creating a trap:

90-99% of people use the default policy, because they do not
change it

if that policy is restrictive, you have made a decision that
security is more important than useability

if that policy is not restrictive, you have made a decision that
useability is more important than security

(then there is also the issue of "it is restrictive towards what")

The trap I talk of is the one where you believe that security
technologies which make such a tradeoff (security vs useability) are
useful. They're useless! These things are buttons for experts, for
tweakers, for only security concerned people, to be used only by those
who feel threatened, and at best can only be used in SPECIFIC
instances. I do not know why there is so much emphass on such crap
tech from some parts of the community (research?) when it is clear
that the best technologies "just work" (translation: why do
researchers research crap "smart" tech instead of dump tech that just
works?). I still believe very strongly that efforts directed at
"security technologies that only experts can use" matter far less than
"security techologies that invisibly improve everything".

>It is tough to change
>your mind on big issues when you have a big public record to live down,
>so I don't particularly want to abuse Theo for making this policy
>change.

Hah, there is no public record to live down. Nor a policy change,
since we still audit code (with more emphasis on "audit means to
improve wholesale"). We also modify a lot of software for
priv-seperation or priv-revocation these days, to internally improve
specific application's resistance against successful exploitation (for
the situation of: it has a bug, but if you can exploit it, you gain
much less). Since we have more people interested in other areas, we
can expend efforts in other directions as well.

> and intrusion prevention technologies.

I translate this to mean that when some random bug does exist, system
features exist which decrease the ease with which it can be exploited.
ProPolice, StackGaurd, non-executable objects, random object addresses
-- these kinds of things fall in that area. Such mechanisms must be
automatic and always on. They must be very cheap. They must not
break any part of POSIX or another defacto standard . I repeat - they
must NOT break any part of POSIX; when developers have as much trouble
understanding the interactions between POSIX, please do not make
interactions that are even MORE magical.

One of these days someone is going to use the magic of a system call
interposition mechanism such systrace; and for their application
accidentally create an operating system behaviour that is un-POSIX,
and some application is going to misbehave as a result of that change
and inadvertantly this will result in the CREATION of a hole. Be very
careful when people tell you that their magic solutions are right.
The programs we run expect the system to act in a POSIX way -- and
consistantly too; but those who are writing policies do not understand
the details of POSIX. Details matter more than anything else. Like a
gun, these things create an process environment which is "POSIX
maybe".

There are things that can be done inside libc too, such as the atexit,
stdio, and malloc modifications we have. Or inside ld.so, where W^X is
done for the GOT and PLT. Some of this is fun, other stuff is really
difficult.

>I just want to tease him for choosing ProPolice instead of
>StackGuard without so much as talking to me :)

Hah, on the contrary, I chose ProPolice because I had talked to you. At
least three times over the last five years I asked you if StackGuard
had ever found a bug in software. Not a security hole, no... I was
asking if a system compiled entirely with StackGuard had resulted in
someone finding bugs, something inane like a buffer overflow in cat or
ls or nroff or something minor. It is clear these bugs do exist.
Come on.. programs dump core all the time! Bugs which had not been
found another way yet, but bugs that were found because a user or
programmer suddenly had StackGaurd abort their program due to such a
bug. You replied "no" twice, and if I recall correctly the third time
you just ignored my question (CHATS in Napa).

Since we incorporated ProPolice into OpenBSD, we have found many bugs
of this ilk. We've even found 2 buffer overflows inside our kernel.

These were not as such security holes per se, but just bugs. This means
the technology is working.

If any security technology shows no success at finding other related but
minor bugs, I really just don't see the point.

(We've found a few other such "minor bugs" with W^X too)

At some point, any serious technology must show side effects that also
help improve quality, or there is something wrong. I've been told by
a few people (who understand this area better than I) that StackGuard
puts the canary in the wrong place (maybe that has been fixed in the
meantime) I do not know if that is related.

We chose ProPolice for three other reasons:

1) it also re-organizes the local stack frame to put buffers closer to
the canary; non-buffer objects therefore cannot be overflowed without
a hit on the canary. i think this is the other fantastic part of
ProPolice rarely mentioned; I think the consequences of this change
are fantastic.

2) ProPolice is multi-architecture -- mostly portable code. Support exists
for at least i386, vax, m68k, sparc, sparc64, alpha, mips, powerpc. the
author is apparently working on the difficult task of supporting hppa.

3) the author is very eager. Since ProPolice was not yet bug-free
at the time we integrated it, we needed direct interaction with
the author to get some of the last problem areas fixed.

ProPolice impresses me. StackGuard did not, because it has not found bugs.

>>Again, ISTM that the only way to get close to a reasonably secure system
>>is to only rely on the smallest, most audited codebase possible to enforce
>>security policy. [...]

whenever I see the word 'security policy' everything after it starts to
sound a lot like 'blah blah blah maybe NSA or DOD will give me money' and
my brain fades out...

(sorry, perhaps that is a little bit strong)

Hi!

> > In fact, the amount of security in OpenBSD is only slightly less horrible than
> > that of most *NIX operating systems (which includes Adamantix for that matter).
> Again, ISTM that the only way to get close to a reasonably secure system
> is to only rely on the smallest, most audited codebase possible to enforce
> security policy.

I think you are right about that.

> To me this means something enforced by the kernel
> itself, like standard POSIX permissions and capabilities, NSA Flask,
> Systrace, SubDomain, LIDS, GRSecurity, etc. (note that this is not a
> particularly accurate list).

And this is in contradiction to the above, because normally, *NIX kernels do
not fit the ``smallest, most audited code base possible''. *NIX kernels are way
too big and too complex to be seriously audited. That is exactly why I say that
the if you believe that OpenBSD provides more security than others, it can only
be slightly less insecure compared to other *NIX systems.

There is no proof that adding security to a *NIX kernel afterwards results in a
highly secure system. It is like putting a powerfull engine in a family car and
then claiming it is a formula 1 racing car. It simply isn't because it wasn't
designed to be a F1 racing car. Similarly claiming that a *NIX system is
``secure'' is either a sign of ignorance or an attempt to deceive people (or
both :-).

> In any event, implementing the above is a far more complicated affair than
> can be accomplished by even an intelligent, knowledgeable and dedicated
> sysadmin. The only way that there will be significant uptake of more
> comprehensive access control/policy enforcement systems such as the above
> is if they are correctly configured and included by the OS manufacturer.

Agreed, that is why the Adamantix project was started, to create a distribution
that provides this.

> OpenBSD seems to be taking the right approach here by developing systrace
> and including systrace profiles for the base system, which is much better
> than the previous approach of trying to perfect the crufty and inadequate
> UNIX "security" model.

Well, it is quite elegant, I wouldn't call it crufty. And it was adequate for
an environment with only trustworthy users (including the system
administrator). It clearly wasn't designed for the kind of environment people
find themselves in on the Internet today. For that it is horribly insufficient.

Anyway, I always thought that perfecting this, what you call, crufty and
inadequate UNIX ``security'' model, is exactly what OpenBSD has been putting a
lot of effort in so far.

As far as Systrace profiles go: Personally, I'd rather have profiles for a
useful system, and not just for a base system. Furthermore, systrace is too
low level and too inflexible to be useful, which makes it too complex. That is
why it is taking people so long to effectively use it. And complexity is the
enemy of security.

> I'd like to see the other major OS distributors, Microsoft, RedHat, SuSE,
> Sun, IBM, Novell, etc. take an active part in this and not only provide
> systems with advanced security controls, but also ship them fully
> configured rather than relying on the system administrator who can't
> possibly understand the system well enough to fully configure them.

Right, you have described the next Adamantix release that is under development
at this moment. :-)

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

Theo de Raadt wrote:

> One of these days someone is going to use the magic of a system call
> interposition mechanism such systrace; and for their application
> accidentally create an operating system behaviour that is un-POSIX,
> and some application is going to misbehave as a result of that change
> and inadvertantly this will result in the CREATION of a hole.

For a concrete example regarding POSIX 1e capabilities (which
are essentially a "system call interposition mechanism"):

http://ciac.llnl.gov/ciac/bulletins/k-064.shtml

Summary: If a root process doesn't have CAP_SETUID, attempts to give
up root privilege fail, resulting in the process continuing to run as
root.

--
Glynn Clements <glynn.clements@virgin.net>

> In essence, PAX attempts a best-effort of mapping existing and unchanged
> Linux binaries (except for marking) so that they are mapped best for
> security. They do this by changing almost only kernel code.

This is not correct. PaX is about researching various ways of protection
against memory corruption bugs. The kernel land approach has just happened
to be the first step, it does not mean it's the last one. And indeed, ever
since we introduced full ASLR (more than 2 years ago), PaX has extended
its reach into userland, since to make proper use of this, you have to
create so called ET_DYN executables (a userland change, available in both
Adamantix [1] and Hardened Gentoo [2] these days), and of course our
userland changes do not stop here, as you can see it in the future plan
documentation [3].

> W^X does not do what PAX does; rather, W^X attempts to solve many of
> the same problem AREAS, but using entirely DIFFERENT SOLUTIONS.

One of the PaX features ([4]) implements the least privilege policy
in the context of runtime code generation (which is one of the possible
ways to exploit a memory corruption bug). This is achieved by
separating writable and executable pages into distinct sets (and
keeping them that way, at least by default because we believe in
'secure by default'). To be able to do this separation you have to
have the ability to mark pages non-executable of course (writability
is not a problem). Now tell me how this is different from W^X which,
err, also implements non-executable pages (for the same purpose, no
less)?

> Yet, persistantly we have been flooded by PAX supporters demanding
> that we should give credit to the PAX people for the ideas in W^X.
> When we had NOT known about PAX, and when W^X does NOT technically do
> what PAX does.

You keep stating that you had not known about PaX yet when asked for
presenting the internal discussions you had while developing your
W^X and other solutions ([5]), you suddenly go silent? Do you want to
tell me that there are no mailing list archives, icb logs, etc about
your technical discussions? Or are they secret?

> Holy cow, can you guys please stop crowing for me to revise history!

In order to revise history, one would need to know it in the first
place.

> It is clear that W^X was developed without knowlege of PAX; it is clear
> that this is a case of two solutions to a similar problem space -- call it
> convergent evolution; it is clear that begging for credit is just making
> your efforts look more and more political and less and less techical.

> I urge the PAX authors to get their community's rabid foaming under control.

I see you have the habit of creating paper tigers then burning them hard
and then thinking you're the hero of the jungle. The fact is, there is no
such thing as 'our community with rabid foaming'. We're not OpenBSD after
all, so there's noone to control.

> In attack after attack posted to our mailing lists, we were not being asked
> to say that the ideas from the PAX people predated the ideas in W^X. No, no!
> We were being told to say that W^X ideas were *COPIED* from PAX, when
> we had no idea that such a thing as PAX even existed!

Interesting, this [5] says otherwise, where did you pull that out of,
another paper tiger of yours?

> Furthermore, there are difference in approach between W^X and PAX which
> are so fundamental that it is clear we did not copy from PAX!

I don't think anyone was questioning the origin of your *code* since
there's next to no way to share such between Linux and the BSDs (at
least not in the VM).

> Like, our idea that mprotect should still permit a user to request a
> page that is PROT_EXEC|PROT_WRITE; by default the PAX people prefer to
> deny such requests.

We chose that because that's the more secure way. You allow runtime
code generation because there's maybe 0.1% of all applications that
need it and at the same time compromise the security measures you want
to provide as has been pointed out earlier in this thread (return-to-libc
style attack to call mprotect() and others). I personally believe that
it's better to have the best security out of the box for stuff like
sshd or apache, and live with the inconvenience of having to exempt
java explicitly.

> If you look at the PAX web and other much more formal documentation,
> you will find that they do not mention W^X.

For this there is a simple explanation: i have yet to finish the
documentation on related work (it will be a separate document),
it's a big undertaking when you consider the almost 40 references
i dug up on the net (some of which have apparently been unknown
even to researchers in this area well), so i chose to write code
instead. But rest assured, once it's finished, your work will be
a part of it as well (at the then current level of course, not long
forgotten and obsolete history as it happens in some papers).

> If you look at Crispin's StackGuard papers, you will not find a
> mention of ProPolice -- which is clearly a better StackGuard. Why
> should we mention PAX? It does not influence what OpenBSD users
> encounter. Are Linux people being specifically told "This is PAX,
> like W^X in OpenBSD"?

Indeed, it's not about influencing others but simple courtesy of
acknowledging related work - something you have failed to do, or
when you did, you made misleading statements (think of your earlier
POSIX (non-)compliance claims in PaX which i see you stopped now).

> W^X was invented because we saw the need for it. We had no idea
> that anyone else was working in the same area.

Actually i don't think this is something you should be so proud of,
it means that despite your claim ("Our aspiration is to be NUMBER ONE
in the industry for security") you didn't actually follow the industry
and have missed out on certain developments for years.

> I have seen about 50 mails from PAX developers or PAX-associated
> developers or users insisting that we say that W^X is a PAX derivative.

Please provide the references to these 50 emails from me or 'associated'
people.

> I will not revise history to make your ego feel less bruised.

There is no need to revise history, just make it known/available to
all.

[1] http://adamantix.org/
[2] http://www.gentoo.org/proj/en/hardened/
[3] http://pageexec.virtualave.net/docs/pax-future.txt
[4] http://pageexec.virtualave.net/docs/noexec.txt
[5] http://marc.theaimsgroup.com/?l=open...0386219963&w=2

On Mon, Aug 18, 2003 at 03:31:11PM -0600, Theo de Raadt wrote:
> >> If we had been aware of PAX as you claim, why would we have thought
> >> that i386 solutions were impossible?
> >
> >You have thought that i386 solutions were possible, because you have
> >implemented them.
>
> Can you please stop spinning this?

How could you implement an i386 solution if you still think it is impossible?

> W^X was up and running on some of our architectures before we had
> heard of PAX.
>
> Months later, ways of doing W^X for i386 were discussed, but this was
> also before we had heard of PAX.
>
> Even later, W^X was starting to work on i386, but even this was before
> we had heard of PAX.
>
> W^X does not do what PAX does; rather, W^X attempts to solve many of
> the same problem AREAS, but using entirely DIFFERENT SOLUTIONS.

Ok, thank you for clarifying that. I didn't know that. All I've seen so far is
abusive language from you against the people who contacted you about this
matter.

> Holy cow, can you guys please stop crowing for me to revise history!

Can you please stop making generalisations?

> It is clear that W^X was developed without knowlege of PAX; it is clear
> that this is a case of two solutions to a similar problem space -- call it
> convergent evolution; it is clear that begging for credit is just making
> your efforts look more and more political and less and less techical.

PaX is not my effort.

> I urge the PAX authors to get their community's rabid foaming under control.

I can't speak for other people in the community you mention, but it seems to
me that the one who is foaming right now is you.

> Like, our idea that mprotect should
> still permit a user to request a page that is PROT_EXEC|PROT_WRITE; by default
> the PAX people prefer to deny such requests.

Right, PROT_EXEC|PROT_WRITE is W|X and not W^X. Denying it is what you could
call secure by default.

> We informally (in mail to lists, etc) presented W^X to say we have
> shipped a system that does this and this and that, to improve
> resistance against exploitation of bugs, in concert with ProPolice.
> If you look at the PAX web and other much more formal documentation,
> you will find that they do not mention W^X.

If you look at the PaX web site, you will notice that it mentions other Linux
patches that do memory protection. The Adamantix web site links to the OpenBSD
web site and to systrace.

> Your continued insistance that we knew of PAX is making you look ridiculous.

My continued insistance? I've written only two messages about the subject, this
one being the second.

> I will not revise history to make your ego feel less bruised.

There is a saying which goes like: It takes one to know one.

> >The Adamantix Project
> >Taking trustworthy software out of the labs, and into the real world
> >http://www.adamantix.org/
>
> Competing against OpenBSD security efforts, but starting out 6 years later...

Thank you for thinking of Adamantix as competition. I think competition is
good and having a choice is also good.

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

On Mon, Aug 18, 2003 at 11:38:46PM -0700, Crispin Cowan wrote:
>
> ProPolice does not protect functions containing arrays of length 7 or
> less. We don't know what other cases exist in which ProPolice fails to
> protect. This kind of risk exists precisely because of the design choice
> that gives ProPolice its multi-architecture capability: putting the
> protection way up high in the compiler. This creates the potential for
> later stages of GCC to optimize away the security checks, or move them
> so far away from relevant code that they are no longer effective. When
> you choose ProPolice, you choose CPU portability over security.

You're correct that OpenBSD/ProPolice does not protect buffers of length 7
or less, but your analysis appears to be completely wrong.

It's just a simple #define SUSPICIOUS_BUF_SIZE, and looks to be there for
performance reasons. If you run with -Wstack-protector, PP will warn
explicitly when it skips a too-small buffer. If you are feeling particularly
paranoid and don't mind the performance hit, just crank the define down
and recompile GCC.

It certainly isn't gcc optimising away the checks, or anything to do with
architecture.

--
Anil Madhavapeddy http://anil.recoil.org
University of Cambridge http://www.cl.cam.ac.uk

Theo de Raadt wrote:

>>and intrusion prevention technologies.
>>
>>
>I translate this to mean that when some random bug does exist, system
>features exist which decrease the ease with which it can be exploited.
>ProPolice, StackGaurd, non-executable objects, random object addresses
>-- these kinds of things fall in that area.
>
Agreed.

>>I just want to tease him for choosing ProPolice instead of
>>StackGuard without so much as talking to me :)
>>
>>
>Hah, on the contrary, I chose ProPolice because I had talked to you [StackGuard did not find bugs]
>
That's a very peculiar complaint, which is inconsistent with the purpose
of StackGuard: it is an intrusion prevention technique, not a debugging
technique. If you want to go hunting for buffer overflows, use either a
static analysis tool like RATS, or a dynamic analysis tool like Fuzz.
Fuzz-like tools will slam programs with big strings, causing them to seg
fault where buffer overflow bugs appear. StackGuard and ProPolice only
slightly enhance the diagnostic output when you get a hit, and do
nothing at all to help find more bugs.

>Since we incorporated ProPolice into OpenBSD, we have found many bugs
>of this ilk. We've even found 2 buffer overflows inside our kernel.
>
>These were not as such security holes per se, but just bugs. This means
>the technology is working.
>
It means no such thing. StackGuard and ProPolice have exactly the same
(weak) ability to detect buffer overflow bugs. If you found bugs with
ProPolice and not with StackGuard, that means only that you tried with
ProPolice, and did not try with StackGuard.

You might respond that it is my job & not yours to try with StackGuard,
We have not done that, because StackGuard is completely the wrong tool
to use for such a bug hunt. None the less, if it helps you understand,
we have found two trivial bugs with StackGuard:

1. iwconfig (WiFi network configuration tool) had a bug that
triggered a StackGuard alert when the program exited. Something
was doing a buffer overflow that corrupted an activation record
just as the program terminated, so it was a non-fatal error.
iwconfig is not privileged and the error probably occurs too late
to exploit, so we did not bother to report it.
2. glibc has a fault in its self-test bootstrap
http://sources.redhat.com/ml/bug-gli.../msg00766.html This
too was insignificant, because Ulrich had already found and fixed it.

"How many bugs have you found with this tool?" is just a silly metric
for measuring intrusion prevention technologies. I understand that bug
hunting is your primary modus operandi, but just because you're really
into pounding nails does not mean that every tool should be evaluated
for its applicability as a hammer.

OTOH, here's a metric for you: ProPolice lets buffer overflows through:

obsd# uname -a
OpenBSD obsd.int.wirex.com 3.3 GENERIC#44 i386
obsd# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.3/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)
obsd# cat fail.c
#include <stdio.h>
#include <unistd.h>

int foo(char *blah) {
char buffer[7];
sprintf(buffer, "1234567890123456789012345678901234567890123456789 0");
return(1234);
}

int main(int argc, char **argv) {
printf("before foo()\n");
foo("blah");
printf("after foo()\n");
}

obsd# gcc -fstack-protector -o fail fail.c
obsd# ./fail
before foo()
Segmentation fault (core dumped)

ProPolice does not protect functions containing arrays of length 7 or
less. We don't know what other cases exist in which ProPolice fails to
protect. This kind of risk exists precisely because of the design choice
that gives ProPolice its multi-architecture capability: putting the
protection way up high in the compiler. This creates the potential for
later stages of GCC to optimize away the security checks, or move them
so far away from relevant code that they are no longer effective. When
you choose ProPolice, you choose CPU portability over security.

OTOH, I like the variable sorting hack in ProPolice, and thought about
implementing it, but chose instead to concentrate on PointGuard, which
protects all of the cases that ProPolice variable sorting protects, and
then some.

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Theo de Raadt wrote:
>>I agree whole heartedly. It is interesting to see OpenBSD transition
>>from a stance of "audit is the only way" to actually employing access
>>control [...]
>
> I persist in my belief that policy-based mechanisms do not improve
> security. If you cannot make a default policy that everyone can live
> under, you are creating a trap:
>
> 90-99% of people use the default policy, because they do not
> change it

This has to be the golden rule of any functional security system. 99%
of the admins aren't going to change the default system because 99% of
the admins aren't the guys who wrote the system. In any moderately
complex system the vast majority of the system administrators aren't
going to understand every possible facet enough to be able to
competantly make any large scale changes.

> if that policy is restrictive, you have made a decision that
> security is more important than useability
>
> if that policy is not restrictive, you have made a decision that
> useability is more important than security

Um, doesn't this kind of cancel out 8^)

> (then there is also the issue of "it is restrictive towards what")
>

And that may be the beginnings of an important distinction. The
security system needs to be flexible enough to support both the most
anal (can only browse to single intranet site) and permissive (every
desktop runs a quake server).

[snip]
> works?). I still believe very strongly that efforts directed at
> "security technologies that only experts can use" matter far less than
> "security techologies that invisibly improve everything".

This is kind of the main point I was saying. A new security system can
only improve overall security when it is widely deployed. The only way
it will ever be widely deployed is if it's almost completely transparent
to the end of the line admin who runs the system. Anything that
requires complicated setup is a non-starter, no matter how good and
secure it is.

>
> Hah, there is no public record to live down. Nor a policy change,
> since we still audit code (with more emphasis on "audit means to
> improve wholesale"). We also modify a lot of software for
> priv-seperation or priv-revocation these days, to internally improve
> specific application's resistance against successful exploitation (for
> the situation of: it has a bug, but if you can exploit it, you gain
> much less). Since we have more people interested in other areas, we
> can expend efforts in other directions as well.

This is all well and good, and I appreciate the efforts y'all have put
in this area but I think there are more fundamental problems about how
access controls are assigned that isn't being addressed by band-aid work
like privsep. It would be nice, if possible given the contstraints I
mentioned above, if the system's security archetecture could kill off
the process when it is comprimised, rather than relying on the
comprimise happening in a user-level privilidge section where it
"shouldn't" be able to do _too_ much damage. It's a good solution that
works with the system we've got, but I think there is a better solution
out there somewhere.

[snip]
> the details of POSIX. Details matter more than anything else. Like a
> gun, these things create an process environment which is "POSIX
> maybe".

Anything that requires a bunch of extra work from everybody
(programmers, admins, etc.) is a no-go from the start. It's unfortunate
that we can't completely start from a clean slate, but it just isn't
practical.

[snip]
> If any security technology shows no success at finding other related but
> minor bugs, I really just don't see the point.

While this seems like a pointless and arbitrary distinction, it is kind
of on the right track. Programs designed and implemented before
$whizzy_security_system probably exhibit all sorts of ill behaviour that
you'd never notice until the security system starts clamping down on it,
catching bugs. More of a side effect than a main feature though, ISTM
that whether this happens at all would depend on what kind of security
system you are talking about. I don't think a security system _has_ to
kick out bugs in existing software to be useful, but if it does kick out
bugs it is evidence that you're on the right track I think.

[snip]
>>>Again, ISTM that the only way to get close to a reasonably secure system
>>>is to only rely on the smallest, most audited codebase possible to enforce
>>>security policy. [...]
>
> whenever I see the word 'security policy' everything after it starts to
> sound a lot like 'blah blah blah maybe NSA or DOD will give me money' and
> my brain fades out...
>
> (sorry, perhaps that is a little bit strong)

Haha, no I wasn't trolling for DoD money I just mean "security policy"
in the generic sense. These things (machines, programs, people) should
be doing these things (talking to fileserver, sorting text, browsing
web) and not these other things (scanning network, executing shells,
reading accounting's files). I don't think that requiring each
application to be responsible for its own security is ever going to
work. It sure hasn't yet 8^)

- --
Mark Tinberg
Network Security Engineer
SecurePipe, Inc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/QoTKFu7F5OUjbGcRAtL6AJ99RkKp4fMz7V8GDvmZRY0Yg2eWzg CfaeVx
OxcYzC40Wh5z+G56zZy48nY=
=DBFH
-----END PGP SIGNATURE-----

On Mon, 18 Aug 2003, Crispin Cowan wrote:

> OTOH, I like the variable sorting hack in ProPolice, and thought about
> implementing it, but chose instead to concentrate on PointGuard, which
> protects all of the cases that ProPolice variable sorting protects, and
> then some.
>
I's not just a "hack" it's a great improvement that distinguish ProPolice
from Stackguard.
To be honest, it's the main reason why I migrated form SG to PP.
Beside that PP protects function arguments unlike SG!

To recapitulate: SG vs PP 0:2.

--
Mariusz Wo³oszyn
Internet Security Specialist, GTS - Internet Partners

> i don't care about other peoples war. but:
>
> > W^X was invented because we saw the need for it. We had no idea that
> > anyone else was working in the same area.
>
> i think it is somewhat strange. there realy smart people start building
> something before they do some research and look if someone else is
> doing something similar?

PAX was not really published in anything that I read. Compare it to
stackghost, a usenix security paper, which we have put some effort at
integrating.

Our tact was to support it first on cpu's that had a proper X bit in
their pte. Ie, sparc64 and alpha and such. Solving the problem on
x86 was not on our radar until, lemme think, perhaps while we were
eating curry during Usenix Monterey at that Irish pub....

As one of our developers said yesterday:

<miod> more exactly, we heard of pax when they started bitching