Hi Kurt,
Thanks for the discussion on the SF article, which has been picked up
on the Register as well.
First, I will address the Theo de Raadt reality distortion field
issue. Theo has a long history of ... um, how to say this
politely ... does not suffer fools gladly, and unfortunately he seems
to meet a fair few*. I believe this is how OpenBSD originated, for
example. Although his message in this instance is most likely
correct, it could have been said with a bit more information. It may
well have been - we don't know.
I personally believe that Theo's forthrightness is why the OpenBSD
cargo cult has so many tin foil hat wearing fan boys (and of course,
many serious security people such as yourself :) - they know that
Theo will tell it to them straight, even if it doesn't jibe with
someone else's preferred level of double speak.
As I've done two security vulnerability releases in my time and
worked behind the scenes on a few others, I know there is a lot of
pressure from various camps to either release it with klaxons blaring
right now, not release it, hide things or generally sweep the issue
under the "low" risk banner. I'm certain Theo probably has been asked
a thousand times for a quip "right now" about a vulnerability his
group doesn't coordinate and control, and he gives them precisely
what he thinks at that time. It's almost textbook Faux News
journalism applied to vulnerability disclosure - selective quoting
and probably selective omissions.
I'd like to hear from the original vulnerability disclosure writers
(Red Team Pentesting, http://www.redteam-pentesting.de) for how their
correspondence on December 4th - December 6th with Theo went. Maybe
there's more to this than is noted in the opinion piece.
Next, moving on to potential replacements for the secure level idea.
Secure level is a hack, like PHP's "safe" mode. It's not really
secure, nor is PHP's safe mode "safe". In both cases, properly
applied, they are at best a defense in depth measure, at worst, a
false sense of security.
Personally, I think porting SE Linux's security domains and mandatory
access control are probably a better solution than secure level. It
doesn't fix root, but it creates isolation so in effect there are
many low privilege "root"s. Coupled with OpenBSD's history of "secure
by default" installations, I think this could work if they were
prepared to do something about it, rather than just a glib one liner.
However, I've personally found that if access control models are to
be of any use, they need to be simple and easily applied. Go into any
corporate jungle, and the networks are awash with Everyone Full
Control shares with full read write access for all. It's just too
hard and expensive to maintain access control at that level, so
people just give up.
I don't have the solutions, and I know I don't speak for the OpenBSD
crowd, so I'd be interested in hearing from them if they want to reply.
thanks,
Andrew
* I say this as a second hand observer; I've never met or
corresponded with Theo. A good friend of mine is heavily involved at
the highest levels of NetBSD, and I heard some interesting things in
my time which I will not repeat as I cannot verify them, but even
Wikipedia's entry for Theo does not disagree with my personal view of
Theo:
http://en.wikipedia.org/wiki/Theo_de_Raadt
On 19/01/2006, at 3:53 PM, Kurt Seifried wrote:
> Actually no in this case the "academic" distinction is entirely
> correct. The file has NOT been replaced, modified, spindled or
> otherwise mutilated. It still exists, it has the same inode, it
> stil exists within the original directory structure/etc. Simply put
> a new directory structure and pointer to a new inode or network
> file system has been laid overtop of it's parent directory.
>
> What is the suggestion for a "solution" BTW? Everytime I mount a
> file system it's supposed to traverse the entire file structure
> "below" the mount point and check for any immutable flags? Do we
> add some sort of table, everytime a file is set immutable an entry
> is added so we canjust check the table quickly? No thanks.
>
> Personally I think OpenBSD's response is entirely acceptable and I
> will continue to use it (in fact I'm moving more servers to it).
>
> P.S. you may want to read up on "accepting risk". Not all risk must
> be mitigated/etc.
>
> P.P.S The quote" Here is a perfectly reasonable response that could
> have been used in place of what was offered.
>
> "Due to inherent weaknesses with the securelevel system,
> securelevels will not be included in any future release of OpenBSD.""
>
> Is a straw man, OpenBSD is unlikely to remove a feature that
> doesn't cause harm and more importantly and removing them would
> require touching a lot of code and potentially introducing a new
> set of security flaws.
>
> This is one of the weakest articles I've ever read, it simply comes
> across as whinging (a step down from whining).
>
> -Kurt
>
-------------------------------------------------------------------------
This List Sponsored by: Watchfire
Watchfire's AppScan is the industry's first and leading web application
security testing suite, and the only solution to provide comprehensive
remediation tasks at every level of the application. See for yourself.
Download AppScan 6.0 today.
https://www.watchfire.com/securearea/appscansix.aspx?id=701300000003Ssh
--------------------------------------------------------------------------
Received on Jan 19 2006
Intro
