Re: [SC-L] Re: White paper: Many Eyes - No Assurance Against Many Spies

2004-04-30 Thread James Walden
Jeremy Epstein wrote:
I agree with much of what he says about the potential for infiltration of
bad stuff into Linux, but he's comparing apples and oranges.  He's comparing
a large, complex open source product to a small, simple closed source
product.  I claim that if you ignore the open/closed part, the difference in
trustworthiness comes from the difference between small and large.  That is,
if security is my concern, I'd choose a small open source product over a
large closed source, or a small closed source over a large open source... in
either case, there's some hope that there aren't bad things in there.
He makes three claims for greater security of his embedded OS:
	(1) A carefully controlled process for modifying source code.
	(2) Small size in terms of lines of code.
	(3) Auditing of the object code.
Certainly, a small, well-audited system is more likely to be secure than 
a large, poorly audited one.  Also, as there has been one discovered 
failed attempt to insert a backdoor into the Linux kernel, I agree that 
the potential for further such attacks exists.

However, his claim that Linux can never be made secure because it's too 
large to audit every time it changes is overstated.  He's ignoring the 
fact that few people (and even fewer in defence) will or should upgrade 
every time the kernel changes.  Widely used Linux distributions rarely 
include the latest kernel, even if your organization is using the latest 
distribution.  He's also confusing the difference between desktop and 
embedded Linux systems.  Yes, his embedded OS is small, but an embedded 
Linux system is going to be much smaller than the desktop distributions.

While kernel 2.6.5 may contain 5.46 million lines of code (counting 
blank lines and comments), much of that code is unlikely to be present 
in an embedded system.  After all, 2.72 million lines of code (49.8%) 
are drivers, 414,243 (7.6%) lines of code are sound-related, and 
another 514,262 (9.4%) lines are filesystem-related.  You're going to 
build your embedded system with the hardware drivers and filesystems 
that you need, not every possible device and obscure filesystem 
available.  The same is true for userspace setuid programs, which I'll 
not count as I'm not sure which ones would be necessary for the types of 
systems under discussion.

In summary, there are both fewer times and fewer lines of source code 
(and bytes of object code) that need to be audited than he claims. 
While auditing Linux is a more difficult task than auditing a smaller 
embedded OS, his claims are overblown since he ignores the fact that you 
only need to audit the parts and versions of the kernel (and OS) that 
you install and use when you install a new version.

James Walden, Ph.D.
Visiting Assistant Professor of EECS
The University of Toledo @ LCCC

[SC-L] MIT study on software development processes

2004-04-30 Thread Kenneth R. van Wyk
Hi all,

I just saw a Slashdot story 
announcing an MIT study on software development processes used around the 
world.  The report itself can be found at

I haven't read through the whole thing, but the slashdot entry indicates that 
the study found some interesting things, in particular the low use of 
specification documents in the design cycle.  Although it doesn't seem to 
address security per se, I thought that SC-L readers might find it an 
interesting read nonetheless.


KRvW Associates, LLC

RE: [SC-L] White paper: Many Eyes - No Assurance Against Many Spies

2004-04-30 Thread Dave Paris
A couple key phrases come to mind when reading this:

1) conflict of interest (he's selling a solution)
2) inappropriate comparison (embedded OS vs. general OS)

I have no problems with someone pointing out flaws in XYZ product when compared to ABC 
product, provided:

a) they're an independent, uninvolved 3rd party
b) the two products are identical in feature, function, and purpose.

So there are a couple trusted people who do the core work.  I wonder what their 
price is to put a flaw in the product?  If they're smart enough to know the entire 
system, they're undoubtedly smart enough to hide a subtle flaw.  Money?  Compromising 
photos?  Threats against themselves or families?  What would it take?

Frankly, I found the entire article nothing but a not-so-thinly veiled advertisement.  
Would he be so bold in comparing against VxWorks or QNX?  Those are his direct 
competitors, not the general Linux kernel.  If he wants to go head to head against 
Linux, he needs to specifically cite and compare against the embedded Linux 
distributions, be it uClinux or other.

Kind Regards,

 -Original Message-
 Behalf Of Kenneth R. van Wyk
 Sent: Thursday, April 29, 2004 8:25 AM
 Subject: [SC-L] White paper: Many Eyes - No Assurance Against Many
 FYI, there's a white paper out by Dan O'Dowd of Green Hills Software (see that It is trivial to 
 infiltrate the 
 loose association of Linux organizations which have developers 
 all over the 
 world, especially when these organizations don't even try to prevent 
 infiltration, they accept code from anyone.
 Although I don't agree with the positions expressed in the paper, 
 I still find it
 interesting to hear what folks have to say.  A story re the paper 
 has been 
 picked up by Computerworld and thus far.
 Ken van Wyk