[Asterisk-Users] Re: Advice on OS Choice

[Joe Greco]

> On Friday 15 October 2004 17:43, Joe Greco wrote:
> > That was never really the concern, that kind of stuff is pretty trivial.
> 
> It must be nice to keep adjusting the scenario to make your "having source is 
> bad" line work.  

No, it's a single product I'm considering.

> I know what you're trying to do (we're both playing Devil's Advocate).

Not really.  There is a product.  If you go into a hospital for major
surgery today, you stand a nontrivial chance of being hooked up to a
descendant of the device in question.

> > The concern was always more along the line of "what happens when they take
> > out the hard drive and putz with the image" - something you have relatively
> > little control over, because most shops expect to be able to do maintenance
> > on their equipment.  You can do various integrity checks that'll be mostly
> > sufficient (think: message digests of executables, into a fingerprint file,
> > itself signed with a key, but you still have to play some games to make it
> > difficult to corrupt the system)..
> 
> If it's life critical machinery it *should* be difficult to alter the images.  
> Routine maintenance should not include ways to alter these critical aspects 
> of the system.

Remove hard drive.  Mount on other system.  Putz.  Reinstall hard drive.

We had techniques to defend against that, because the system could do an
integrity check, and the first part of that - the init module - was a 
black box unknown.  If you messed with the modules, it wouldn't start. 
If you tried to sandbox the init, it wouldn't start.  If you tried to 
replace the init with the OS vendor's init, nothing would work at all.

You can't say "well don't let them pull the hard drive", because drives
can and do fail, and different versions of the product required different
hard drives on the same base chassis anyways.

> Seriously though -- what's stopping them from screwing up pump direction, 
> radiation strength, lens alignment or anything else they could do by 
> accident?  The software.  What's stopping the firmware bootloader from 
> verifying the system image before booting it?  Hell even our VFDs do that!

That's the point.  When you give someone the source to the system, they can
*inspect* your protection system, or worse, modify it, install it, and
defeat it, because then they can see how it's supposed to work, and once
you understand that, causing it to do something else becomes much easier.

> > Providing source makes it hellishly easier to disable or corrupt that
> > integrity verification system.
> 
> Not in a properly designed system, as I am stating.  That's like saying 
> sharing the algorithm for an encryption standard makes it easier to hack the 
> encryption.  If that's the case then the algorithm is *bad*. 

Correct.

> Same with the system in question.

I don't agree.

An encryption algorithm can be crappy or excellent.  If it is excellent, 
you can gain an understanding of how it works, but you will be unable to
decrypt data without the key, which is an external factor.

The problem with any integrity verification system which can be altered
is that you can inevitably alter the decision logic to indicate that the
image is good.

This is substantially different from the encryption algorithm, where no
amount of modifying the decryption code will result in the decryption 
code doing its work successfully without that key.

This is also why copy protection schemes have been successfully broken for
years and years and years.  It's not a question of /if/.  It's a question
of /how much work/.  A copy protection scheme is, after all, just a
variation on an integrity verification system.

Crappy Microsoft products such as XP have attempted to work around this by
introducing an external factor (the activation system), but have failed to
address the fact that at some point, there are still decisions being made
by a device under the control and influence of the user, and as such, there
are reportedly more illegal copies of XP than legal ones.

If it were even possible to "properly design" such a system and arrive at
something that couldn't be gamed, I'm sure that the largest software company 
on the planet would have done it by now.

> > I'll also say this:  while I'm no fan of security through obscurity, there
> > are certain extra risks to having code open to public scrutiny, especially
> > for networked appliances.  Sure, the code's carefully written, and audited,
> > but that doesn't save you 100% of the time...
> 
> Agreed.  I don't think you're some hidden source zealot; honestly I 
> don't.  :-)

Well, think what you will.  I like open source and I've written a ton of
open source software over the years.  I've also done other stuff.  What
causes me heartache is when I run into a case where practical requirements
prohibit me from making use of GPL software, and I know that the GPL
software in question would have been hacked upon, made better, and had
whatver changes were generally useful sent back to that project.  That
can only happen under the BSD license, and I view it as an "everyone
loses" case for the GPL'd software project.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.