Re: [SPAM] Re: SF new column announcement: How not to respond to a security advisory

[Andrew van der Stock <vanderaj () greebo net>]

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
--------------------------------------------------------------------------