There are a plethora of "operating systems" one could run on a
computer. OpenBSD and Windows do not represent anything like an
endpoint on the continuum.
While the OpenBSD approach, ("inspect the source by hand", which they
term an "audit"), while yielding some results, is fundamentally flawed.
Read it and weep for OpenBSD: http://www.cs.utah.edu/flux/fluke/html/
inevit-abs.html
As proof, there are other computer architectures which have not been
hacked, despite tremendous efforts, and others which were only hacked
once (Multics), and then only because someone left a low-level
debugger configured in-place. OpenBSD (and most of the other *nix-
based platforms) do not, for instance, implement BIBA by default.
Linux has the SElinux extensions which are now part of the 2.6 kernel
series, though not enabled by default, when last I checked.
In FreeBSD land, there is a project named TrustedBSD.
TrustedBSD provides a set of extensions to FreeBSD to add support for
{ACLs, Capabilities, Mandatory Access Control, Auditing} as well as
supporting features to implement them. These features are being
integrated into the base operating system distribution, with the
intent that they be "part of FreeBSD".
Restated, the OpenBSD and TrustedBSD projects have largely different
thrusts: the OpenBSD project seeks to provide a correct and bug-free
POSIX implementation (where correctness includes a focus on failing
to suffer from security holes). It also includes cryptography-related
features as a primary development goal, hence early development and
integration of IPsec in the base system (and a continuing high level
of maturity of their implementation), as well as their work on
OpenSSH. TrustedBSD project seeks to introduce a variety of
features, some described in the defunct POSIX.1e draft. These
include MLS (with fixex-label BIBA), MAC, ACLs, FLASK and Type
Enforcement.
Its possible (and perhaps probable) that OpenBSD will pick up some of
the TrustedBSD work, but this just proves that you can't look to
OpenBSD as "the secure operating system". Solaris has had similar
work in-place for *years*.
Whats next is the integration of source control into the mechanisms
for patching running systems, just the thing that IBM and Lisp
Machine environments (*) had in the 80s and before.
These are the kinds of systems that we are now having to rediscover
to be able to respond quickly when hackers find security flaws in our
running systems.
My 'complaint' about OpenBSD was really more "finger pointing" at
their flawed response. They really wanted to preserve the "N years
since a remote exploit", but could not.
Though it took five years for the last one, you get no guarantees
that the next one isn't being discovered while I type this.
Jim
(*) interestingly, you cant mount several popular attacks (buffer/
stack over-runs, etc) on Lisp Machines, either.
On Aug 6, 2007, at 3:45 PM, bully wrote:
So, let me get this straight. What are we talking about here? ONE
security 'hole' or exploit every FIVE YEARS?
As opposed to ONE "hole" punched in Windows OS every FIVE MINUTES?
(Or less?)
No brainer if you ask me. I think they're making way too much of
such a little thing comparatively speaking. (actually there is no
comparison) :)
Whatdayathink Jim? :)
Bully
Jim Thompson wrote:
On Aug 6, 2007, at 1:09 PM, 808blogger wrote:
well.... Keep in mind no other OS has even a close record to
what the
openbsd team has done.
Please.
And dont forget that the ssh you use everyday is
written by the openbsd team, thats right. Theo and co. have done
a HUGE job
improving security the unix world at large.
So what? There were RSA-keyed, encrypted telnets in-existence
before ssh got written.
(Under my watch, by Doug Barnes, at Tadpole, circa 1994. Doug
later of 'C2' fame.)
and on the topic of this particular exploit, you would actaully
have to be
on the same physical LAN segment to use this exploit. this is a
not an "over
the internet" hack that can occur
to quote from http://www.securiteam.com/unixfocus/5HP0C1FKUO.html
"However, in order to exploit a vulnerable system an attacker
needs to be
able to inject fragmented IPv6 packets on the target system's
local network.
This requires direct physical/logical access to the target's
local network
-in which case the attacking system does not need to have a
working IPv6
stack- or the ability to route or tunnel IPv6 packets to the
target from a
remote network."
"logical"... if your router manages to create a tunnel for you,
you're hosed.
Its **SPIN**, get it?
99% of users will not even have a a problem with this and
you dont even have to patch the system if you dont want to
simply put
'block in quick inet6' in your pf.conf
Right, but the claim is "default installation", and they didn't
want to lose that.
(and let us not forget that the other bug was in (drumroll) ssh)
dont dump on the openbsd guys..... their product rocks.
their process for security bugs appears to be quite badly borked.
and FreeBSD rocks much, much harder.
Jim
_______________________________________________
[email protected] mailing list
http://lists.hosef.org/cgi-bin/mailman/listinfo/luau
_______________________________________________
[email protected] mailing list
http://lists.hosef.org/cgi-bin/mailman/listinfo/luau
_______________________________________________
[email protected] mailing list
http://lists.hosef.org/cgi-bin/mailman/listinfo/luau
