|
BugTraq
Re: Buffer overflow prevention Aug 14 2003 05:26PM Mariusz Woloszyn (emsi ipartners pl) (6 replies) Re: Buffer overflow prevention Aug 14 2003 11:27PM Shaun Clowes (shaun securereality com au) (1 replies) Re: Buffer overflow prevention Aug 15 2003 06:48PM Crispin Cowan (crispin immunix com) (1 replies) Re: Buffer overflow prevention Aug 17 2003 11:09PM Shaun Clowes (shaun securereality com au) (1 replies) Re: Buffer overflow prevention Aug 17 2003 10:42PM Crispin Cowan (crispin immunix com) (2 replies) Heterogeneity as a form of obscurity, and its usefulness Aug 21 2003 02:00AM Bob Rogers (rogers-bt2 rgrjr dyndns org) (1 replies) Re: Heterogeneity as a form of obscurity, and its usefulness Aug 22 2003 03:56AM Crispin Cowan (crispin immunix com) (1 replies) Re: Heterogeneity as a form of obscurity, and its usefulness Aug 22 2003 06:21PM Nicholas Weaver (nweaver CS berkeley edu) Re: Buffer overflow prevention Aug 18 2003 06:07PM Mark Handley (M Handley cs ucl ac uk) (1 replies) Re: Buffer overflow prevention Aug 14 2003 07:37PM Theo de Raadt (deraadt cvs openbsd org) (3 replies) Re: Buffer overflow prevention Aug 14 2003 09:14PM Gerhard Strangar (gerhard brue net) (1 replies) Re: Buffer overflow prevention Aug 14 2003 09:43PM Theo de Raadt (deraadt cvs openbsd org) (1 replies) Re: Buffer overflow prevention Aug 14 2003 07:17PM Timo Sirainen (tss iki fi) (1 replies) Re: Buffer overflow prevention Aug 14 2003 06:47PM Jedi/Sector One (j pureftpd org) (2 replies) Re: Buffer overflow prevention Aug 15 2003 09:41AM Peter Busser (peter trusteddebian org) (2 replies) Re: Buffer overflow prevention Aug 16 2003 01:36AM Mark Tinberg (mtinberg securepipe com) (2 replies) |
|
Privacy Statement |
> > 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/
[ reply ]