Can Open Source Be Trusted?

Kostya asks: "I attended a infosec seminar put on by Tripewire and eSecurity on Tuesday. They had Dr. Gene Spafford from Purdue University giving a lecture on the changing landscape of infosec; he's the director of CERIAS. In his lecture, he argued that Open Source is not the solution to making trusted systems. Trusted systems are built according to a formal specification and are tested and confirmed against a formal testing and standards process. His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state. But isn't that what the Linux community prides itself on? Do you think he's right? If so, what can we do to develop more trusted systems?"

"I also menitoned OpenBSD to him as an example of a secure system that was open source. I argued that it was exactly because of the OpenBSD/FreeBSD development model (i.e. closely controlled with a top down hierarchy) that it was able to be more secure. Dr. Spafford still felt that OpenBSD did not fit the criteria of a well-trusted system: because it was not designed to a formal spec, and there are no formalized tests or standards being applied to it. Are there some ways in which we can get OpenBSD more trusted by testing it against some infosec standards?

For the rabid reader, I would just like to point out that Dr. Spafford NEVER disagreed with the 'more eyeballs means less bugs' tenet of faith that so many open source advocates preach. He just felt this was irrelevant to his point--how do you judge whether a system is more trusted than another system when there was no design spec or goals listed out to which to test the system against?

All in all, it was a challenging lecture. I felt myself start to get irritated, but by the end of his lecture, I was convinced he had a good point. How do you think we can address his criticisms?"

Honestly, I would say the same thing about a lot of commercial software as well. Just because you sell something doesn't mean that it's been designed properly, and likely just because something is free doesn't mean it's been slapped together with duct tape. Further more I'd trust a program with source more than one without and many open source developers are always willing to accept a better design. I'd also like to say that just because there aren't many pieces of Open Source that proceed with fully documented design goals, that this won't always be the case for future projects.

Comments

I agree with him

[Tet]

Basically, he's right. All he's saying is that with no formal design spec or test process, a system can't be considered secure. Yes, we have some design specs in the form of RFCs, POSIX and so on, but we certainly don't do rigorous compliance testing for them with each new release. For systems that aren't done that way, though (a category which applies to more than 99% of all available software, at a guess) I'd much rather take an open source one than a closed source one.

it's all in the definition

[Suydam]

Dr. So-and-so is defining trusted as being designed to a formal spec. That definition is constructed, whether the intention is there or not, in such a manner that he is right. Under that definition, Open Source cannot be a trusted system.

My assertion is that open source challenges the notion that you need a formal spec to develop trusted software. Much like the submitter of this story, I would hold up OpenBSD as an example of a system that I consider trusted, yet was not developed under any formal spec. Perhaps it's time to realize that formal specs help to get things done correctly, and they certainly help get things done quickly (by preventing, in theory at least, feature-creep), but they certainly are a requirement.

Re:it's all in the definition

[nhw]

My assertion is that open source challenges the notion that you need a formal spec to develop trusted software. Much like the submitter of this story, I would hold up OpenBSD as an example of a system that I consider trusted, yet was not developed under any formal spec. Perhaps it's time to realize that formal specs help to get things done correctly, and they certainly help get things done quickly (by preventing, in theory at least, feature-creep), but they certainly are a requirement.

I'm assuming you mean 'aren't' a requirement.

You may trust OpenBSD, but many people won't. The US Government, in particular, won't; nor will any company/agency/whatever that defines 'trusted' in a way that corresponds with TCSEC or ITSEC.

'Trusted' means a lot more than 'look, historically, it's got a great record' or 'we audit all our code'. Surely, these elements do form part of the equation, but there's a lot more to it than that: configuration management systems, proper specifications, and proofs of code against those specifications, a structured engineering process etc.

TCSEC and ITSEC do define themselves, at least partly, in terms of formalisms. The sames is true of DEFSTD 055 in the UK, and presumably similar standards in the US. Quite often, what is required of a trusted system is a proof of the security of that system.

Most of the systems that are developed for high levels of assurance under ITSEC/TCSEC are specified in highly mathematical notations that your typical UNIX hacker doesn't really have much interest in. The Certificate Authority for the Mondex smartcard system is designed to ITSEC E6 (which is roughly equivalent to TCSEC A1, for those more familiar with the Rainbow Books): the formal top level specification runs to 500 pages of Z.

Even once you've got a specification to work to, you still have to implement it. Now, if proof of source code against specification is required, you can throw away your C compiler right now, because proving properties of C programmers is a nightmare: you want a programming language with a simplified semantics, with dataflow annotations, and an associated toolset. Something like Spark ADA.

Some open source Unices may have a good record for security, but I doubt they'll ever meet the higher assurance levels. Most of the people who enjoy working on open source don't have the skill set or enthusiasm for the sort of work required here. How many of you wince when I say 'formal axiomatic semantics'?

Moreover, the customers for systems like these want to be able to hold someone accountable. I know that in the context of your typical company, this is an 'old hoary chestnut' and a much debunked myth, but the fact is that when the subject matter becomes sufficiently serious, support becomes a real issue, and the only way that companies _can_ sell is by standing behind their products.

I'm not saying that a trusted system (in the current context) could not be developed open-source, but that there are obstacles:

• The open-source development model does directly contradict most of the software engineering principles that are called upon in the development of trusted systems.
• The lack of skills and interest among open source developers to get involved in things like IV&V, code proof, development of formal specifications.
• The need for an entity to sponsor and support the code (preferably one with deep pockets).

The unfortunate fact of the matter is that writing trusted code is quite hard, and often requires a different mindset from 'hacking'. OpenBSD may have neat features like encrypted swap, and an audited SSH component, but it doesn't have an FTLS, MAC, or (God forbid) object code MCDC testing.

Cheers, Nick.

Re:it's all in the definition

[GregWebb]

I'm sorry, but you seem to be missing the point here.

OpenBSD is a wonderful, secure system. If I had to trust that an out-of-the-box, off-the-shelf system wouldn't give me a security problem on my hypothetical servers, OpenBSD would be there in a second.

What this guy is talking about is rather different. We're talking trusted functionality. Trusting that this software controlling your nuclear power station does exactly what it says. Trusting that your rocket will fly into space properly. Trusting that your ABS brakes will stop your car.

Now, if we're being at all practical, this requires a tight, formal specification which can be effectively tested. You can't ensure that a system works properly if you don't know what working properly means, while you can't practically ensure that it will work properly if you don't have a tight, complete and agreed definition to work from. Anything else means you'll have to spend a long time chasing down problems, which may well tun out to be fundamental to a design technique used in the implementation of the system.

Current 'open source' development styles simply do not permit this. There isn't any way to get this level of control, or even of proper design. Now, that doesn't mean that it's impossible to implement such software _as_ open source, merely that current methods won't work.

Frankly, though, I'm not sure there's any real point. Open development works very well with consumer applications marketted at computer nerds such as ourselves. We're prepared to put up with problems to get the bleeding edge in a certain respect. Release early and often is clearly sensible, while there are plenty of people who are demonstrably prepared to use this incomplete, unstable software and help the developers make it complete and stable.

Now, let's move this across to the field this guy's talking about. Let's imagine we're talking about the hypothetical ABS brakes on your equally hypothetical car. Release early and often becomes, to be perfectly honest, dangerous as it results in brakes whose functionality isn't certain. You can't be sure they'll stop your car. So, do you drive it? No. How do you find the bugs? Well, you can play with it on test cells, tracks, simulators and the like. But, how many people have them?

Now let's imagine the final release has a bug in it - a major problem, but not totally impossible. Let's suppose you manage to spot what's causing the bug. Should the team running the project take your submission? Well, I can't say I'd recommend it to them. If you're coding a bigfix without total knowledge of the system, its specifications and design parameters - which is inevitable in this environment - the potential for an unseen effect is huge. They're better off to get their own engineers, who know the problem well, to reimplement it. That way, they can know that it won't produce an unforeseen consequence elsewhere due to inadequate domain knowledge.

Releasing the source code for outside inspection may well help others to trust their code performs as they say it will, but it's not going to usefully do much more than that.

We are talking about a problem space which few of us here will ever encounter. It's hugely different, and the same models aren't necessarily true. We aren't talking about trusting your WP not to crash or report your every word back to its makers, we're talking about trusting your nuclear power station not to go into meltdown. And for that, the current 'open source' development methods are wholly inadequate.

Two variables

[Cuthalion]

Open source can be more trusted than closed source

Formally designed and reviewed software can be more trusted than chaotically assembled software.

These seem orthogonal to me (and to each other! wakka wakka wakka!). Sure, most all of the software out there is NOT formally designed for security first. A lot of it is open source, a lot of it isn't. Open source obviously doesn't make a programme or suite instantly bulletproof, neither does formal design and review. Nothing is 100% secure, trustworthy, or bug free. Loads of things can help or hurt the process.

Apologizing....

[emerson]

>Honestly, I would say the same thing about a lot of commercial software as well.

Well, yes. But that's not the point. You're playing the ad hominem deflection game: "seeeeee, they're just as bad, toooo!!!"

Boiling this issue down to open versus commercial is completely orthogonal to the actual point: well-designed, specced-out systems are going to be more trustable than ad-hoc slapped together ones.

Where the code comes from should be irrelevant -- if the spec is good and the code actually matches, all is well, regardless of origin. Granted, open source makes bugs easier to find, but also adds an element of chaos into the implementation phase that could be detrimental; the bazaar doesn't necessarily follow specifications. It's a tradeoff....

Trying to cast this issue in the light of open versus closed is really just playing the 'when what you have is a hammer everything looks like a nail' card with the Slashdot open-good-closed-bad mentality.

Not every software development issue can be solved by a free license. Really. I promise.
--

Understand what "trust" means.

[Paul Johnson]

Spafford's point was that before you can trust a system you have to know what you are trusting it to do. Simply saying "the right thing", or even "the right thing according to POSIX", isn't enough.

To describe this you generally start off with what you don't want it to do. Examples include "kill someone" or "let someone write to a file without authorisation". Then you have to say exactly what you mean by that (e.g. how might the system kill someone, and what constitutes "authorisation"), and before you know where you are you have a document several hundred pages long, much of which should be Z or VDM. Then you need to check that for any holes.

Then you have to prove that the system fulfils these requirements. Now a full formal proof of this is going to be a larger project than the original software by an order of magnitude, even with today's automated support. So the only feasible solution is to write the software very carefully. You have to identify each piece of code that might cause a non-spec event to occur, and then explain how it prevents any execution which might be outside the spec. And since this is important, you have to leave an audit trail behind so that potential clients (who are going to be staking lives and fortunes on your software) can see that you have done this properly. Unless you do all this, your system cannot be trusted.

(Aside: you also have messy recursive problems with trusting your development tools and hardware)

Put it this way. We all know Linux is reliable, right? But would you stake your life, or even your house, on keeping your Linux box up continuously for the next 12 months? I sure wouldn't. I wouldn't even do that with BSD. There are a few bits of software I would do that with, but... they were all written to these kinds of standards.

No matter how you slice it, this stuff requires a lot of hard work and bureaucracy. The question of "who will watch the watchers" is particularly germaine to the creation of trusted software.

Paul.

It's all in the people...

[Spoing]

The following is dry, and opinionated, from the POV of an old-timer VV&T/QT/Tester.

I'm big on specifications, and will argue both sides of a contract when a spec is violated. I've even been in a couple shouting matches over them, fighting for the correct implementation, not supposed "flexibility" though they do need to be bent at times.

Fortunately, the shouting matches are rare and as a Contractor Scum(tm), I never take them personally...only as a barganing point and to help stiffen the backs of those who are easily swayed. It's a shame when good projects go bad, but that's other people's money!

Good specifications are invaluable in eliminating all sorts of conflicts and allow projects to actually end without different groups wanting to kill each other.

Unfortunately, specifications are by necessity limited in scope. If it's not in the spec, it can't easily be added. If it's in the spec, it can't be modified easily.

On a formal contract, adding in goals like "The system shall be fast" don't work well, so more detail is usually specified; "The system shall retrieve a query on the client stations within 4 seconds at all times".

There's always a few details that slip by, and if the people on the project aren't reasonable the details will cause quite a few social and technical problems.

Even relying on an outside specification is a problem...since APIs/protocols/... are usually vauge on some level.

The people who implement it and the environment have a much greater impact on the results; there will be good and bad free software / open source projects...as there are good and bad commercial projects.

From what I've seen, I'll trust open source as much or more in most cases...but I'll test it first.

Re:Amazing -

[Kaufmann]

You've managed to miss the entire point of the discussion. As the original poster pointed out, this isn't about "enough eyes make all bugs shallow"; it isn't even really about bugs. It's not about "open == good && closed == bad", no matter how much faith the Slashdot crowd may have in this doctrine.

It's about OSS not being developed in a careful, thoroughly planned and controlled fashion. It's about the fact that right now, no OSS system out there can be satisfactorily considered "trusted", not even the high-and-mighty, "look ma I'm secure" OpenBSD.

I've pointed out elsewhere why a formal definition of the term "trusted" is important. Shortly, it's not enough to simply say "the general consensus is that it's secure, so let's just say it's trusted".

(And your absurd overgeneralisation to the effect that all expert reviews are corrupted doesn't help your case one bit. FYI, in the Real World (i.e. outside of Slashdot), ad hominem is frowned upon.)