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.

More than closed source

[hattig]

Open source software can be trusted more than closed source software when it comes to security, for all the reasons that you all know (quicker bugfixes, code open to scrutiny, etc). Closed source software can have hidden APIs, bad implementations and bugs, and the release cycle is slow.

OpenBSD is interesting, as they do audits on software to get rid of the security holes. They can only do this because the source code is available.

Of course, software like Sendmail, various ftpds, POP3 daemons etc, all mess up the security aspect of an OS. The OS can be as secure as it can possible be whilst still being usable and useful, but if the software being run on it is vulnerable, then backdoors into the system will be found. Having the source code available allows the cracker to find better access methods than having to guess and feel their way into a system.

You just have to remember that there will never be perfect security, and plan accordingly.

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.

Re:it's all in the definition

[frost22]

Dr. So-and-so

Oh man ... you just had to make yourself an idiot, had you ? Gene Spafford is longer around (on the net, and specifically in the computer security field) than most of you knew computers, let alone heard the Word "Internet". He is about the last person someone with a grasp for net.history might call "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

Well, Spaf is one of the foremost experts in his field. So, you redefine "Trusted Systems" - thereby disagreeing with him - and your credentials are ... what ?

Under that definition, Open Source cannot be a trusted system

Others in this thread have already shown this this be false.

My assertion is that open source challenges the notion that you need a formal spec to develop trusted software.

My assertion is that you don't have the faintest idea what you are talking about

f.

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.

Definition of trusted

[Kha0S]

As long as trusted systems are evaluated in a many-month long process as defined in the Red Book (NCSC Trusted Systems Evaluation Criteria), most Open Source OS's will continue to fall, simply because they cannot afford to have the testing or certification performed.

What we really have to remember is that Open Source OS's simply don't have the features that the trusted system evaluation criteria dictate -- it has nothing to do with whether or not they're secure in practice, but has *everything* to do with if they're secure in theory, such that a poor implementation can't break the security model.

Memory that's segmented in hardware such that even increasing your process priveleges doesn't allow access to the memory space of another process? Filesystems that log every transaction (including read/stat operations)? Systems that log every system call reliably, in an untamperable state? These are the features of government critically evaluated trusted systems, and until Open Source OS's support them, we shouldn't gripe. =)

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

Re:Apologizing....

[GregWebb]

That sentence actually made me wonder if Cliff knows what the guy is talking about or not.

If we approach this from the viewpoint of trusting that our OS will not crash or be hacked (or whatever) then this argument has some merit. But we're not, and this isn't really about commercial vs. community development. Trusted code, after all, normally means that we're talking a custom job for a particular application, rather than off-the-shelf.

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.

Trusted Systems - Building Paranoia into the code

[ka9dgx]

Trusted systems require that the programmer be paranoid. I think that this is a very simple requirement, but one that is very hard on the psyche of the programmer. Do you really want to spend all of your time worrying if your code will break? Oh... wait... we all do!

The difference in trying to build a trusted system is the formalization. The team which tries to break a system (or certify it), is called upon to review the design, and try to find all weaknesses that might be used to break it. While this could be done with open source, you'd have to find someone to play the role of review team. This could be a serious problem.

I think that it's certainly possible for an open source project to build an operating system to match "C2" specifications, or better. The problem with meeting the Orange Book requirements is that they require trained people to review and test a system. This requires a large commitment of time, effort, and especially, money. Then when you are done, you have certified one version of the system, and nothing supsequent. The open source model is one of many releases, with bug fixes as we go, which has many strengths, but makes the rapid obsolencence of what would be the "blessed" version a big weakness. So, it's possible, but I don't think we should try for it.

I do think that there is a better way, if the testing procedures can be automated, so that the code can be covered from every angle, by the a set of computers pounding on a system, this could be MORE secure than a "Trusted System", at least at the C2 level. A set of workstations could be set up to pound a system, and try to find weaknesses, ala "SATAN", with emphasis on stack overflow weaknesses, etc. If a computer does all the functional tests that a human review team does during C2 certification, this is a good step in the right direction, if nothing else. Add to this a group dedicated to adding test conditions for new flaws, as they are found, or hypothosized, and I think you've got the winning combination for a truely secure platform.

What is really needed is a way to make all of the consequences of a line of source code visible. With C, C++, Delphi, Fortran, et al, there is no way to see all of the possible (side) effects of a line of code. That simple iteration, could have a bounding condition that causes a major hole in security, or it might be perfect, how can anyone know? I consider this to be the problem of brittle code

Object Oriented Programming is a good step in the direction, it does, if properly used, make code testable down to the object level. There need to be better tools for hammering on each object, and making sure they work as delivered, but at least you have something which CAN be tested on a unit level. OOP is good, but still not good enough. It does go in the right direction, because cracks in a system can be traced down to a single component, but those components can be brittle. Testing those components to a high degree brings us close to the goal (my goal, actually) of perfect code. Close, but no cigar.

A platform needs to be built which can make writing a computer program as simple as working with physical objects, such as hammer, nail, etc. When you pound a nail into a 2x4, you know right away if something goes wrong, and what all the effects are. It's easy to test, and visually verify the results. Coding needs to be the same way. This would take a lot of the "magic" out of the process of coding (and uncertainty). What ideas are out there for making this happen? Is a system of individually tested components good enough?

I have a few ideas, which I posted more than a year ago with my own manifesto at basicsoftware.com, ( and I need to review those ideas myself) but really haven't contributed anything myself. So I'm in the same boat... my contribution is a possible pointer in the right direction, and a keen eye on others, and their response.

The goal should be to make software better than any possible real world analogy. We need components that don't fail, and work predictably in a all conditions. If that's not possible, it would be good for the component to signal exactly what went wrong. Nails holding things together loosen over time, software doesn't have that weakness. Nails don't signal failure, but wouldn't it be nice if the nails in your roof signaled failure before the disaster struck?

--Mike--

Spafford's right, but wrong

[dublin]

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

In fact, the two are orthogonal to one another in most aspects, but they can be aligned. I don't see any dichotomy between open source and the kind of intense process that produces trusted systems, it's just that the open source movement hasn't matured to that level yet.

Spafford's observation is correct today, but he makes the erroneous assumption that open source community will continue its current practices of doing inadequate planning and testing to ensure real trusted systems. This is one of those areas where the arrival of the commercial backers of open source, like IBM, an offer substantial contributions.

The one thing that has marked the open source movement from the beginning is the ability to respond and change quickly to get the job done. We are in the adolescence of the open source movement, and since trusted systems do require more process than the standard open source method provides, and since people will want trusted open source systems, it's only reasonable to assume that the open source process will morph as required to "scratch the itch"

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

Trusted unrelated to reliable/secure

[alexhmit01]

Trusted Systems refers ONLY to the spec. The spec must match a certain criteria, and then the OS is designed and tested to that criteria.

Remember the NT C1 (now C2) compliance thing? Because NT's design happened to include some of the elements of the C2 definition, they were able to come up with a configuration that could be trusted. Not bugfree or secure, but trusted. (Note, NT's C2 security used to involve no NIC, but I think they fixed it).

OpenBSD is really fucked secure, but isn't designed to the spec, doesn't include the ACLs and other stuff needed for DoD compliance, etc.

Neither does FreeBSD, but remember the Trusted FreeBSD project? They are trying to make a B1 compliant (trusted) BSD based off FreeBSD.

Also, Operating Systems are not inherently trustable. It is the entire system that earns a security rating. It largely involves a fine tuned control of file access, but not a fine tuned fixing of bugs.

Alex

Yes, I picked NT as my "trusted OS" mostly because it will generate the stupid /. effect of "waah waah waah, NT is horrible, you must be a moron" the required "you are the stupidest ass in the world" and other stuff like that.

Get a grip kids! OSes are NOT the end all and be all of life. Further, drop the prejudices. I am an MCSE, that does not make me a moron, clueless, or a lemming. Indeed, just because all the MCSEs that you know are dumb does not mean that they are dumb BECAUSE they are MCSEs. Some of us happen to be very competant administrators, and happen to have a certification. Some of us actually learned are shit to get it, instead of just memorizing study guides.

Quit hurling insults to people that sometimes disagree.
Alex

problem with specs...

[EnderWiggnz]

THe problem with specifications, is exactly its benefits.

When WYSYWYG interfaces, someone point out that not only is What You See Is What You Get, but also that What you see is ALL you get. This means that while you can see on the surface what document or page or whatever that your creating, and how its looking, but thats all your going to get, nothing else, no more, no less.

Take example a standard graphics program like the GIMP, and compare it to POVRay. The GIMP's WYSYWIG interface is really slick, but with POVRay, you can create ray traced images that would be next to impossible in a WYSYWYG environment, but you dont get to see the exact creation before its done.

With programming, a formalized, structured process ensures that the program will give you what you want, but it will never provide more than that.

True "Innovation" will never occur. No one may spot the flaw in the security model, no one may realize that 40-bit encryption is a bad way to protect DVD's from being copied, no one may predict that a Record-Industry defined "secure" file will only be effective for a couple of .. minutes?

But by setting Goals, but allowing for large amounts of flexibility of the Programmers allows for products to be delivered that are not only Programs that meet their requirements, to Products that truly meet their needs.

And trust me, clients requirements and their needs are almost always two completely separate things.

Use Gnumeric as an example - the author did what? Copied Excel. What did excel do? Copied Lotus? Lotus? They copied VisiCalc.

But the question remains, these products are meeting requirments, but are they really meeting the NEEDS of the people that use them. Couldnt someone have thought of a better way of setting up a spreadsheet? Making the formulas? Hell, why are there formulas at all?

But I'm sure you get the point.

Linux may not have the strict methodology that modern business management and Quality Testing require, and that, is exactly why it ends up with higher quality products in a shorter amount of time.

Formal Specs? RFCs!

[Tower]

Hmmm, well - you can easily test if the networking components of open source software live up to the RFCs that they are designed to meet. Sounds like a bunch of specs to me. A description showing overall protocols and spefic situations, with specified function and response to stimulus sounds like a pretty good control document to me.

The HTTP RFCs are a good example.
This is what you MUST do:
This is what you SHOULD do:
This is what you CAN do (if you feel like it):
This is what you MUST NOT do:

Pretty cut and dry, and rather effective (the web works, don't it?).

I'd say that most JAVA implementations (from most companies) would fail full compliance to the Java spec (well, at least some of the Java specs... there's so many these days).

If I understand him correctly. . .

[Goonie]

the man is talking about formally-specified and verified systems, where everything is specified in some mathematically-based specification language, and then the implementation is demonstrated to have desirable properties in relation to the specification. Chaotic, bazaar-style development doesn't match with this style of development at all.

However, this kind of formally verified system is extremely costly to develop, extremely difficult to adapt to changing circumstances (and retain the verified properties), and still doesn't guarantee that it does what you want it to do - mistakes in the specification or mistakes in the verification process are just as likely as mistakes in coding.

Frankly, for 99.9% of the software written in the world, this kind of thing is utterly impractical and will remain so. I don't mind consigning the remaining 0.1% to cathedral-style approaches (though open source can still help spot bugs that the verification doesn't catch).