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

Some people have too much time on their hands.

[queasymoto]

On an unrelated note, Spaf (Dr. Spafford to you, buddy) also runs the usually-funny Yucks mailing list. This list has long seemed among the cream of the crop of net-humor to me.

Whats that got to do with it?

[pallex]

"His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state. "

What does the way something is developed have to do with the final product (or a given release), and the tests performed on it? You are testing the product, not the developement environment, surely?

Re:Whats that got to do with it?

[Schnedt McWapt]

Sorry, guy.

The "but it's better than Microsoft" arguement is wearing thin, and might soon be rendered meaningless.

You'll have to come up with more meaningful ways of praising Linux and Open Source in the near future.

Re:Whats that got to do with it?

[Schnedt McWapt]

What does the way something is developed have to do with the final product (or a given release), and the tests performed on it? You are testing the product, not the developement environment, surely?

It's a well-established tenant of modern 'quality' theory that it's not enough to 'test quality into a product.' One cannot simply ignore the process by which something is produced, and just test it as a final step.

I think this article, however, goes further than this, and actually hits Linux and Open Source at one of it's weakest spots: the lack of a top-down well managed design. Linux has no team of central designers determining the basic structure of the OS. It instead relies on knowledgable developers using 'Unix' in general as a reference design to produce a 'kinda sorta' Unix clone OS. The severe lack of any real architects at the top overseeing the whole effort is an issue that isn't well addressed by the 'Open Source' ideologues.

Re:Whats that got to do with it?

[SEWilco]

Right. You can test as much as you want but you can't prove the program will always do what is desired (the obvious example is the Windows BSOD).

The trust has to begin with a trusted algorithm, then the trust has to follow in an unbroken chain through all the coding and testing. And the entire system has to be trusted -- although you might do this process with a cryptographic library, you also have to trust the system library routines, the program loader, the network library and drivers... At least with environments such as MULTICS the trusted items can be well isolated from the untrusted, but it's still a big job making and keeping it clean.

Fortunately, there is a difference between a provably secure environment and an environment which is secure enough in practice. People have been creating small provably-secure environments at great expense for 30 years, but most people can't use or afford the results.

There have been efforts to blend mathematical algorithm provers with programming tools. Perhaps someone will succeed with something general enough to be able to review existing code.

Re:Whats that got to do with it?

[nhw]

What does the way something is developed have to do with the final product (or a given release), and the tests performed on it? You are testing the product, not the developement environment, surely?

Nope; that's not true actually.

Probably more than half of the work that goes into the design and implementation of trusted systems has nothing to do with 'code', or how the final product tests.

When you get to high levels of trust, you cease to regard testing as an adequate assurance. You want to see evidence that the system has been specified carefully and correctly, and that the code meets the specification. Needless to say, if you don't have a specification, you can't be trusted.

The most that testing can tell you about a program is that you haven't managed to make it Do The Wrong Thing. For high levels of trust, you want a proof that it can't. And, if Doing The Wrong Thing includes disclosing top secret data, missile launch codes or cooking a patient with gamma rays, then I'd bet you'd prefer the latter too!

Cheers, Nick.

Re:Whats that got to do with it?

[pallex]

"When you get to high levels of trust, you cease to regard testing as an adequate assurance. You want to see evidence that the system has been specified carefully and correctly, and that the code meets the specification. Needless to say, if you don't have a specification, you can't be trusted. "

Yes, but this just tests that what has been specified has been coded correctly. If people are just adding bits here and there, as in an open source project, such as Linux, then nothing is specified as such, but you can test the various bits just as well. Its just outside this particular development paradigm.

You can still `prove` that a given part of the product works succesfully, surely.

Re:Whats that got to do with it?

[stevew]

This is a common mis-conception concerning the way the develpment cycle occurs. Don't you imagine that Linus and the BSD guys have a general idea of what features they are going to add to the kernel? I assure you they do. There is a certain amount of discussion and "show me the code" that occurs for features to get added, but this is no different than would occur in a cathederal environment behind closed doors. There are just more eyes looking at it.

Further, when we are talking about Linux are we talking about the kernel or a distribution??? The simple fact is that his arguement covers the entire system, not JUST the kernel. I tend to think he is right for "trusted" systems, but as an article just below this states - you can have a practical/safe level of security thru careful auditing of the existing software, and you get it faster.

So the point - Linux (and the BSD's too) DO have a central group of designers determining features/structure of the design. On the other hand, a distribution is much more of a patch work.

Re:Whats that got to do with it?

[aug24]

There are two ways to get a trusted system really. 1) You can have a spec and test it exhaustively *yourself* or *trust* that the coder did so. 2) You can have no spec and trust the hundreds of people who are more paranoid than you and actually read the code. 1) = MS type products 2) = OS type products Neither model is perfect. Neither model is infallible. I know which one I *trust* more though...

Re:Whats that got to do with it?

[nhw]

I originally wrote:

When you get to high levels of trust, you cease to regard testing as an adequate assurance. You want to see evidence that the system has been specified carefully and correctly, and that the code meets the specification. Needless to say, if you don't have a specification, you can't be trusted.

pallex wrote:

Yes, but this just tests that what has been specified has been coded correctly. If people are just adding bits here and there, as in an open source project, such as Linux, then nothing is specified as such, but you can test the various bits just as well. Its just outside this particular development paradigm.

If the specification correctly embodies the requirements (enter, stage left, the requirements engineers), then what you've actually proved is that the system Does The Right Thing.

I'm not sure what you're getting at when you say 'you can test the various bits just as well', if you don't have a specification. What are you going to test them against? Your personal expectations? What if another developer has subtly different expectations?

What I'm getting at, basically, is that you can't prove shit about squat unless you have some kind of specification. And unless your specification has been done in a moderately rigorous manner, then even what proofs you can do are mostly worthless.

This isn't meant as a knock to the Open Source development model, it's just a harsh fact of life. Where proof is important, specification is vital, and historically that has tended to imply Cathedral, rather than Bazaar. I would be interested to see a large open source project done with a degree of formalism. In fact, if anyone is interested in doing something that way, I'd be interested to be involved!

Cheers, Nick.

Re:Whats that got to do with it?

[scott@b]

3) The system spec is designed, with clear interfaces, I/O limits, and the like. The product is developed opensource style to that spec, with some folks builting the test suite and tools.

Source + Spec + Test
I think that might be even better.

Re:Whats that got to do with it?

[CmdrPinkTaco]

"can't we all get along"
-Rodney King

The whole "my OS is better then your OS" argument is wearing thin. From both sides of the Open Source / Closed Source Factions. Maybe some day people will realize that certain OSs are created for specific purposes. Microsoft clearly is the leader in the desktop front, and *NIX is clearly the leader in the back end. The distension that is created by the people who believe that an office/home/"place where computers are used" should all be one happy OS family and cannot have other OSs involved are the truly ignorant. Microsoft is constantly criticized because to them communication and connectivity to them means communication / connectivity to other Microsoft products. When OS vendors wake up and realize that having communication between multiple OSs will create a truly powerful environment, then both of these arguments will cease to exist and we as the consumer will be the ones who will benefit.

Frankly I am posting this to both of the above posters. When you learn to play together, you will find that you will become far more powerful than by fighting with each other.
------------------------------------------ --

Re:Whats that got to do with it?

[shadowduck]

There have been efforts to blend mathematical algorithm provers with programming tools. Perhaps someone will succeed with something general enough to be able to review existing code.

There is some work being done on proof-carrying code, where the execution of a program can be tested for certain properties. See here for further info.

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.

Re:I agree with him

[blane.bramble]

But does Open Source mean that there CAN'T be a design spec or any formal methods? Just because the current leading lights don't use them, doesn't mean it CAN'T be done.

There's plenty of closed source stuff that doesn't have any formal methods - does that mean that it can't be done? No. Maybe it's harder to do with open source, because the development cycle tends to be more relaxed, and it's harder to impose methodologies on those working on it, but that doesn't make it impossible.

Re:I agree with him

[session]

I don't think Dr. Spafford ever mentioned that it CAN'T be done -- he just said that open source systems are not currently done that way (and therefore cannot be trusted as secure systems).

Re:I agree with him

[darkith]

His point is that Open Source by itself does not make a trusted system. The problem is that many Open Source advocates tend to equate source code and trust, even if they themselves have never glanced at the code.
Just because it requires a quick "make install" doesn't necessarily make it secure. Note that I'm not arguing that Open Source doesn't have it's merits...just that a "trusted" program must be built from the ground-up according to a rigid set of design principles and standards. (a moving target at the best of times).

An interesting point is that my experience in software development tends to suggest that standards are poor in both closed and open source dev'ment, but I have to wonder if it is inherently harder for an open source project to adhere to standards?

Re:I agree with him

[mvw]

Careful formal testing is among other things dull work. Definitly less sexy than the usual areas hackers like to hack. So it is not impossible, it just might proceed very slow if at all.

Good chance for some company to make some bucks.

Re:I agree with him

[dsplat]

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.

Is there anything preventing building automated test suites? I would think that there are plenty of excellent tools to build the actual software: Expect, perl, etc. The problem is what tests to run and the time for someone to write code that doesn't extend the functionality of the system. It is useful, but until it actually catches some bugs before they are found by other means, there isn't any glory in it.

Re:I agree with him

[Shirotae]

But does Open Source mean that there CAN'T be a design spec or any formal methods? Just because the current leading lights don't use them, doesn't mean it CAN'T be done.

There could be design specs and use of more rigorous techniques up to the use of formal methods, but would Open Source developers be prepared to submit to that discipline? There is no reason why the code produced should not be free (both senses), but are there enough developers with both the skill and the inclination to work to that model in an Open Source effort? Perhaps the problem is that those inclined to work on Open Source projects like freedom to use whatever techniques and tools they like, and this makes it hard to verify that the results meet the negative (no unexpected behaviours) as well as the positive aspects of the specification.

There's plenty of closed source stuff that doesn't have any formal methods - does that mean that it can't be done? No. Maybe it's harder to do with open source, because the development cycle tends to be more relaxed, and it's harder to impose methodologies on those working on it, but that doesn't make it impossible.

I think that only a tiny proportion of closed source software has been developed with a serious input from formal methods. I am not sure that detailed and accurate design specs are all that common either.

Being unable to impose methodologies on voluntary contributors is probably the main obstacle to having a typical Open Source project meet the view of "trusted" that Spaf was using.

Attitude to those who write specifications also plays its part. We will never get an Open Source project with a rigorous demonstration that it meets a usefully detailed specification unless the writers of the specification get at least as much respect as those who write the most difficult code.

I don't know if he said it at that infosec seminar, but Spaf has also pointed out that not enough people are being educated in computer security, and how to build more trustworthy systems. The shortage means Universities can't keep faculty with experience in this area, and this leads to the vicious circle of less teaching and research that means the shortage continues.

Re:I agree with him

[Spoing]

Is there anything preventing building automated test suites?

Automated testing sucks. Don't think it's going to save you any time or catch defects any more reliably or faster. It's tempting, and can be useful, but it's usually a big waste of time.

To do it right, you need to basically duplicate everything that the target program does, and verify it's output. When the code changes, your scripts often break. Guess how many people on a project of 30 people will code that?

Now, how many people will want to do automated test scripts on a project with often and early release schedule?

Having said that, limited automated testing can be very valuable. Usually testing protocols or data manipulation...ideal to catch some security issues.

Re:I agree with him

[Senior Frac]

All he's saying is that with no formal design spec or test process, a system can't be considered secure. No. He's saying it can't be proven secure by certifying authority. It obvious that the Dr. is, excuse the cliche, "thinking inside the commercial software box" because he's defining "secure" as a certification process only achievable through a decision by committee. A very corporate/academic thought process that. The open source movement appears more interested in the end results. Can infinite monkeys pounding on keys produce better code than a well-designed comittee process? Eventually. *grin*

--

Re:I agree with him

[Spoing]

'Formal testing is borring': Yes. It is.

"Good chance for some company to make some bucks.": Yes, it can be!

Re:I agree with him

[Grab]

Find an automated test environment that _works_.

The trouble is, you can have something like Lint go through and say 'that looks dodgy'. But you still can't prove that the code is doing what you want.

Our company has an in-house testing tool. We write long (LONG!) lists of test scenarios in Excel, then use the tool to check that the outputs of each function are what we expect. This has 2 flaws: (1) the tests may themselves be wrong, or (2) the design requirements for the function may be wrong. If the tests are wrong, either a bug can get through or a valid bit of code gets flagged up as being wrong. If the design is wrong (eg. the design asks for us to add 1 instead of subtract 1) then it'll be coded wrong too, and we'll never see it.

So the layer above this is to put all the functions of a module together, and then do some more higher-level tests on that. And then put all the modules together, and do some more tests on that. And you've got a pretty good chance that your code is right after all that, but you're still not sure.

As for automatically generating the tests - where from? Do you have an explicit, computer-parsable set of requirements for your project? Have you ever seen, or even heard of such a thing? Ever? I'm afraid it just doesn't exist. The design is done by humans, and the test scenarios are extracted from the design by humans. Humans are fallible. Shit happens. The best you can do is test as best you can. And if you're thinking about getting the test scenarios from the code - well, d'oh! if you're testing the code with tests extracted from the code, nothing's ever going to fail! :-)

We're writing safety-related and safety-critical software for car engine controllers. We're going on to other stuff like drive-by-wire. We can't afford errors, so there's oodles of testing. But shit does happen, so all we can do is say "well we tested it the best we could". Nothing is ever 100% safe, and 100% testing is provably impossible. So the problem is getting folks to make sure the designs are right, then that the code meets the designs. Open-source seems to fulfill that requirement pretty well. The problem is for older things like 'sendmail', where a design doesn't actually exist - newer projects like Apache would (I imagine) have proper design documentation.

Grab.

Re:I agree with him

[motek]

You are missing the point. If you are implementing something, it can be beneficial to design it first ;-). Then you can write test scripts that check, whether the code does exactly what it is intended to do. That implies, some sort of tests should be devised prior to writing code.
When code changes (but its intent does not) there sould be no reason for rewriting test scripts. If they break it means, the code is flawed.


-m-

Re:I agree with him

[Anonymous Colin]

Exactly. The issue is not whether Linux is secure or not but whether or not it can be proven secure with current methods. As current methods require an algorithmic functional specification which can be logically proven consistent and coherent and Linux most definitely DOES NOT possess such specifications, Linux cannot currently be proven in this limited, theoretical sense.

So what is the issue? It could equally validly be any of the following (and no doubt others):

Perhaps Linux really cannot be trusted (in the common-sense meaning of the word, rather than the formal, mathematical meaning in the lecture).

Perhaps proof mechanisms are inherently too limited to be applied to all real-world situations.

Perhaps current proof mechanisms are too simplistic and promitive to handle something like open source but future approaches will provide useful metrics. For instance, though logical consistency proofs may be forever outside the realms of this approach, perhaps stochastic methods will give probability scores that, though not absolute, are nonetheless useful.

Take your pick, they are equally plausible to me. I personally have serious doubts about the certainty that formal methods instill in some. They are all based at some point on assumptions of fact that may be true now but could be overturned by new technologies. For instance, a proof of a crypto method might assume that computing is in some sense inherently serial. Look what happens to such a proof if quantum computing takes off and essentially infinite parallel processing algorithms arrive.

Still, whatever you feel, understand that the professor almost certainly means something different from you when he says "trusted".

Re:I agree with him

[Spoing]

I think you responded to something that wasn't in my original message. Take a look below and feel free to hit me with a clue stick if you have a legitimate gripe not voiced in your reply.

Yes, things should be properly designed prior to coding. Yes, testing should be an early consideration prior to coding. Manual -- and implementation independent -- test scripts will be created before any code on good projects.

1. Sidebar: Are you talking about mixing testing and design with coding? That's a bad idea.

Theoretically an automated test could be created prior to coding. In practice, nobody does that unless they have a very limited scope for the tests they want to perform...or if they want to waste an amazing amount of time!

Each automated test script I've created using over a half dozen different tools all have the same problem;

1. Scripts are highly dependent on the actual code -- the implementation. Change anything, and the test scripts I've created in the past have almost always required modification just to get them to push data through the system. Checking the results at each step is an entirely different level of complexity.

I haven't been able to create scripts prior to code being delivered unless _I_ wrote the code. Mixing coders and testers in the same group is just a bad idea on multiple levels. If you don't know the objections, I'm not going to tell you...ask a few people you respect.

Remember, you're validating the spec not how the spec is implemented. How do you, in an automated fashon, track deviations unless you limit yourself to IO?

The only exceptions are when you focus on data and protocols; does the input x always result in the specified output y? Works for files and data regaurdless of volume, though how long a test takes can result in different results.

Re:I agree with him

[jeremyp]

Proof mechanisms *are* inherently too limited for real world situations. For a start, how do you prove 1/2 a million lines of code (say). It'll take some time, unless you use an automated proving tool. How do you know you can trust the proving tool? You have to prove it. Even if you have 100% proved the source code is OK, what about the compiler / interpreter? What about the operating system, CPU microcode, the logic design of the chip etc etc etc.

At some point you have got to stop and just trust everything below that level. Taking gcc as an example, how do we know it always produces correct code. Has anybody done any formal tests to prove it? No, but I bet it hardly ever occurs to anybody that their problems may be a result of a compiler bug. Enough people use gcc every day without problems to make it fairly trustworthy. Is trust built on experience any less valuable than trust built on formal methods?

Re:I agree with him

[rdemanow]

OpenBSD -- it's Open Source, it has a formal spec, it's regularly and thoroughly audited.

Re:I agree with him

[notsoanonymouscoward]

Is trust built on experience any less valuable than trust built on formal methods

An excellent point. It seems as though many of the other threads grasp at this concept without saying it explicitly. In the case of OSS we have people constantly using viewable code. With so many coders making use of said code day in and day out, if something is wrong, it is eventually found and fixed. The proof of reliability can be found in the number of people who have used the code without problems.

Re:I agree with him

[mindstrm]

Right.. but this has nothing to do with open -vs- closed.
Nothing is stopping a company from making 'Secure Linux' and rigorously applying compliance tests for each new release.

It has absolutely nothing to do with whether something is 'open' or not, it simply has to do with packaging.

Re:I agree with him

[dsplat]

We use some limited automated testing at work. Where I find it most useful is when I intend to rewrite a piece of code (for efficiency, to extract a common piece into a library, whatever) without changing the behavior or interface. I construct a few tests that treat it as a black box, make them work on the original version and then make sure I don't break them in making my changes.

In general, any piece of code htat has to test some output is relying on the programmer that wrote it knowing the answer in advance. I know from experience that unless there is a spec that spells it out, there is a decent chance that somebody will mess up. Of course, there's a decent chance of bugs in the spec too.

Re:I agree with him

[motek]

First thing first:

Mixing coders and testers in the same group is just a bad idea on multiple levels.

Quite frankly, I still fail to see why. Mind you, I know usual explanations about desired independence of quality control etc. I just never agreed with this. Maybe because I never worked on a project involving 200 programmers in cravats.
The point I would like to make is that tests should be derived from the design of the software and not from the observation of how it works after it was implemented. That implies, tests should be designed by (or with participation of) the person, who designed this stuff. If you use the above recursively, it will mean: tests should be created by a programmer, who develops (i.e. designs and implements) specific module.
There are good reasons for this kind of organization, ant the best I have ever heard is that if you are unable to write a routine testing the your design that means, that you didn't understand the problem.

Another statement of yours:

Are you talking about mixing testing and design with coding? That's a bad idea.

No, it is not bad idea. I think that what I wrote above explains why, but I shall risk being redundant in hope to save one erring soul:
I am not talking about final test. These are like final exams at a college: You have to pass them to be admitted somewhere, but passing them does not necesserily make you good at your profession.
The problem is to make sure every single functional part was designed (and not conjured) and that implementation sticks to design. Good way to do it is to require a programmer to provide tests for her designs and of course to execute them ocassionaly (e.g. everytime something gets changed)

Next one:

How do you, in an automated fashon, track deviations unless you limit yourself to IO?

Every testing short of tracing code through a debugger is in the matter of fact limited to input and ouput (not to be confused with reading and writing to files). Like you feed a function (I don't mean a routine in some programming language) with data and see, what pops up on the other side. If you do it not on the highest level only, but wherever you expect problems to originate, life could be easier. Well, obviously, good judgement is necessary here, but, c'mon, we are all intelligent people here, aren't we?

Regards, -m-

Trust CLOSED source?

[laptop006]

One of the reasons you might use open source software, is that you can read through the source of all the software you consider using for any security holes / excess features etc. With closed source software you have to trust the software developer, and if/when security holes are found you have to trust that they will: 1. Officially announce it. and if your lucky... 2. Release a patch for it.
--
Laptop006 (RHCE: That means I know what I'm talking about! When talking about linux at least...)

This guy's crazy!

[Chanc_Gorkon]

Let me ask you this....who would trust the security of an operating system when you can't look at it's source code?? NOT ME MAN! I trust Microsoft about as far as I can throw em.

I have to agree

[michael.creasy]

Because of the way Open Source is developed it will have less bugs than some commercial software, but it will never be developed to a formal specification using tried and tested Software Engeering principles.
Commercial software (i.e. closed source) benefits from not being developed in a chaotic way and can be more secure. Techniques such as the Cleanroom approach, software inspection can lead to almost zero-defect software. Which is something I don't think Open Source can ever really achieve.
The use of formal methods for specification and verification does achieve secure systems, the only way Open Source can match commerical systems developed in this way is for them to be developed in a similar fashion. Sure, you can still give the source away, but developement does need to be centralized for these techniques IMHO.

Re:I have to agree

[hattig]

it will never be developed to a formal specification using tried and tested Software Engeering principles

Can you back this assertion up? I see no reason why Open Source software cannot be developed in a good proven way? Sure, some software will not be, but that software will not be used in critical systems. A lot of Open Source software originates from the academic community, e.g., Exim was written at Cambridge University, and these programmers will have used good software engineering techniques to write their code.

I don't know of many big Open Source projects that have just been hacked out from the start now, there has always been a lot of planning going on, and surely less bugs means more security?

Commercial software (i.e. closed source) benefits from not being developed in a chaotic way and can be more secure.

I bet a lot of the closed source software that is developed is not developed in a less chaotic manner than the Open Source way? If you call distribution of programmers "chaotic" then yes, but I believe that you can have more chaos when all the programmers are in the same room and some are doing things they don't want to really be doing, than when all the programmers are spread out around the world (and never see each other even!) but have the desire to write the software.

The use of formal methods for specification and verification does achieve secure systems

Formal specification and verification is all very good, but it takes so long that it isn't used in any commercial companies, except in some kind of loose analogy. Commercial Companies want to get their software out of the door quickly, this does not lead to good secure quality software. Open Source can take its time, witness the Linux 2.4 kernel - getting it right before it is released. OTOH, Gnome 1.0 was a mistake, they tried to compete with KDE before the software was ready.

Tools such as rational rose can be all very good when used correctly, but all to often the designers do not have the time to get familiar with the tools they use, so they underutilise the software in such a way it takes them twice as long to do something that could have been expressed on a sheet of paper.

So you can see how Open Source works, and it looks chaotic, distributed, and messy, but the code isn't, the people have an interest in the code beyond making a fast buck, and this means that bugs and security flaws will be detected, and fixed, and the software will end up being of a high quality, when it finally gets released. Most commercial companies do not have the luxuries known as time, dedicated programmers, etc. They have money to throw at a problem.

Re:I have to agree

[nhw]

Formal specification and verification is all very good, but it takes so long that it isn't used in any commercial companies, except in some kind of loose analogy.

That simply isn't true. It's true that most consumer software isn't developed to those standards, but just because you don't see it happening at Microsoft, doesn't mean it isn't happening...

An awful lot of safety/business critical software is developed with formal specifications, and even proof on an industrial scale. I've included a URL and a reference to a paper at the end of this post. That software is common in aerospace, rail, telecommunications and (as businesses realise that they are increasingly dependent on their computer systems) in finance.

For examples of products developed with a high level of formalism, including mathematical specifications, see: Praxis Critical Systems' SPARK projects page.

If you're interested in reading about how formal specification and proof have been applied in real systems, see (for example) 'The Value of Verification: Positive Experience of Industrial Proof', FM'99 Vol II, LNCS 1709 (1999), p. 1527. Sorry for the paper reference; a good college library will have LNCS though.

Cheers, Nick.

Re:I have to agree

[hattig]

Okay, your point is taken. In critical systems, it is obvious that higher levels of software validation will occur than in non-critical systems.

However, look at the UK. Closed source systems to run the NHS - failed, poor software. Closed source systems to upgrade Air Traffic Control - failed, poor software. 999 Emergency management software - dumped, poor software, and many other examples. I am not saying that some 15 year old Linux hacker would have done better, but Closed Source systems which should have been better designed have quite often failed.

Re:I have to agree

[nhw]

I am not saying that some 15 year old Linux hacker would have done better, but Closed Source systems which should have been better designed have quite often failed.

I think (and this seems to be a common thread being repeated throughout the responses to this article) that the closed source/open source issue is mostly orthogonal to the idea of trusted/not trusted.

I say mostly orthogonal, since I've never yet seen an open source project with what I would consider a sufficiently formal specification and so on, whereas I have seen closed source systems that do.

I suspect this is a cultural thing, more than a technical issue, but ... hey, isn't that what people have been saying is great about open source?

Cheers, Nick.

Re:I have to agree

[hattig]

I agree. What open source person wants to write some Air Traffic Control software for nothing, something that if done correctly would cost £100,000,000+?

The problem is that many companies aren't actually doing proper plans and specifications, and hence their software fails. This isn't Microsoft, Oracle, etc, who probably have some of the best quality control systems out there, but rather the newer companies, or the companies that haven't kept up.

Look at the specification for Gnumeric:

Excel, but prettier and easier

Great, isn't it? ;-)

Still, I wouldn't trust Open Source to produce any kind of Mission Critical System, that was 100% error free, guaranteed 99.999999% uptime or whatever. Maybe 99.99% uptime though. You have to consider what a mission critical system is though: Nuclear Power Station Controlling Software, Life Support Machines Controlling Software, ABS, etc. In those situations, you would pay a company a lot of money to make something that worked. If they decided that a stripped down Linux with some custom software was enough, then great.

Most companies just like the feel good factor that paying for software gives them I think. They think they are getting more ;-)

I think I have lost the point of what my post was going to say. My brain feels like the Windows registry on my home computer two days ago - completely hosed because I quit IE.

Re:I have to agree

[CodeWright]

Because of the way Open Source is developed it will have less bugs than some commercial software, but it will never be developed to a formal specification using tried and tested Software Engeering principles.

Ummmm....WHAT?

Why not? Open Source != chaotic development.

Just because many Open Source projects are -managed- that way doesn't mean that they have to be. Open Source just means that the SOURCE is OPEN. It is perfectly feasible for a group to engage in rigorous Trusted Systems development, and then release the source code.

DOH!

Re:I have to agree

[keaaw]

Anybody here ever work for a company that produced software commercially? Would you characterize the software development process at your (former) workplace as well-ordered and non-chaotic? I think that commercial development efforts, for thet most part, are more chaotic than, e.g., Linux, because as schedule milestones loom, the pace gets fast and furious and extremely chaotic. The amount of scrutiny of new code, patches, etc. to Linux far exceeds that of many of the places I've worked, so I think the basic tenet of "commercial == non-chaotic" is bogus to begin with.

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.

Amazing -

[Chris Worth]

I find this amazing - so open source doesn't submit itself well to a closed-doors 'expert review' where the experts are usually appointed through a political process rather than a skills one?

Open source's strength is that it's Darwinian. Yes, a program can start off full of holes, but the whole point is that these holes become evident through the development process, and get plugged.

Hell, even I get this, and I'm not even a developer/techie. (Read The Microsoft Matrix" to see what I've learned.

Re:Amazing -

[Schnedt McWapt]

Open source's strength is that it's Darwinian.

People throw around the term 'Darwinian' too much. To many, and it seems you would be an example, it's as if it's a mystical processor. 'The real world' just pounds away at something long enough that it 'evolves' into being something robust and secure.

That isn't how sound products that will thrive in the long term are developed. There has to be someone in charge. Yes, it hurts the feelings of a lot of anarchist ideologues to have to admit it, but having someone in charge of development does matter.

To step outside the metaphor of using the 'Cathederal' and 'Bazaar' as a model of the development method, and look at them as the end product: A 'Cathederal' is a structure built up with great planning and foresight. Cathederals take a century to build, and last for many centures. A 'Bazaar' is basically a bunch of people dragging tents and tarps out onto a flat piece of land. It lasts for maybe a month.

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

Re:Amazing -

[nhw]

I find this amazing - so open source doesn't submit itself well to a closed-doors 'expert review' where the experts are usually appointed through a political process rather than a skills one?

Do you have any evidence to back up this assertion? I've met plenty of people who do independent validation and verification (IV&V), and every one of them has been a tremendously clued up individual...

Open source's strength is that it's Darwinian. Yes, a program can start off full of holes, but the whole point is that these holes become evident through the development process, and get plugged.

That's all very nice, and I'm a tremendous supporter of the Open Source movement in general, but there are some systems where Darwinian evolution is simply an utterly inappropriate design methodology. If you need it to be right, first time, then you want your solution from mathematics, not biology.

There are a few good examples: safety critical systems are an obvious choice; the other, is trusted systems.

Cheers, Nick.

Re:Amazing -

[Art Tatum]

Well, Cathedrals last a long time in part because of the materials used. If they had used wood and plaster, they wouldn't be there right now. Similarly, if bazaars were built out of heavy stone, they'd last a very long time. Either way, the materials used have nothing to do with the analogy.

Re:Amazing -

[hobbit]

I think you may be missing what Chris was trying to say, too. Sure, it's possible to prove a program correct, but 'correct' means that it performs according to its specification. If its specification is not created by experts, it's not secure. The same is true of both open- and closed-source products, but the difference is that open-source products will then undergo further review. It's not about 'enough eyes make all code bugs shallow', it's about 'enough eyes make all specification problems and code bugs shallow'.

There are two roles for experts. To take a well-known example, cryptography, one role is for the mathematicians and the other is for the implementors. Open-sourcing aids verification of both.

Hamish

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

[Kaufmann]

Under that definition, Open Source cannot be a trusted system.

Untrue. It hasn't been done yet, but it's very possible. However, it wouldn't be a "typical" OSS project:

• A contributor would be required to have at least some experience with formal techniques for building trusted systems.
  
• It should use better, more advanced tools for distributed development than the vim/make/CVS combo by which most Unix hackers nowadays swear.
  
• It shouldn't use C/C++. (Ever tried to do closed-world program analysis with C++?) Languages such as Eiffel, which provide better support for formal development techniques, should be used.
  

I would hold up OpenBSD as an example of a system that I consider trusted, yet was not developed under any formal spec

Not to make this seem like an attack, but your personal opinion regarding OpenBSD isn't really relevant to the rest of the world. Right now, having a software system be labeled as "trusted" means something: that the system's developers used the best techniques available to make sure that it could fit the regular definition of "trusted". If we abandon it in favour of "I think it's pretty secure, and so does the general consensus, so why not just call it trusted", the word loses its meaning and purpose entirely.

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

[SquadBoy]

This is using the phrase "trusted system" to refer to the Orange Book specs. What that means is it is not a matter of do you trust a system or not but does it meet the Orange Book specs. If is does it is trusted if not than not. The thing is the Orange Book is a very narrow document and a very narrow spec. Just because a system is not a "trusted" system under the Orange Book does not mean that it is not secure.

Re:it's all in the definition

[jd]

I'd argue that OpenBSD =WAS= written to a formal spec. It's clearly written to the BSD4.4-lite spec or it wouldn't be BSD! Also, "formal spec" is a loose term. To me, the phrase "Any user can use only services they are explicitly authorized to use" is a formal spec. After all, you're defining a pre-condition (input: valid(user), valid(service)) and a post-condition (output: true if allowed(user, servic), false otherwise).

There are no other conditions which comply with the phrase, and those pre/post conditions completely define all cases.

Thus, OpenBSD's aim to be secure out of the box, where secure is defined as preventing unauthorized access to services or data, IS a very formal spec and one that can be tested against.

The problem comes when managerial types define "formal specification" as something with a number attached to it, ISO 9000 compliant development, a rigidly-defined heirarchy of management, an EULA, Powerpoint slides, and a cheese-and-wine party.

NONE of these have anything whatsoever to do with formally specifying anything. Least of all the ISO 9000 stuff. ISO 9000 is the least formal doc I've read in a LONG time. It's worse than useless.

A formal specification is simply that. A specification of what goes in, and what comes out. THAT IS ALL! Specifications say NOTHING about implementation, they are simply definitions of what a given black box does.

Re:it's all in the definition

[arkansas]

The definition in the lecture is a pretty reasonable one for trustworthy. Trust means that you believe software will behave as you expect all the time. This is best handled through a detailed spec. There was an article on Slashdot pretty recently about the code design for the space shuttle (a pretty good example of software that has to be trustworthy). The essence of the article was that the detailed spec and the rigorous adherence to it were big parts of the reason the code was so good. That said, they also pointed out the intensive review process (which open-source may even do one better) was a big component as well.

Re:it's all in the definition

[nhw]

Also, "formal spec" is a loose term. To me, the phrase "Any user can use only services they are explicitly authorized to use" is a formal spec.

Formal specification may be a loose term to you, but it is not nearly so loose to (say) the Department of Defense.

For example, for the higher levels of assurance under Orange Book (DoD TCSEC), like B2-A1, a formal specification is required that allows proof that a system does not violate its axioms. Now, your specification may baldly restate this requirement, but it does not come close to discharging a proof obligation.

For A1-level assurance, the top level specification is required to be highly formal, including the requirement for a mathematical proof of the system, and also a proof that the security policy itself is sufficient.

Least of all the ISO 9000 stuff. ISO 9000 is the least formal doc I've read in a LONG time. It's worse than useless.

ISO 9000 is a quality certification that is about process, not about the standards required of a particular project. There are, however, objective standards (which do have those letter/number names you dislike so much!) which are relevant: things like DEFSTD 00-55/56, ITSEC/TCSEC, DO-178B etc.

It seems that there is a feeling that having a formal specification is simply a hoop that some people have to jump through before getting down to hacking. This is an unfortunate attitude, and (I feel) tends to undo the whole point of making the specification in the first place.

Cheers, Nick.

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.

Re:it's all in the definition

[Chalst]

Nice post, but I'm not sure what you mean when you say the `open
source development model does directly contradict most of the software
enginerring principles that are called upon in the development of
trusted systems'. Do you have a specific contradiction in mind, or
are you just making a an assertion about hacking culture? The latter,
I think, is as irrelevant as an analogous generalisation about most
commercial software development would be.

PS. I note your email address is in Oxford: are you a member of
Roscoe's group?

Re:it's all in the definition

[Chalst]

To me, the phrase "Any user can use only services they are
explicitly authorized to use" is a formal spec.

Does that mean you see no ambiguity in the phrase `explicitly
authorised', or that you think that any way of disambiguating it is
equally good?

Re:it's all in the definition

[nhw]

Nice post, but I'm not sure what you mean when you say the `open source development model does directly contradict most of the software enginerring principles that are called upon in the development of trusted systems'. Do you have a specific contradiction in mind, or are you just making a an assertion about hacking culture?

I think there are specific contradictions, as well as a more general cultural problem.

From the viewpoint of specific contradictions: there is, in the trusted systems world, a certain emphasis on the importance of specification. Now, to my mind, the concept of a formal specification, and of development guided entirely by a codified specification, sits all at ease with the open source development model.

As stated elsewhere, it is the evolutionary advantages of open source development that seem to be their keenest asset; but one important thing when it comes to trusted software is getting it right, first time.

When it comes to getting it right, from a trusted systems point of view, there is also the requirement to prove you have it right. Now, I've never seen an open source project developed using anything approaching formal methods; I would be interested to be corrected on this, though!

To be still more specific, and to focus on TCSEC as a source of authority on what constitutes trusted systems 'best practice', the open source model is almost the antithesis of desirable life-cycle assurance: Orange Book calls for steps to be taken:

to ensure that the system is designed, developed, and maintained using formalized and rigorous controls and standards

This connotes everything I mentioned above, and also implies extremely high standards of configuration management and regression testing. Similarly, there is a tremendous emphasis on documentation, which I feel is a weak point for many open source projects. The level of required documentation for high assurance levels is impressive: not limited to end user documentation, but also security policy and design.

The potential incompatibility between the highest assurance levels and the open-source model is evident from Section 4.2 of the Red Book - Beyond Class (A1); here, one specific area mentioned is:

Trusted Design Environment

The TCB must be designed in a trusted facility with only trusted (cleared) personnel.

I probably needn't say much more about this.

I notice that in that brief survey, I said rather more about culture than I intended, so I'll not make any other points about that; other than to say that I also feel that many 'hackers' just plain aren't interested in doing the boring bits required for trusted systems. Despite the fact that having a DoD/NSA approved system, no-one in the open-source world has done it yet.

PS. I note your email address is in Oxford: are you a member of Roscoe's group?

No; I'm currently working on my Masters thesis, which is concerned with functional programming; I'm supervised by Richard Bird. I notice that you were an assistant lecturer at New College ... you probably know some of my friends!

Cheers, Nick.

Re:it's all in the definition

[jd]

I see no ambiguity in it, except "contrived" ambiguity. (You can argue that I didn't say WHO was doing the authorising, but I don't believe that formal specs have any business moving into lawyerese, in a bid to meet every possible context that a statement can be interpreted in. To me, it is clear that the authorising agent is the person or organisation responsible for that service on that system, and no other. To me, that's straight logic. Remember, computers think in logic, not double-speak. Computer programmers are there to tell computers what to do, clearly, concicely, and logically. Thus, logic makes much more sense than looking for hidden meanings or coded interpretations.)

When a statement genuinely IS ambiguous, but has been given as the pre/post condition pair, then ALL interpretations which comply EXACTLY with that condition (both in the positive and negative) are equaly valid.

Say you have the statement "data must be kept on disk 1". Then the converse of that is "!data must be kept on !(disk 1)". By applying both these, you can conclude EITHER that data is restricted to disk 1, and everything else is restricted to disks other than 1, OR that data is restricted to disk 1 and that everything else can go on any disk. But since your pre/post-condition says nothing about anything other than the data, then as far as that condition is concerned, the "everything else" could be on Mars. In this case, logic would argue that there's no implicit interpretation, so it really doesn't matter.

The way I would always go, though, in ALL cases, is take the most restrictive interpretation of the pre- and post-conditions. You can always loosen up a bit, but it's a royal pain to tighten things afterwards.

Thus, using this axiom, the first conclusion would be the one to use.

Re:it's all in the definition

[Chalst]

It is ambiguous, and non-trivially so: the implementor will have to
make decisions about how to channel bureaucratic authorisation into a
permissions model, and these kind of matters can involve subtle
security issues.

The kind of disambiguation you describe is very simple minded: it
is simply schematic ambiguity, of which the `explicitly authorised' is
not an instance. Even so, I don't think that `most restrictive
disambiguation' is an effectively applicable criteria.

To put it bluntly, the kind of informal specification you advocate I
think is likely to reduce the visibility of potential security
vulnerabilities.

Re:it's all in the definition

[Chalst]

I think there are a mix of advantages and disadvantages to open source
development from the point of view of secure development. I don't
think there are any `contradictions', however.

I'm not sure what to make about the red book criteria: does `in a
trusted facility' mean that if I have some ideas about design of the
code while at home in the shower that the criteria is invalidated? I
can't comment since I am not familiar with its trust model, but it
smacks of `security through obscurity' to me. I doubt that it could
be made to work outside of an organisation like NSA or GCHQ, which is
interesting, but not really the topic under consideration.

I think that the TCSEC criteria are likely consistent with open
source development. What standards happen to prevail in `many' open
source projects really is irrelevant: of course all of what you
describe must take place, and with proper tools. I think I could
imagine a plausible such group of open-source developers.

I have a dim idea that we may have met: did you apply for the MSc a
few years back (1994/5/6?) and then switch to a law course?

Re:it's all in the definition

[EWillieL]

Hmm...

You mention the huge formal spec of the Mondex smartcard system. I didn't know they put that much thought into it.

Hasn't Mondex been broken?

EWL

open source is orthogonal to trust

[Nick Barnes]

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

I suspect that Dr Spafford would agree with you. Whether or not a piece of software is open source is orthogonal to whether or not it can be trusted.

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.

Just because you sell something doesn't mean that it's not open source.

Specifications are not to be trusted

[Diabolical]

If you can actually PROOF that you adhered to the specs that were outlined eveything is okay.. but as with alot of things people cannot be trusted enough to follow the specs. Just look at constructing. If a wiring scheme inside a building can be much cheaper because of cheaper wires they will put those in.. if a company can save money by NOT adhering to the specs they sure as hell will... if you create some specs and afterwards your product seems to adhere to them that does not mean that internally eveything is correct. At least with Open Source you can check that. Of course he is correct at the point of Linux and most other projects being chaos like. That's inherent to the bazaar model of things.. But strongly run Open Source projects with clearly outlined goals and specifications can be as secure as anything else...

Just my thoughts about the subject

Re:Of course - just look at its proponents

[Suydam]

Brilliant, I'd forgotten that the quality of software was dependant on the look and feel....



...of it's developers.

you're either kidding (and it's not really funny) or you're a troll. Outstanding.

Formal Spec?

[BadlandZ]

Well, honestly, this would need more definition to make much sense to me. "Formal Spec" is something written down AFAIK. Depends on who wrote it, and exactly what it says. Without seeing a "formal spec" it's hard to prove or disprove that Linux/FreeBSD/OpenBSD has or hasn't been tested for the potential problem.

Very simple solution, write a "formal spec" for Linux/OpenBSD/FreeBSD/NetBSD, and test. I'm quite sure it would take several people, if not a community, to try to define all the potential ways of testing. And, then, turn the table back around and say, "well does your formal spec test for problem X, no? we have, on a monthly basis, with a programming community in the thousands judgeing the outcome"

Then even if they do test to a "formal spec" you would be able to clearly point out that only from an open community can you really know the weeknesses, and you could never trust a commercial company to release information about where they failed, and where they have problems. Odds are, if they fail on one point frequently, they just rewrite their "formal spec" to not include that test.

Isn't this the job for distro's

[bdeclerc]

If a company like RedHat or SUSE decided there was a sufficiently large market for a "trusted" distribution, wouldn't it be possible for them to go through "formal" procedures. Obviously, such a distro would never be cutting-edge, because of all the extra testing that needs to be performed. It's only if you try to look at all of "GNU/Linux" developement at the same time that you might say "anarchy rules". As soon as you get to the distros, you get far less chaos and far more control of what goes in. I think that such a thing would even be more "trustworthy" than closed source, because afterwards, you would be able to see all the source that went into the "trusted" distro.

Open source = unorganize

[MobyDisk]

I didn't know that open source code meant anything except that the code was released? Since when was a project not open source if it had a specification, and went through bugtesting?

I currently work at a company that spent 40% of the development cycle on documentation, and will spend 20% on testing when the development team completes. So if we release the source code, it's no good?

Point is, just because it is open source doesn't mean you cannot do these things.

He's living in never never land

[Coward Anonymous]

Formal this, formal that. Software development is a black art inspite of attempts at trying to formalize it; From flow charts to design specs to UML.
Formal is nice but it almost never works in the real world.
So far, good design is a result of an ongoing process of trial and error and never the fruit of a first attempt.
Open source takes it to the extreme by creating a massively parallel trial and error machine with a decent "good design" selection process.

Re:He's living in never never land

[markus o'farkus]

>Formal is nice but it almost never works in the real world.

Really? I guess Trusted Solaris is a big waste huh? Shoot, just tighten up the services, shut off telnet, ftp, and rpc and set-up a bank..? No, nothings perfect. But that blithe dismissal of formal standards was a little too much. "Trusted" versions are little bit more than just more secure defaults. They include a mandatory access controls, and suite of tools to help administrators give users and processes (and administrators!) the least amount of privilege necessary. I would be out of my league if I speculated on how close this approximates a true capability-based system (yes there is still a root account so...). But, still, it's a lot more than being on top of your patches.

Notice, I'm making NO mention of whether OSS OS's (that was fun to write) would be better or worse at this. I don't see why they wouldn't be fine! In fact I would think Red Hat Trusted Linux would be a natural and a huge hit. Perhaps they're worried about making their money back... but oh man, just think of the consulting gigs!

Out of couriosity, are there Mandatory Access Controls (i.e. permissions [ok, 'labels'] that even the file's owner may not change) available for OpenBSD or Linux? Something that's polished?

But i tought that open source meant...

[mallie_mcg]

I was under the impression that open source was a way or release not nessesarily development.

By this i mean that the ideoloy behind open source is that the source is available to add/fix/do whatever to a system. So theoretically a trusted system could be open source, the source need only be released.

Would ssh be considered a trusted system by this person, or is this a trusted service instead, and where does that leave OpenSSH in that particular schema of things.

.sig = .plan = NULL;
http://www.alladvantage.com/go.asp?refid=HVZ895

ISO 9001

[a_n_d_e_r_s]

Well the ISO standard defines a formal method of how to construct a program. The fact that a program has been developed using that process should in theory mean that it is bug free.

In practice that basically just means that the formal softeare development process has been described and red-taped. There is a hope that such a process will make it well though of and controlled in such a way that a second project would have come to the same solutions, fully disregarding that design is mostly an art and not a science.

In no way does it in reality mean that the program os more or less bugfree than a bazaar type open source code project. It only conclusion one can draw is that it most certanly exist a lot of documents describing the sytsem - which might or might not describe the actual code.

It also has taken a muck longer period to develop becasue a lot of documents has been produced. But in practice the document are never read anyway since most people who wants to know anything mostly looks inteo the source code anyway - since thay know that the docs never tell the whole truth.

Re:ISO 9001

[CaptainZapp]

The fact that a program has been developed using that process should in theory mean that it is bug free.

Nope, ISO 9000 doesn't guarantee that software is bug free (it's ISO 9002 for software, I believe).

ISO 9000 specifies a formal approach in terms of a documented, reproducible process. How you define this process is up to you. An independent audit just verifies that you follow your own specs and that your specs are ISO 9000 compliant. It does not verify if your processes actually produce good software or services.

As an example (my ex-employer went through this crap) we had documented rules that mandated the documentation to be provided for a project, responsibilities, follow-up, repository, etc...

The irony is that you can very well define that we, pointy haired acme soft produce software which is so crappy that the customer is forced to upgrade because it doesn't really work. To achieve that we have such and such testing cycles. If those tests don't fail the software must go back to development and be broken in 24 hours

In terms of ISO 9000 this is a completely valid procedure and perfectly certifiable. As long you document it and follow the procedure.

OpenBSD

[gfxguy]

But OpenBSD is the real life counter example that he's wrong, unless he can specifically mention a more secure OS. I mean, in order to prove his theory he has to first prove that OpenBSD is not secure. Then it would be nice to have a counter example that fits his criteria.

----------

Re:OpenBSD

[Sanchi]

OS/390 nuff said

Re:OpenBSD

[gfxguy]

Ah...even if OS/390 was the most secure OS in existence, the first part hasn't been met...you have to show that OpenBSD isn't secure.

It seems to me that when OpenBSD was mentioned, the good professor probably didn't know much, if anything, about it, and merely stated one of his prepositions:

because it was not designed to a formal spec, and there are no formalized tests or standards being applied to it.

So it seems to me he's stating OpenBSD, which is probably unknown to him, can't be trusted because it doesn't fit his theory. Oddly enough, most professors follow this methodology! If it doesn't fit their theory, skirt the issue and wave a hand or two and lie (knowingly or not).

My argument is that OpenBSD proves his theory wrong, as one of the most trusted OSs available, and built contrary to his notion of how a "trusted" OS must be built.
----------

Re:OpenBSD

[frost22]

It seems to me that when OpenBSD was mentioned, the good professor probably didn't know much, if anything, about it, and merely stated one of his prepositions:

Actually, I'd be surprised if there's not code by him in OpenBSD from the BSD heritage - even if its only a few contributed paches. Spaf is not exactly a new kid on the block.

f.

development methodology != design and testing.

[Poe]

I don't see that there is any connection between where your code comes from and the specifications it is built to.

A benevolent dictator, acting much like Linus, could accept only code that brings the product closer to the design.

The test suite or testing procedure could be released along with the code. Sure, goals like "ISO 9000 security compliance" are less popular than "a working operating system", but that doesn't mean you have to keep your source closed. And it doesn't mean you can't accept patches that bring you closer to your goal.

Its all about scale...

[MosesJones]

Trusted, Assured, Safety Critical, these are all areas where IMO Open Source won't work. They require a level of discipline and upfront analysis and design that doesn't merge well with release early and often. OSS creates great software for large user bases, however it tends to create products rather than enterprise applications.

The key to trusted, assured or Safety Critical is the specification. You must know in advance what you have to prevent. Its no good after you've lost all of your data fixing the bug that allowed it open.

Re:Its all about scale...

[RedHat Rocky]

Knowing the full specification before writing a single line of code is vapor. You will never have a complete spec. Developing strictly to spec without being flexible for requirements that develope over time is a sure way to end up with a swiss cheese of security holes.

Re:Its all about scale...

[Lozzer]

Unless of course you are working on software for spaceships: Story here

That's not what he said.

[session]

The article didn't mention any bias against open vs. closed source. Actually (if you'd read instead of shouting out OPEN SOURCE ROOLZ just to be cool), he mentioned that more developers looking at the code usually tends to produce a better system. However, open or closed source, if a system is not designed to rigorous specs and tests, it cannot be trusted. I think he has a good point.

It doesn't matter whether the source is open or closed.

Re:That's not what he said.

[KjetilK]

Indeed, but it is a point nevertheless. For my thesis, I'm using the Open Source statistics package R and occasionally Mathematica. Now, I know R has bugs, I have two unresolved bug reports in the bug reporting system myself. Yet, I trust R more than I trust Mathematica. As a scientist, I don't like faith. However, it is exactly what the closed-sourced software like Mathematica asks me to have, faith. With R, I know it has bugs, but whenever my results fail to pass my sanity checks, I can see what the code does, and usually that this the trick, I don't need to trust that the developers followed the spec or did the formal testing and certification, I can see what it does.

After this, and after seeing what some closed source packages does, I really don't have much faith left. Mathematica, however, seems good, I only wish I could dissect the source.

Re:That's not what he said.

[RedFang]

Trust has nothing to do with if you trust the software to work correctly or not. Trust has a very specific meaning when it comes to secure systems. Most likely he has the DOD Orange Book in mind. As far as I know, none of the free OS's have an Orange Book security rating (thats what MS is talking about when they claim NT is C2 certified). The reason for my thinking this is it costs a considerable amount of money to get a system certified in this manner. Up to C2 the amount of documentation needed is not overly burdensome that Open Source couldn't pull it off. Above that (B1, B2, B3, and A1) you need a mathmatically provable design and specification. You need huge amounts of documentation and checks at all points of development. It is possible, but highly unlikely that Open Source could achieve B1 or B2. IBM managed to achieve B1 back in the 80's with a particular version of MVS and RACF. Only one system (at least as of the early 90's when I was writing a paper of the subject) has ever achieved an A1 level. The joke was that the system got it's rating by never remaining up long enough for anyone to do anything with the system. Here are a couple of links for more information regarding the Orange Book: http://www.multics.demon.co.uk/orange/index.html http://jcs.mil/htdocs/teinfo/directives/soft/ds520 0.281.html

Re:That's not what he said.

[UnknownSoldier]

> thats what MS is talking about when they claim NT is C2 certified

Wonder why M$ never mentions that NT was C2 certified when it _wasn't_ hooked up to a network =P

Re:That's not what he said.

[Cratylus]

Because that's implied by getting the C2? the way I understand it, no networked machine can get C2.

Re:Of course - just look at its proponents

[NP]

Eric Allman is the sendmail hacker, ESR wrote fetchmail ...

And yes, sendmail sucks. run qmail or postfix instead.

(I can't belive that I actually reply to such a blunt flamebait ... )

MICO?

[Matthew Smith]

Don't know what exactly a system has to be to be considered 'trusted' but OMG tested MICO against their CORBA spec for free in recognition of their efforts. MICO passed and hence can be legally branded as a CORBA implementation. Could MICO be considered a 'trusted system' then? It was tested in a very formal way.

Re:MICO?

[Kaufmann]

An analogous situation:

1. I release a spec, let's call it "One2000". It consists of only one line, specifically "In order to conform to One 2000, a program must print out an endless string of ones." (I'd probably give the ASCII value for '1' too, just for the sake of completeness.) I register One2000 in all the necessary ways.
   
2. My friend J. Random Hacker writes a program, let's say in Perl: print '1' while 1;
   
3. I (trivially but formally) test JRH's program and conclude that it does, indeed, conform to the One2000 spec. I thus brand this program "One2000-compliant."
   
4. Should print '1' while 1; be considered a 'trusted system'?
   

My (richly illustrated) point is, it's not just about getting tested. There are specific formal procedures involved. It's not as simple as it's made out to be.

Open source has more benifits

[attobyte]

1. There is no greed for money.
2. No need to rush the process (Except KDE and Gnome)
3. Just geeks are working on it. There are not Non-geek asses trying to do what they think the "public wants or needs".
4. Opensource developers are just more cool.

atto

Trusted systems=???

[Surak]

Then what makes a trusted system? What systems would be considered trusted?

Just because something is closed source, that doesn't mean it's developed to a formal specification with formalized testing.

Furthermore, what constitutes a formal specification? Both OpenBSD and Linux derive their security models from the Unix security model. That model *is* a specification. But is it a *formal* specification, and if not exactly what constitutes a formal specification?

FInally, as for formalized testing, I don't know that much about what Linux kernel hackers do, but I'm to understand its a very chaotic environment. I agree with the professor here: I don't think Linux has had formalized testing for *anything*, let alone the area where it matters (security.) Yes, to a bazillion eyeballs all bugs are shallow, but formalized testing means creating a formal benchmark test that puts the program into virtually every conceivable situation. I'm not saying that closed source developers do that (isn't it obvious? look at the number of security holes in the Windows operating systems over the years.) but I do think that Linux, and software development community as a whole, needs serious improvement in the areas of testing.

From what I can see, the proessor's whole gist is this: software development needs develop an engineering culture. Software needs to follow a systems development life cycle (SDLC)where formal specifications (requirements documents) are written up in advance, the software is developed within an engineering culture, and there is formalized testing and user acceptance. These seemingly superfluous controls, especially in the area of infosec, are vital to controlling the inevitable bugs that crop up and to making sure that software meets the requirements.

I think Linux and *BSD at least need to take a hard look at requirements gathering and testing phases and see if there is any room for improvement.

Re:Trusted systems=???

[nhw]

Just because something is closed source, that doesn't mean it's developed to a formal specification with formalized testing.

Absolutely true; the overwhelmingly vast majority of software (be it open or closed source) is not developed to a formal specification with formalized testing.

That said, there are pieces of closed source software which do meet these standards, and are certified to do so; examples of these include the products that the NSA (via the NCSC) certifies as part of its INFOSEC programme. The development of such pieces of software (Trusted Oracle, whatever) is reviewed, the source code is inspected, proofs are drawn up that the security policies that are alleged to be maintained are in fact maintained. In some cases, one even goes so far as to verify the object code generated.

Furthermore, what constitutes a formal specification? Both OpenBSD and Linux derive their security models from the Unix security model. That model *is* a specification. But is it a *formal* specification, and if not exactly what constitutes a formal specification?

No; the UNIX security model does not constitute a formal specification. However, one could quite easily write a formal specification for the UNIX filesystem security model; in fact, it would be quite a simple specification. Formal specifications are usually written using a mathematical specification notation, accompanied by English explanatory notes. Such specifications have the advantage that they are unambiguous, which is a tremendous advantage over English.

However, even if the UNIX security model were to be formally specified, it is an insufficient model to be trusted to any real level. It is insufficiently fine grained at one level, and it is insufficiently strict at another.

TCSEC C2 and above require the implementation of DAC - Discretionary Access Control - which requires a finer level of distinction between users' access priveleges than is really possible with the simple capability bits of the UNIX filesystem, in its original form.

TCSEC B1 and above require the implementation of MAC - Mandatory Access Control - this is all about making sure that 'security levels' on data are respected: i.e. if Joe has Confidential clearance, and I have Secret, I cannot write my Secret data into a file that Joe can read; even if the DAC system would allow me. Similarly, Joe cannot read my Secret files, even if the ACL permissions I have set would allow it.

And that's only half the story: once you have a formal specification of your system security policy, you have to prove that it is invariant. That's tricky stuff, unless you're working from a specification in which it's inherent.

Cheers, Nick.

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.

Re:Two variables

[Hard_Code]

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

Not really. Remember, most of the internet was built on "formally designed and reviewed" "open source" software. Look at the BSD development cycle, for example. It is much more controlled than say, the release-early-and-often-new-micro-version-every-fi ve-minutes Linux world (although significant kernel changes have to be funneled through Linus anyway, save the flames). Open Source != chaos. I think you will find that a lot of the major open source software that has really built the community and lead us here, was built slowly and steadily with lots of peer review, against a standard, by every day engineers...not some random kids moonlighting on opposite sides of the globe.

Re:Two variables

[Iambic Pentametor]

This makes me wonder about bazaar-style design models. I've been observing the Debian system for the last couple of months and it seems amazingly well structured for a completely volunteer effort.

I agree that typical open source design models could yet mature into something capable of developing trusted systems, but can anyone give examples where this has already covered some ground?

Damon

---
We've secretly replaced this mathematicians value of pi with 355/113.
Let's see if he notices!

Re:Two variables

[MattW]

Indeed, I think it would be more appropriate to say that open source is not inherently more trustworthy. In terms of levels of trust, open source alone guarantees nothing. Nonetheless, if I had a choice between a solidly tested and reviewed trusted BSD and trusted Solaris, I'd probably prefer trusted BSD.

Re:Two variables

[Cuthalion]

Yeah, I reread what I said, and realize that it comes accross different from what I meant. "Open Source can be more trustworthy" rather than "Open source can be more trusted". Not that it always is, early on in a project, the opposite is probably true. The real obvious bugs haven't been fixed, and can be exploited. In a early revision closed source project you at least get security through obscurity, which while not a good long-term solution, is certainly a hell of a lot better than nothing.

Opensource is what we wish it to be..

[MikeFM]

I'd agree that open or closed source has little to do with trusted or not trusted. Either open or closed source software can follow strict design guidelines or be flakey. With closed source we get what a company wants to sell us and no way to prove if it is or isn't what we want. With opened source it's exactly what we want it to be. If that means trusted then it'll be trusted because otherwise what would be the point of coding it? The bottomline is that we are in control of our destiny.

Re:Opensource is what we wish it to be..

[Fooknut]

AMEN

Not designed by a suit with no clue, in an office far far away in gondwonaland.

Fook

But how?

[EinarTh]

After all Linux is rather standards-friendly, but I fail to see how one-size-fits-all security design goal could ever be written, let alone implemented.

Think about it. There are somewhere around..what..20 Million Linux's running right now, doing all sorts of stuff, with all sorts of software and configurations, and they're exactly as secure as their weakest software and/or config file.
Bottom line: The OS only brings you a mechanism to implement _your_ security policy and nothing more!

Re:But how?

[Peaker]

That does not make the OS's job any less important for achieving security.
The policy Linux and other OS's (with or without formal specifications) provide as a security-frame is very weak.
A much stronger mechanism is EROS's. EROS is an OS created as a research project, and is most probably providing the most secure mechanisms that ever existed.
Surprisingly enough, EROS is now under GPL, yet it is not currently developed using the 'chaotic' opensource model.
However, it also does not conform to 'formal' specifications that I know of, but rather creates specifications of its own (whether or not those are formal, I do not know to determine), and some of those were proven secure.
I think this strengthens the point that was already mentioned - the release model (opensource VS. closed source) is not at all related to how well the design was tested and designed. While it is true that testing a design and creating solid specifications for it helps to achieve better security, it is not, as the professor says, related to the distribution license.
In addition to the development model, the release model is also linked to security, but not in the way the professor mentions. Opensource releases increase security and reliability, and so do formal tests and specifications. The combination of both is what we should strive for.

formal seems to be the word here

[Fooknut]

It looks to me like he wants "formal" and "formalized" testing and coding.
That's just about as irrelevant as saying that the coders must not drink coffee and must wear purple zoot suits. Code is code. If it works well it works well. The end user doesn't care at all about who wrote it wearing what or in what environment it was written. Open source is open. that means it's a TEAM of people working on it (the good ole, more minds makes better code idea)
More coders means more ideas, more coders also means more testing and more code review.

if Windows was open source, it would not be released with 65k bugs.

People can keep putting down open source and the excellent products that derive from open source, but open source will continue to thrive. these open source products that keep the web running will still be the best.

limiting your code to "formalized" yadda yadda blah blah blah will not make a better product in less time.

Fook

Re:formal seems to be the word here

[Kaufmann]

Ahhh, I see the New Jersey mentality is at work again. "If it works (however marginally), why bother getting it right?"

No wonder so much software sucks. I wonder how long a civil engineer would stay out of jail if he went by "if it hasn't fallen down so far, why should we bother making sure that it won't?"

Re:formal seems to be the word here

[UnknownSoldier]

> see the New Jersey mentality is at work again

Hey, I lost my link to why that "why good is good enough" by Jamie Z... on why Unix/C was good enogh.

Anyone know the url I'm talking about?

Two points

[Frodo]

1. Open Source and Bazaar development is not the same. Indeed, Cathedral development might be better for systems with rigid specifications and well-defined goals and functionality. Just most products out there aren't like this - you can never know what you'll have to support until users try first version and say what are they lacking.
And I'd expect from university doctor to have research on differences between Open Source and Bazaar development before giving lecture on the subject. Or is it /. misreporting?

2. Most commercial companies are even more unfit for trusted development than the Bazaar. The reason is simple - they are driving by profits, and if release date and "doing things right" contradict - the latter will almost always lose, and marketing will push product out the door and say "we'll fix it later, it works good enough for 90% so 10% will be fixed afterweards". The only real way that I see trusted system can be developed is open academic environment - Open Source Cathedral style with lots of peer review. This puts chaotic component under control and allows to use it for moving into well-defined direction.

why not open source the test procedures

[matthew_gream]

There seem to be two distinct issues: (1) the lack of a formal spec against a formal test procedure; (2) the nature of open source software and protection of security by obscurity.

(1) Perhaps a formal test procedure could be created. It could even be a commercial opportunity. Even better, it could be an open source project itself, drawing from the best minds, and open to the scrutiny of all. This could be similar to encryption standards where algorithms are available to all.

(2) Perhaps there is a view that at least with the source code 'closed', then black hats cannot analyse the code. I would argue that black hats do have access to source code for many operating systems, perhaps even the trusted ones. I'm not sure I can weigh up the pros and cons quickly off the top of my head.

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

Re:Definition of trusted

[MagnusDredd]

Check out Trusted BSD.
They are Targeting Orange Book specs. If I am not mistaken Orange Book is the government's defintion of Trusted.

So what's the problem?

[JimPooley]

Ooo! Ooo! Someone criticising our beloved open source!
Must be a Microsoft drone!
Let's run him out of town on a rail!

What IS your problem here?
For example, I feel a lot happier knowing that computer software used for aircraft is designed in a strict formal method under close supervision. The kind of "trusted" system defined here.
I would feel a lot less happy had this software been designed by Joe Bloggs and Sid Snot in their spare time, with no formal checking done...
Open Source is no universal panacea - for some things you NEED a solid programming team under constant supervision, using formal methods.

Closed==Open for high level security audits

[Foochar]

One of the big problems with the classic open source argument of "you can examine the source" in the "trusted" market is that it dosen't apply exclusively to open source projects. The bucks for this kind of thing are substantial enough that even M$ will open the source up to the auditors. On top of that the cost difference is not as substantial because the cost of having the suytem audited has to be figured into the TCO.

Also, like many people have pointed out development cycle time is less important because of the large time constant involved in testing. Basicly if closed source can get a release out in x amount of time and open source in x/4 time both will require c amount of time to test. While becomes negligble for sufficently large value of x, sufficently large value of x results in massively obsolete code.

The best way that open source can get a solid foothold on the trusted systems market is with the production of quality systems. If it does the job better then anything else on the market then people will use it. If it dosen't then they won't.

Trusting trust

[NP]

I think that it could be worthwhile to reconsider Ken Thompsons all time classic Reflections on Trusting Trust in this context.

Peer review (as one of the streanths in opensource) won't alone give you a secure system, there are far to many other factors to be considerd. Peer review is however one very important factor.

Depends on what "trust" means

[FascDot Killed My Pr]

In the mathematical sense, he is right. If you start with a formal spec that can be tested (crypto-mathematically) to be safe and then implement that spec rigidly (testing each component) you can use some definition of the word "trusted" to describe the outcome.

This is probably the same method Bill Richardson advocates for keeping nuclear secrets safe.

You could also skip a little on the formality but add a buttload of real-world testing. Throw in a sense of honor that feels personally offended when a bug is found. Then mix in some "many eyes effect". Now you have something that you can't PROVE safe, but at least you FEEL safe.

Now before you respond, be aware that, Bill R ref aside, I'm not saying "those ivory tower fools don't know what it's like in the real world". What I AM saying is that formality, like scientific theory, is only as good as the real-world experiments that bear it out.

I also think that Linux could benefit from a little more...structure. There are some projects that are doing audits, but we all know it's better to design security in, not QA it in. However, I think Spafford is underappreciating the Open Source Way.
--

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

[saltyhog]

Forget the whole more eyes less bugs stuff. I trust open source for the simple reason that development is decentralized, yet structured (at least in OpenBSD's case). With many developers, you only have to trust that people are working in their own best interests - that is, if you accept the perhaps shaky notion that it's harder for developers to introduce backdoors when other developers are watching, even though there are more developers who may possibly introduce said backdoors.

Re:Apologizing....

[TheReverand]

Maybe I've just been lucky, but working for a smaller company, we have a few coders and we've all been together for a long time, and we all have a vested interest in our software succeeding. Maybe this is different than other places, but I will trust the people I've worked with and known for years over some hacker I've never seen. Maybe s/he is a better coder, maybe not, I wouldn't want to take that risk.
Then again I am probably being paranoid as we design Phone System software and aren't quite as worried about security.

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.

Re:Apologizing....

[Chalst]

Well, if you want a software system to be secure, then there's a lot
of components you have to trust, like OS kernels and compilers. No
one designs and implements these on a per contract basis, so everyone
depends on properties of generic tools.

Spafford surely is right: security can't come just from being open
source. But I think being able to look at the relevant source code is
a very powerful advantage when trying to design secure systems.

Re:Apologizing....

[seaan]

...then there's a lot of components you have to trust...

Good point, and it is true for all security system designes. Actually most of the really high security systems are not just "software". The most common type is the "Hardware Security Module" (HSM) industry, which includes secure sections in everything from smartcard to tamper-resistant boxes.

You can use off-the-shelve compontents without them also having to be fully ceritified, so long as the way they are used is carefully constrained. The FIPS 140-1 standard shows some good examples. If the compiler is used in a trusted environment, and produces objects that are run in a limited set of circumstances, you can evaluate those circumstances in place of trying to get a certified complier.

For example, if you are building firmware for a smartcard, you don't have to have complete trust of the compiler. This presumes the smartcard has a reasonably small amount of funtionality, is well tested, and has the code masked at the factory.

The only acess to the card is through the API you designed and tested. Since there are limited features, and the access is not through a generic environment; you can rule out all but the most targeted and sneaky trojan attacks. Even these can easily be found if you inspect compiled code (a routine practice at HSM companies).

As the project gets bigger and more complex, and as you start dealing with untrusted hardware; these types of attacks become much easier.

Re:Apologizing....

[Chalst]

Well...not really. Smart cards are kind of an unfortunate example,
because there have been so many `out of the box' attacks launched
against them. Eg. it is perfectly practicable to crack codes in
most RSA-based smart cards by analysing their power consumption.

That's not really the point you are making, but it shows a problem
with pure hardware-based systems. It may well be the case that the
highly modular designs in PC systems might be harder to attack with
these kind of attacks due to their complexity, but saying so seems to
be anathema to many in the security industry...

Re:Apologizing....

[GregWebb]

I'm sorry, but you miss the point. As long as people keep thinking this is about security, we'll never properly understand the requirements for a trusted system.

The whole point here is a system where you can trust that its functionality will conform precisely to the specifications. It's not security or trusting that there aren't back doors, it's trusting that it will do what it's supposed to. That may include security features, but that's not the point.

I'm sorry if this sounds awkward, but a lot of this topic is showing a basic ignorance of some aspects of software engineering by 'open source' fans and / or developers.

Chaos In Development

[buzzcutbuddha]

"His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state. "
Having worked on several projects at different companies I believe that almost every product is born in chaos, especially towards the end of the development cycle. I would think the measure of whether or not something should be trusted is if the coding follows a standard, and is tested rigorously by users till it breaks so it can be fixed.

Two sides here

[drnomad]

There are 'formal specs' and there is 'implementation'. You can have a good 'math-proven' formal spec for authorisation / security / encryption etc. The way it's implemented can be the weakest point - like the Xing DVD player.
There's another issue: a burgular designing a lock uses his own expertise to build a better lock than those made by other manufactors.
Third thing is that 'formal specs' are specs made by people with a lot of expertise, their expertise can be outdated, there expertise can be limited. My guess is that 500 burgulars implementing a lock can build locks more secure than 10 burgular veterans designing a lock far into their burgular-retirement days.
Ofcourse, with everybody with their eyes into the lock design prevents the assholes for building in a back-door, or an auto-connect-send-some-customer-information-to-Mat tel component.
The guy forgets one thing in my opinion: those formal specs are made by people!

Trusted systems or secure systems?

[Znork]

Without hearing the seminar it sounds as if Dr Spafford is talking about Trusted Systems, not security in general.

Trusted systems are usually of the kind where every action is auditable and traceable; system administrators do not have access to delete logs or change audit trails, etc. The 'trustiness' and 'security' of these types of systems is rather designed through system architecture and specification of how, exactly, everything works, and very strict definitions of security access and permission. Bugs and exploits dont even figure into wether or not the system is 'trusted'. It's a measure of how it works; ie, your sysadmin cant add a $50000 bonus to his salary in the economy system (he probably cant even access that data) and wipe the logs of his doing it, bugs notwithstanding.

Of course, no commercial or free 'standard' unix lives up to that, simply because of design (some trusted unix-like systems do tho).

Which, I think, would be his point; no open source OS currently exists that implements something like that, and the usual design methods in opensource favour functionality and features above things like total fascistic control and auditing of every action taken in the system.

That is not to say an opensource model wouldnt work for a trusted system; it would probably even be better, but bugs are irrelevant to the very idea of wether a system is considered a Trusted System or not.

hmmm

[nlabadie]

Hmmmm, let's think here. I'm sure Microsoft goes through a very thorough and controlled (in their mind) testing phase, and look where it gets them. I don't know about you, but if my car got recalled 6a times (soon to be seven), it would be deemed unsafe to drive. 99% of the time the most controlled and tested products still have all of the same bugs. You need to throw in a chaos factor for a product to eventually become stable.

It maybe the real world but...

[FirstNoel]

Formal specs are a god-send IF you ever get them. Programming by trial and error has got to be the most anti-productive way of working. I've done both, and believe me, with formal specs it makes the writing, debugging process awhole lot simpler and cleaner.

To use an example, I typically write code for manufacturing systems. IF I'm lucky my spec consists of a Post-it note with some chicken scratch on it. It ususally takes a long time to hash out all the "actually specs" of what the user wanted. On the FEW occasions I did get a formal spec, it took half as long to write the code, and hardly any time to debug it. And to this day those are the only programs I don't have to keep going back and "adjusting".

So, yes, in the real world, typically you won't get specs, clean room tests.... But that doesn't mean they aren't important.

I wouldn't want a Structural Engineer building a bridge by trial and error.

Sean D.

Re:It maybe the real world but...

[Peaker]

I wouldn't want a Structural Engineer building a bridge by trial and error.

This is quite a foolish thing to say, because the analogy is compeletely invalid. A program design that fails results in a few hours, or dozens of hours of reprogramming, whereas a bridge design that fails may lead to quite a lot more.

Re:It maybe the real world but...

[sqlrob]

Oh?
What about the software in...
Life support machines
Airplanes / the Shuttle
Nuclear power plants

Anything failing here can be catastrophic, possibly more so than a bridge failing (wasn't Bopal due to a bug?)

Re:It maybe the real world but...

[g1t>>v]

> A program design that fails results in a few hours Me disagreeink. Like that bug in the mars explorer stuff where the one team used inches and the other centimeters ... that was *not* noticed after a few hours of programming methinks :-) So formal stuff could be of use also for software. Still don't know really what kind of formal stuff is to be used though (you can go pretty far in that direction).

Re:It maybe the real world but...

[Coward Anonymous]

You misunderstood what I wrote. I'm talking about the "development of software". To me this means everything from the first napkin drawing, through the design specification to the actual act of programming it to work. This whole process is a black art, from the napkin to the code.
The only time software development is not so, is when you are developing a limited variation on something that has been done before.
Bleeding edge software development is always trial and error. If it were not, there would be no dotcom corpses floating around.

Open source

[boligmic]

You guys might want to listen to this guy, its Purdue for Christ's sake. I went to Purdue and the more I work the more I realize that most other educational institutions can't come close to Purdue. This guy is on the right track. Mike BS IM/MIS 97

It isn't Open Source he has a problem with...

[Spudley]

This isn't so much a problem with Open Source, it's a problem with the way some open source projects are developed.
It's perfectly possible to have an open source product which has rigorous development standards imposed by the central source maintainer. That just isn't the way Linux development operates.

With Linux, he's basically right - the development is very chaotic, and there is almost certain to be a problem with trusing it in the way he wants.
However, there are other projects which, though open source, still maintain a strongly structured development.

The things to consider here are the number of developers, the number of independant versions, the licencing restrictions, and the amount of control excerted by the central source maintainers over the development process.

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.

Re:Understand what "trust" means.

[Chalst]

So far as I know, no one has ever proven a usable compiler correct. So a fully formal proof is just not an engineering feasible.

Trust

[tkrabec]

I feel that open Source can be trusted, because we have the opportunity to check the code.

"His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state"
Order and patterns are found in chaos all the time, fractals.
What makes him think that the "closed Source" software is developed in any less of a chaotic maner? Just because we do not know does not mean it is done in an organized manner

Re:Trust

[Detritus]

I feel that open Source can be trusted, because we have the opportunity to check the code.

Check the code against what? Besides looking for obvious bugs, how do you verify that the code meets the requirements if they have never been written down?

Re:Trust

[tkrabec]

besides obious bugs you can check for back doors and the like. even if the origional specs cannot be checked you can see if it meets your requirements. If not you can change it

Re:Trust

[ekidder]

What does linux do? What does any piece of software do? To re-say what was said earlier, how can you determine if a product is working properly when you don't know what 'working properly' is? As a real-world example, I was recently tasked to modify some software we use inhouse. This was a verbal tasking of 'make sure the software conforms to the spec'. I demanded it in writing (CYA) and realized soon after that the specification was broad and almost impossible to test. So, I put everything on hold (effectively going on strike :) until I was given a specification that could be tested. Why? Because otherwise, there's no way to determine if you did it right.
Now, here's a question for you, concerning the obvious things you were talking about: what if the specification calls for a back door? (Ignoring the fact this may be bad design..) and that part of the code was taken out? Suddenly, your code does -not work to specification-. Therefor, it cannot be trusted to work properly under the situation it was designed for.
That is what it was all about. It's not open vs closed, it's more like orderly vs chaotic (bad example, I know..), as has been said so many times, but I felt the need to post something because I don't have anything to do today :)

"Secure", and "Trusted" are not the same thing.

[jfrisby]

We think of Linux and Open Source projects as being "secure." They are safe from most attacks in general... Once a problem arises, it is quickly fixed by the community -- and it is very likely to be found quickly.

The problem is that "trusted" within the infosec community means that you can reliably assume in a beyond-mission-critical environment that the system is totally secure from attack.

This means a careful, meticulous design, and very rigid, formal implementation and testing. The aspects involved are far more comprehensive and cohesive than Open Source generally considers...

We look at Open Source software in terms of the safety of a package. Sendmail is not secure, or QMail is secure, and imapd is not secure or... You get the idea... Building a trusted system means looking at the big picture -- as low level as how kernel data structures are defined and manipulated, to as high level as individual file permissions and pretty much everything in between...

IIRC, "trusted" Solaris tends to lag a couple versions behind the general release of Solaris and takes a bit of a performance hit. Why? Because it takes a lot of time to evaluate, and fix an OS to make it "trusted."

A simpler way of looking at the difference is this: A "trusted" system goes to great lengths to meticulously ensure that no edge cases exist. A "secure" Open Source system takes the shotgun approach: With enough monkeys pounding on enough keyboards for a long enough time you'll get the works of Shakespeare... Translation: Open Source counts on enough talented, skilled developers working on a project to cover all the cases without anyone specifically telling them to do so.

In the end, Open Source may or may not come out with a product whose security matches that of a "trusted" system -- but you wouldn't be able to recognize it if it did come out. You couldn't *verify* it.

-JF

Re:"Secure", and "Trusted" are not the same thing.

[demi]

I agree. I was going to post a message with this Subject: but jfrisby beat me to it.

And, to bring things to a more concrete level,
the kinds of features in a trusted system, like Trusted Oracle or Trusted HP-UX, are simply missing from any open source OS, secure though they may be. For example, trusted HP-UX provides the rich auditing facility and DAC (discretionary access control) required by TCSEC level C2, OpenBSD has none of these.

Chaos

[Bongo]

Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state.

Please, don't bring Chaos into the argument. Does he understand chaos? Does he know what chaos is? Life evolved out of chaos, creating everything we know. How does he profess to understand the complexity of Open Source development without inquiring further into it's nature? What hidden jems of intellectual development are manifesting within this post-modern matrix of meme exchange? Does he really know?

He could have called it "random", but he called it "chaos". He acknowledges it's all beyond him. He doesn't "trust" it because he doesn't understand it. QED

Re:Chaos

[Sanchi]

chaos

1. a state of utter confusion or disorder.
2. any confused, disorderly mass
3. the infinity of space or formless matter supposed to have preceded the existence of the ordered universe

I think he ment 1 and 2. Not 3

Re:Chaos

[Bongo]

1. a state of utter confusion or disorder.
2. any confused, disorderly mass
3. the infinity of space or formless matter supposed to have preceded the existence of the ordered universe

I think he meant 1 and 2. Not 3

Yes, I guess you're right.

Another question is whether OS development is really 1 and 2, like he seems to think, or whether it's more like 3.

Re:Chaos

[Bongo]

3. the infinity of space or formless matter supposed to have preceded the existence of the ordered universe

Although, to think about it, your no. 3 is not the chaos I meant. I mean more a sort of deep order that on the surface seems too incomprehensible, and hence 'chaotic'. His opinion that 'trusted' has to be formal is maybe 'offtopic'. Maybe a better question to ask is whether we can find evidence that the surface chaos of OS does indeed bring forth a more 'ordered' system than what his formal methods could produce.

If someone made a complex system...

[Alex Belits]

...completely adhering to specs, it probably would be trusted. However no one ever done that -- even systems that are supposed to be "trusted" contain parts that aren't. Probably some embedded stuff can be "trusted", however it's the place where security problems are the least important, and only proper behavior with certain hardware is necessary -- what is much less of a challenge compared to, say, HTTP server + operating system, desktop environment or even a router. If people had many decades for the development of each version of operating system, switch from "chaotic" development to formal specs and proofs that a piece of code adheres to them probably would improve things, however this is not the case, and even if it was, it's possible that specs would end up being developed even slower than anyone would be able to follow then, thus slowing the pace of development to a halt.

question authority

[Capt. Beyond]

trust no one.

Ahem, "rush-to-market" and "post-release support"?

[BitMan]

The ~4 phases of software engineering:

1. Requirements and Design (5%)
2. Development and Coding (5%)
3. Testing and Recoding (5%)
4. Release and Support (85%)

First off, it's really up to the programmers whether or not formalize their organization and follow the two and even third rigorously. I think he has made an analysis that all Open Source development is done in an unorganized, non-traditional software engineering environment and all commercial development is.

But let's say for a moment his assumption is correct. This brings me to the last two phases.

In stage three, commercial interests can drastically cut short the testing phase. The "rush-to-market" attitude prevails as software quality takes a back seat to profit margins -- the great conflict-of-interest that greatly reduces consumer benefit of the product. Vendor's release early way to often. A common misconception is the fact that while the "release" of an OSS product is less definable, because the source code has always been available, if software bugs are inherit to programs, why not always always make it available then? I think he fails to realize the testing _and_ recoding are inherit in use of an OSS product. And OSS projects still have to have the traditional "feature freeze" milestone to move even close to production quality. Unfortunately, commercial software cannot be recoded by consumers once released which makes it actually less tested than OSS -- again, especially if it falls victim to the "rush-to-market" mentality of most commercial software firms.

Then there's the final stage, which is 85% of the traditional software engineering model. Unfortunately, in today's shrink wrapped software world, it has been reduced to 5%. Why? Because there is basically no revenue stream in fixing commercial, shrink-wrapped software. As such, it does largely go unfixed, only being bothered with if a large volume customer complains enough and is paying several millions or tens of millions of dollars in support costs. OSS support never ceases because there is no set "release" of code, it's always been released. As such, OSS is in a continual state of support.

And that final stage is the biggest point. Again, the traditional software engineering model has always been about 85% post-release support. Only those design teams, whether they are OSS or commercial, who are driven by post-release support (either ethically or even financially) can accomodate this most important phase best. That's why when RedHat and other vendor's say "service-focused software firms" are the key to good software products, they are hitting the mark!

The days of rushing the 3rd phase and ignoring the 4th phase of the traditional software engineering model are over. OSS is here and it's our best chance at releasing quality software because it's inherit design methodology accomodates all phases of the software engineering model, even if it lacks an "official source code release" and the code can be chaotic at various points.

But even the concept and problem of the "choatic code state" is debatable. I mean, do you trust software just because it has been "officially released"? Or do you at least hear some peer-review before using it? I think the later applies to the adoption of all software more than the former.

-- Bryan "TheBS" Smith

Someone Needs Glasses

[Cylix]

I have a question for the good Doctor. Exactly
why does open source equate to a chaotic development model.

This is a wholy unwelcomed generalization...

Simply distributing the source code to an
application and attaching a very friendly
license does not say a damn word about the
process used to develop that software.

Take for instance OpenBSD, Q-Mail, ProFTPd.
Maybe they have various licenses...bsd license,
funky q-mail license and the gpl. But they are
mere examples of a group of people or individual
developing with a strict model of security in
mind.

I do believe the good doctor needs a new pair
of glasses. Obviously he hasn't had an
easy time reading or he would not have much
such a horrid generalization. He would have
read about some of those wonderful teams out
there working towards our benefit.

Silly professor, generalizations are for kids.

Proving what?

[LondonFish]

Formally testing a system against a set of specs at most only proves that the system works ACCORDING to those specs

In my experience writing a set of specs that cover every single possible problem (bugs, features, security holes..) is next to impossible.

A closed source security system which perform according to a resonable set of specs could still have problems, and even nasty little back doors.

That said, it doesn't mean that formal testing doesn't have a place, even (or especially!) in open source projects.

Simple things like the OpenSSL test suite which can be run every time you compile up a new version can be very useful, just think - you have a set of tests you run every time you build that can spot straight away if you inadvertentently break something

And I bet that having the Java Compatability Kit to run against has helped the people porting Java to Linux and BSD.

Just ask youself - what exactly to the tests prove?, before starting to rely on then

Is there BETTER model ?

[arhuman]

I mean a lot of computers pass their "ITSEC"/"TCSEC"/"Critères Communs" test and appear to be vulnerable. Even those models seem flawed to me in a sense that they tend to make people think that once the test passed the system can be trusted !!! That's wrong for many reasons : 1) A computer secure at a time may be insecure later as a new vulnerability appear. (I know that periodic audit is part of the certification, but can we trust the audit process(Is it really up-to-date?) 2) Security isn't only the hardware/software, most people underestimate the human factor which is to my mind by far the weakest point of the security chain. (Even those (maybe certified) MI5 laptop where lost...) 3) those formal system models can't be 100% sure (think to godel theorem...) I've read in a book (orange book?) : This system must be proven without any kind of covert channel ! How can you proove that ? Were the boxes in 1980 tested against TCP/IP covert channel ?(Read G. ROWLAND excellent article !) So the real question to my mind isn't : Can open source be trusted ? but rather is there a real formal method to certify that a computer can be trusted ?

In real life the rools are diferent.

[Forge]

Experience has shown that being tested and certified against a spec. Any spec is no guarantee that your system actually meets the goals of that spec. I.e. Windows NT is posix compliant. That doesn't mean porting a posix app to NT is a trivial task.

There are systems that are certified with various security levels according to DOD standards that the military refuse to use at those levels. Reason is that while a formal test bed will by it's very nature be limited in scope and consistent in the number and type of attacks it seeks to evaluate a real world hacker / cracker has no such rules. His goal is simply "Break this system by any means necessary".

I don't think you need to worry too much about Linux being a trusted system. If it ever gets to the high security standards of OpenBSD it will become the system of choice for the paranoid. Until then Open BSD is that system. No amount of certification and trust heaped on other systems will change that.

You see admins who must deploy trusted systems are evaluated in a different manner from managers generally. Did our system get "owned", "Rooted", "cracked" or otherwise compromised under your watch ? Can you tell us how many people tried and who they are ?

If you can't look smug answering those questions but can say "we have deployed trusted systems" you are out the door. It really is that simple.

Another point is that the definition of Trusted System includes the development process. How can you fit into the category without following that development methodology ? So far it seams you don't. Instead you force others to redefine the category so that you fit in. I.e. Right now lots of vendors are redefining "Unix" with the goal of including Linux. Linux taking a larger market share than all other Unix systems combined was no small part of this.

PS: Changing the development process on Linux isn't relay an option.

The doctor's view is quite an intellectual one!

[ubi]

I totally agree with the body of the Slashdot article. To pair Open Source and "chaos" may be acceptable from a certain point of view, but to state that commercial products come from a "serious" production environment is disputable by anybody who works in the IT industry, where usually the lack of time and and any sort of quick-and-dirty practices live.
From the "artisan" of software, that made the history of IT by writing custom code for single machines, and who often became unreachable after a couple of years (like his source code from him, erased from the messy piles of diskettes), to the most modern firms, whose SW products often come with bugs so evident that just a fool would think may pass a serious, basic quality test -that's to say, it never underwent any quality test-, the IT commercial industry could not provide such controlled development of software.
I'm sorry for speaking such words like I'm saying something against my collegues, but there is really nothing like that: we all know that there are so many external factors that make usually impossible to test software at the desired level, the level developers really would like to come.
Think about the history of security algorithms, that displays how "close" means real threat, and of how companies and organizations have probably been aware of the limits of their code but went on confiding that such limits could not be discovered -or not in a certain of time-. Would this have ever been possible in an open source environment?
Not to mention the poor quality of support that's often met when asking companies to solve a problem with their products... Open source gives a chance to ask somebody else for help, real-time help, close products do not.
I think that the view expressed by the man who criticized open source in favour of commercial products has a point -yes- but much more "intellectual" than practical.
I will partially agree with him the day that 90% of the software companies will provide what he's talking about, presumably when the whole process of SW making, included test and support will be rewarded as much as really due...

Is *any* system secure then?

[Mekanix]

Not that I no anything about the subject.

But doesn't the rejection of NetBSD as a "secure" system imply that *no* system is "secure"?

Bjarne

Isn't it a matter of definitions?

[Darth Yoshi]

Excuse me, my coffee hasn't kicked in yet, but isn't this a matter of definitions? That is, levels of "trust"?

Oversimplifying a bit, a "TRUSTED" system might be "built according to a formal specification and are tested and confirmed against a formal testing and standards process", a "Trusted" system might be "tested" secure, and "trusted" might mean "no known vulnerabilities". Under those definitions, Linux might be "trusted", and OpenBSD might be "Trusted", but I know of any operating systems offhand that would be "TRUSTED".

So I think Dr. Spafford is right. Linux isn't a "TRUSTED" system under (what I interpret to be) his definition of "TRUSTED". I think your interpretation that since Linux can't be "TRUSTED', therefore it can't be "trusted" is mistaken.

Hmmm, I think I'll get another cup of coffee and reread that.

How can you trust closed source?

[epcraig]

YMMV, but I cannot trust source code I can't see.
If I can't see the code, how am I to know it was coded as designed?

Open source is compatible with formal proof.

[renoX]

At least for the design: Eros is an OS which is GPL'd and its security model (based on capabilities) has been demonstrated secure with a formal proof.

Of course demonstrating something with a formal proof is different from using formal spec and formal testing. But that's a first step.

Now can open source use formal spec, formal testing, etc?
I don't know but given the current mindset (use C because it is the most well-known language, patch now and release soon to fix later), its seems quite unlikely.

I Agree

[LaNMaN2000]

I have to reluctantly agree. Even if the official release of a given OS project could be certified, the fact that anybody can download the current code and insert back doors before compiling makes it impossible to determine whether the version of XXX that *you have* is actually secure. In addition, somebody could introduce security holes in a new feature that they develop and, unless somebody else is able to discover them before updating the CVS tree, somebody could download it along with the "current development release."

The only advantage I see to commercial software is that the releases are controlled. The code is not released to the public outside of clearly defined production releases. This ensures that interim security problems are repaired before anybody encounters them. In addition, binaries can only be obtained from one set of source code and from one trusted source. With OSS, anybody can download the current source, insert malicious code, compile, and then distribute their version as if it were the official release.

Any company that would certify OSS risks damaging their reputation should a version of the code they certified surface with a back door. Of course, that was not the code they reviewed, but the bad press they risk receiving would inhibit any desire to certify the security of OSS.

rapidly evolving standards?

[denshi]

My complaint with Dr. Spafford's position is this:
Most present work in the web world now, where the standards are often implemented & written simultaneously. Laying aside complaints of poor design for a moment, I have to point out the problem here; Dr. Spafford defines trusted (ie, secure) systems as ones that pass "a formal testing and standards process". But are the attacks against web systems laid out before the system is built? Often, NO! So we have a conflict between how we're writing systems, and how Dr. Spafford defines trust.

Addressing more specifically open source, I want to point out the overwhelming portion of the web that runs on open-source. A primary reason behind that is that closed-source, desktop developers are very good at cloning systems, but don't do so well writing innovative products. The best stuff we have for web services are open, primarily written or extended in order to fulfill a specific need.(yesterday an interview with Brian Behlendorf was posted - a fine example) Fanning the flames here, often the standards developers either contribute or write these systems -- which definitely garners my trust. These systems are going to continue to evolve rapidly. No one here can or will wait 2 years for: freeze the standards, theorize attacks, design the system, write the system, test the system, release-and-now-keep-that-system-until-we-release- the-next-one-2-years-later. So under the circumstances, I trust open-source systems collecting contributions from standards developers rather than closed-source developers with unseen and possibly out-of-date code, lagging behind.

Point 2:
Spafford has a faulty argument. He criticizes all open-source development on the grounds of how several well-known projects are managed. Let us remember that the sets are not equal. The definition of open-source is a hell of a lot larger than, eg "how Linus runs things". I hope he recognizes that; I for one never again care to work with, extend, or support a system I cannot see the source to. You may trust your vendor, but more options are never a bad thing.

Open can be trusted, but...

[Kefaa]

Trusted Systems are built according to a formal specification and are tested and confirmed against a formal testing and standards process.

Trusted systems are tested and confirmed against formal processes. Formal specifications can go a long way in identifing flaws, but would hardly seem a requirement.

Until open source many of the specifications & design documents were considered propriatary or corporate secrets. Open source provides a method to ensure systems are being built exactly to specification. Otherwise, we are trusting the developing entity has actually coded what was defined in the specification.

How often has anyone coded complex systems EXACTLY to specification, the first time? With an open source system we not only know, but can correct those issues as quickly as anyone finds them.

hrm

[jbarnett]

*cough*cough*cough*cough*cough*cough*cough*

Sorry, I got a bad cold.

OS development model != open source code

[lukel]

His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state.

This doesn't really seem to a question of whether trusted systems can have open source code - clearly they can. All that's needed is to develop a trusted in the traditional manner then releases the source code and this need not endanger the system's trusted state.

What I think would be a fairer reading of his claim is that a decentralised development model with different developers doing the bits that scratches their itch is not the best way to meet a set of centrally determined formal specifications. But then this is a question of how the system is developed, not whether the source is open. Paying a bunch of programmers to meet the formal specifications and opening the source so that others can spot bugs doesn't seem to be a problem.

Maybe, if all the design goals were centrally determined, outsiders would be less inclined to contribute, so the benefits of open source would be less. But this hardly seems to be an argument for not opening the source code at all.

Am I missing something?

Maybe, maybe not

[Dust31]

I understand the principle of wanting formal specifications and then testing against those specifications. Where do formal specifications come from? Those with expertise and/or control debate and decide that (x1) needs to be laid out in this way, (x2) should withstand this, (x3) should be designed keeping this in mind, ... (xn) needs to incorporate this, where (x1) ... (xn) define the specification, call it (X). Those in control then say that (X) is "secure" given certain assumptions.

Someone then designs a system to (X), and then we can test the system to see if it meets (X), which is easy because (x1) ... (xn) are all laid out for us.

The problem arises when comparing (X) to, say, Linux because of a number of reasons, including:
(1) Linux was debated over and designed by a different set of experts than those that wrote (X)
(2) Linux was designed using (y1) ... (yn) as its security specifications, which may or may not intersect with (x1) ... (xn)
(3) Some of (y1) ... (yn) are not stated explicitly, and/or a complete list of (y1) ... (yn) may not exist

Thus the security of (Y) can't be "properly" verified. This means that (Y) may require more "faith" in trusting it than the faith required for (X), but it doesn't necessarily mean that (X) is more or less secure than (Y). That (X) is explicit and (Y) is implicit doesn't mean that (X) is more secure than (Y).

One could easily come up with a set of specifications (Q), (R), and (S) against which (X) and (Y) be tested and verified. If (X) is secure with repect to (Q) and (S) and (Y) is secure with respect to (R) and (S), then why is (X) trusted and (Y) not trusted?

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

Trust what?

[The Famous Brett Wat]

First of all, based on this definition of "trusted", the open source issue is irrelevant. Software could be "trusted" whether you could know the source or not, so long as the thing was designed to a precise formal specification and underwent sufficiently rigorous testing. None of the software I use (directly) is "trusted" in this sense.

That doesn't mean I don't trust my software. I put a certain amount of trust in it -- some more than others. But this is "trust" in the more usual sense. The sense in which it is used in the article above is an unfortunate jargonisation of a word with a well-defined meaning in everyday use. Let us rather refer to these systems as formal systems. That's probably an overloading of the term "formal", but at least there's less chance of getting confused relative to "trusted". Of course, you would expect such a formal system to be highly trustworthy by merit of the rigorous design and testing, and critical systems should almost certainly be constructed in a formal manner.

In general, I think more systems should be handled in a more formal manner. Indeed, in my opinion, lack of formality is one of the major reasons we have crap software. Usually we have specifications written by marketroids or by hackers scratching whatever itch is pestering them most at the moment. This doesn't make for good formality. Even when formality is attempted, it's rarely done well.

What's surprising about open source is that it seems to have a generally higher reliability than many commercial offerings, despite the fact that the development process is unfunded and chaotic. In that sense, it is relatively trustworthy, despite being informal. This isn't an absolute statement: there's a huge spectrum of quality, and it's mostly the top end of the quality that's interesting.

It would be interesting if a formal open source system were to be developed. The code contribution process could still be informal, but the specification and testing would have to be more organised. Infrastructure systems like DNS and TCP/IP stacks would do well from this, I think. Would there be enough interested parties to write the test harnesses? Who knows.

Cultural Dichotomy

[onepoint-o]

What we're seeing here is a big, old, fat dichotomy between the software engineering community who consider themselves engineers and the open source community who thinks of themselves as programmers or coders. I've traditionally always fallen into the latter group, however there is no doubt in my mind that the SE tactic of actually coming up with a sensible plan in advance is better. *This concept does NOT threaten open source software.* What it threatens is the culture of open source community. There's a difference between hundreds of programmers simultaneously fixing bugs within a predesigned and well thought out architechture, and those same hundred programmers randomly going off on their own design tangents. Any successful open source project has some kind of centralized authority- even if it a guy who just does the builds. What I'd like to see is a vast expansion of the whole TODO file concept. Rather than have a handful of items listed such as: "Somebody needs to figure out a way to blah blah", the TODO list should be a detailed spec. The process of coming up with that spec could itself be an distributed process but a very detailed and heavily reviewed spec should be developed before everyone starts coding.

bugs in "compliant software"

[QuantumRiff]

Correct me if i'm wrong, but just because a product meets a trusted specification, and passes a product test, it can still have bugs that were not tested for. With open source, if a product was designed this way, it would be easier to find other potential bugs that could endager the security of the tested system.

Things such as accidental back-doors and such that might not be tested in a formal test, would have the chance to be noticed by hackers the world over. closed source does not mean no bugs, or potential security breaches, just none that the group of developers have thought of.

------------------------------------------
If God Droppd Acid, Would he see People???

What do you want to trust?

[bockman]

This is not a rhetorical question.

A big company or a large organization, say the Army or a Government Agency, can take open-source software, submit it to a full auditing process [not only tests but also reverse engineering] and put in place a strict configuration control policy. They get trusted software and they don't need to depend on anybody else for their security. And probably they save lots of bucks in the process [wrt developing the software from scratch].

Individuals and small companies have neither resources nor skills to do that. Yes, anybody can look to open-source code. But how much it will cost in terms of man-power ? Skilled software engineer time is not a cheap resource.

Therefore, they have to trust someone else. At this point is not a matter of how the software is developed, but of what you choose to trust. It could be the peer-to-peer inspection of Open Source. Or it could be a company that distributes 'Trusted Linux' or 'Trusted BSD'. Or a company distributing a closed source system that they say is trusted.

This is a formal concept of trusted

[rgmoore]

I think that an important part of what you have to understand on this issue is that he's refering to a very formal concept of a trusted system. If you read the government guidelines on building trusted computer systems (e.g. the Orange book), one of the specific factors that is involved in designing systems at level B3 (IIRC) and above is that they be formally specified and proven to meet that specification.

While it's easy to gloss over this kind of requirement, there's some reason to think that it's actually a good idea. By the time you get to a class B system, you have to think about things like mandatory access controls, covert channel analysis, and the like. A formal demonstration that A) your system specification succeeds in meeting those goals and B) the system as built successfully implements the specification seems like a reasonable basis for reaching a high state of trust.

It's not impossible that you could build a free software project that could achieve this kind of goal. It certainly seems to be the case that every time someone says that free software can't do this, that, or the other thing, they've been proven wrong. But it's going to be tough to attract people to a project where you have to do stuff like keeping records of what you've done to meet design specifications, which is actually a requirement of high level trusted systems.

Isn't POSIX a formal spec?

[dido]

Hey, even Dr. Gene Spafford ought to consider the POSIX standard, which the Linux community prides itself on conforming to. I believe I'm not mistaken when I say that some organization (UNIFIX) has already certified Linux to be 100% conformant to the POSIX.1 standard. POSIX is definitely a formal spec even by Dr. Spafford's rigorous definition, I suppose...

"Trusted System" vs. a system you trust

[ave19]

Somebody moderate ka9dgx up.

I think this guy is talking about a Trusted System, like C2 certification, ala orange book. I don't think you can swarm-code past those tests.

Go check out the post from ka9dgx: "Trusted Systems - Building Paranoia into the code" It's long, but it's good.

OH YEAH?

[Signal 11]

Oh, really? I can make my system secure against physical theft using linux. It's simple. Follow the Loopback-Filesystem-HOWTO and recompile your kernel to support crypto. I prefer the serpent and idea algos, but YMMV.

Next, copy losetup, bash and your kernel to an unencrypted /boot partition. Encrypt everything else. Add an option to lilo specifying that /boot/myscript.sh is init. I disrecall if you need to specify boot as the root partition and remount it, so some experimentation may be necessary.

In the myscript.sh, there should be the set of commands to run losetup and prompt you for your passphrase(s) to mount your partitions. Enter them. Script should then remount root and exec the real init. System boots normally.

Dear sir, I humbly ask that you attempt to bypass the login: prompt and access my data on a system so configured. You may use any tool you like.

Open Source not secure my arse...

Re:OH YEAH?

[mbpomije]

WHOOOSH!
That's the sound of the Gene Spafford's point going over your head. He said that a system being "Open Source" does not lead to it being a trusted system. In the INFOSEC community, trusted has a specific meaning that is only related to security, not equivalent. Gene Spafford didn't say anything about the relative security of "Open Source", according to this summary.

Re:OH YEAH?

[Signal 11]

Trust, defined: the level of reliability of a system. ie, you can trust that system X will not crash often.

WOOOOOSH!

That's the sound of my point going over your head. Open Source problems are fixed, fast. They tend to be less severe than other "secured" products on the whole. I use products that fix their bugs fast, and don't produce too many of them in shipping releases. Another "trusted" system - NT 3.51, I wouldn't trust to hold my porn, let alone classified government secrets. Yet, strangely enough, Microsoft managed to get it C2 certified.

Certification != trustworthiness. That's my point that Gene forgot, along with empirical evidence.

Re:OH YEAH?

[shadow169]

as I recall M$ had to unplug the keyboard/mouse and the modem to get NT 3.5.1 C2 certified. . . . .

OpenBSD is secure until something gets rusted!

[tofus]

I once declared a system as 'trusted'... But then it's programmers got busted, So I installed OpenBSD, Guess what happened to me? All the malicious attackers were disgusted!

Old advice, new risks.

[Noryungi]

When reading that type of article, I am always reminded what a senior IBM network engineer once told me:

"If it has to secured, DON'T put it on a computer".

I used to believe he was joking but now, with a little more experience, I totally agree with this declaration. If it's sensitive, for goodness's sake, don't put it on a computer, and especially on a computer which is connected to ANY form of network.

With all due respect to a senior 'net citizen such as Dr Spafford (who is certainly more intelligent than I am or ever will be), it is true that Linux (or *BSD) evolve in a chaotic and ramshackle way. But we should always remember a few points:

• Open source is always better than closed source, whenever security is a concern. That's a given, period.
• The network effect ensures that, today, any computer systems which is not connected to the 'Net sees its value decrease. Therefore, unfortunately, most organizations have to connect part or all of their internal networks, which already represent a security risk, to the 'Net (an even greater security risk) in order to just survive. The result is easy to guess: we are going to see more and more security risks, whether or not we follow IT security specs or not.
• Remember: your security is only as good as the implementation of the specifications itself! Good specs are worthless in the hands of morons, who will just take shortcuts to roll the product out the door faster. Even good specs can be broken down by a tiny little bug in the end program, even if said software is crafted by geniuses. Case in point: the recent bug found in the random number generation routines of PGP. Good software, good specs, tiny bug = Window of opportunity for attackers.
  
• Most security specifications were designed before the growth of the Internet. Most do not take into account this enormous growth or the fact that an "always connected" system or network will always get attacked, sooner or later, just for the eck of it, by script kiddies. We also need to remember that most 'Net sites went from UUCP-dial-and-disconnect to HTTP-always-on-all-the-time in a relatively short while! How can, say, a UUCP-security specs hold up to HTTP? And I am not even talknig about distributed systems stuff such as Gnutella or Freenet, which could (will? have?) become a security risk in the future!
• The Internet itself grows chaotically, at extreme speed. Therefore, it is probably better to have a system grow chaotically and with extreme speed to keep up with the security risks. This gives a huge edge to Open source OS, since major security problems can be fixed in a matter of hours, not weeks or months with traditional software vendors... who may be following precise specifications and procedures that are just too slow for 'Net time! Case in point: some major security problems and DoS attacks were solved in a matter of hours after their publication with patches in the Linux kernel. Of course, not having these problems (OpenBSD!) is even better...
• Finally, except for OpenBSD, no project that I know of has been undertaken with the idea of putting security first, from the ground up, with the emulation and the benefits that Open Source brings.

Want to keep something a secret? Remember the advice of that engineer: write it down on a piece of paper, use a one-time-pad, lock the paper in a steel box and put the box in a military-grade safe. Burn all other traces and throw the ashes in a vat of acid. But, for goodness sake, DON'T leave it on a computer!

Of course, this is just my US$0.02...

Re:Old advice, new risks.

[mbpomije]

Open source is always better than closed source, whenever security is a concern. That's a given, period.

Well, obviously we're talking you're religion. Would you trust the security of Redhat Linux over, say Multics or OS/400?

Re:Old advice, new risks.

[Noryungi]

Maybe we are talking about my religion... =)

Seriously, though, if you are interested in a *web server*, my remarks still stand. I don't if Apache has been ported to OS/400 or Multics.

Besides, how many companies, these days, can afford a Multics- based computer (does it still exist?) or an AS/400?

My dad (who was a security officer on a big iron somewhere) used to mention that, even with OS/400, it usually took less than 30 minutes, for a good security consultant, who was probably much better than the average script kiddie, to gain complete access to a machine.

Compare & contrast with what OpenBSD claims on their website: "Two years without a local root exploit".

I am ready to admit that "Big Iron" means much better security than a PC+your choice of OS. That does not mean *good* security, though. Simply better security.

a trusted system might not be a Trusted System

[mirko]

If I correctly understood your story, it just seems that because of some rule, open-sources will never get the sticker with the Trusted System trademark.

I believe this is kind of a restrictive approach even though there might be some good points about it.

By definition, you trust wh[o|at]oever you know.

If you get experienced enough with your server you should not look for such distinction but for ways to make it even more performant.

After all, this sounds like some new kind of benchmark and we all now that satisfaction is not necessarly a matter of figures.
--

so what?

[White Shadow]

Well, perhaps Open Source software shouldn't be "trusted," given his definition of trused. But the true test of a program should be how well does it compare to it's competitors. If a program works better, it shouldn't really matter if it's "trusted" by his definition. It's still the better program. So if you're arguing whether open source is better or worse than closed source, I would say just look at what's out there. Which program performs better?

Bruce Schnier says ...

[joe_fish]

Bruce Schnier says ...

... Security is not something that can be tested for.

Makes sense if you think about it. And it blows a truck right through the "you need a formal spec to test against" premise.

I think Schnier makes much more sense from a theoretical point of view.

From http://www.counterpane.com/crypto- gram-9911.html

The only reasonable way to "test" security is to perform security reviews. This is an expensive, time-consuming, manual process. It's not enough to look at the security protocols and the encryption algorithms. A review must cover specification, design, implementation, source code, operations, and so forth. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure.

No mention of a formal spec.

Go Bruce!

Re:Bruce Schnier says ...

[Kaufmann]

I like Schneier (note the two 'e's) as much as the next guy.

But what we're discussing here isn't just whether a system is secure: it's whether it's trusted, which has a very specific definition. That's the entire point. Is OpenBSD, by itself, secure? Very much so. Is it trusted? Nope.

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"

Re:Spafford's right, but wrong

[Xerithane]

www.protectix.com - open source security solutions. I think the main point is you can develop a security-minded heirarchical system and have it be open source so if you have any flaws in your design or code (which are bound to happen) you have other people ready to look at it and fix.
Free Q&A :)

nerdfarm.org

We need _formal_ documentation!

[Steeltoe]

"How do you think we can address his criticisms?"

A few outdated man-pages, HOWTOs and pointers to Web-URLs just won't cut it in this context. In Trusted systems you will need formal proof of ownership, wholistic design, white-box testing/analysis and black-box testing, plus other things I can't come up with now. Documentation on the whole process of conceiving and creating the system would be a great benefit. This would have to be Applied To The Whole Shebang(tm), down through every library, including formalization of every function and good comments on most of their lines.

Now doing this properly _after_ the actual implementation has always been a bad idea, and would further require much harder work than if it had been done in the first place. However, this is an impossibility when regarding how the Open Source-process really works. It would never be as good as it could have been.

If more companies started supporting Open Source solutions, they could perhaps fund this kind of work and release it to the public (either for free or for a fee). It could benefit these companies, because now they can Trust and use free software. Actually, I saw a book that documented the whole Linux kernel once, so I know that has been done successfully.

Of course, "trust" is a word of many meanings. I for one trust many Open Source solutions simply because I know they have stood the test of time again and again. However, I'm always aware that new versions may break things considerably, and the documentation is not always updated. That is why Open Source is not currently a good process for building really Trusted systems. (This has nothing to do wether you release the source or not, which should always be a benefit to trust.)

So to me personally it is good enough, and currently the Open Source-process has quite a few benefits over closed source in this context (and many more regarding price and freedom):

1) Peer review (less bloat, great functionality and inter-operability, harder to put in trojan-functionality)
2) Large techsavvy userbase (quicker bugfind- and fix cycle, easy to get help and gain a community)
3) Ability to find and fix errors or improve the system yourself (Although this should never be necessary in a trusted system. Doing so may also contaminate the system with eg. bad binaries. However, it can be done safely if you use the right process of doing so.)

Note that these points are connected to the very fundamentals of how Open Source works, and should be seriously considered by companies that not merely want to ride the "Open Source Wave".

However, if I were to buy a Trusted system from a company, I would make sure there was a contract that held them accountable. That would be one point to proprietary software I guess. I think it would be hard to find a company that wants to be held accountable for Open Source code (written by others) that they have merely certified..

And lastly, always remember this: There's no such thing as 100% security. You cannot prove security, only prove insecurities or specific lacks thereof.

So don't put your trust arbitrarily.

- Steeltoe

Trust no one (but the code)

[redbird]

The whole issue really comes down to one things: the code is the only thing that can be trust. No test or even real life proving provides what the code does: solid proff that the program is what it claims to be. Test after test could be run on some M$ server program and it could meet some very rigerous, formal standard, but that means nothing to me becuase they won't let me see the code, so I don't know if M$ is secretely observing my use of their program or violating the privacy of my users and myself.

Like I wrote; the only thing that can ever be trusted is the code.

---

I sat in on this presentation wednesday...

[otis wildflower]

... And you need to remember that his bread is (as I've said before) partially buttered by closed-source development, and that butter may be threatened by open-source code and economics. Also, beyond just his livelihood, open-source does not necessarily obey his notions of secure design and practices. Academics REALLY HATE when real-world practice doesn't fit into their theoretical structures.. So inconvenient!

We can definitely learn from this man, listen to his experience and knowledge, steal his ideas, and write more secure software, but leave the obsolete preconceptions behind. Then again, he should know that the only reliable crypto is open/peer-reviewed crypto, and security in general needs to be scrutinized by many people of different talent areas to be of quality.

Your Working Boy,

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:It's all in the people...

[seaan]

I'm big on specifications

Security specifications are different than a normal system. Although I generally agree with the comments in #119, they miss the point that Gene Spafford was trying to make. Most systems are just happy to have the system work correctly, a point mentioned in post #121.

Security systems are only as good as their weakest link. Good security system design requires a step past working correctly. They have to work correctly and not work wrongly, in other words: no bugs even if a very intelligent opponent is trying purposely to break things!

Needless to say, making things without bugs is very hard, and making things that resist attacks is even harder. You have to consider the real world and the whole environment, not just the sub-system you happen to be working on at the time. For examples, remember the smartcard hacking techniques like subjecting the computer to microwaves or extreme temperatures as a method to force the system to leak information.

I won't claim the open source community could not achieve a secure design, but it requires some very different ways of working on the project. That leads to several rules of good security system design:

1)Know what you want to do (this is the main point of good requirements).
1a) Fully understand all errors, and decide how to handle them.
2) Keep things as simple as possible.
2a) Break down complex problems into simple sub-systems.
2b) Minimize the amount of interacting sub-systems

No one said this was easy. :-)

Yes and no

[ozbird]

He's right in the tradition sense of "trusted" i.e. "tried and true". These systems are trusted because they're a veritable Rock of Gibraltar - they're been around for a long time and have weathered all storms. Fair enough, as long as you can live within such a framework. (Change something, however trivial, and you may well ruin its trustworthiness.)

Open Source, OTOH, takes a different approach. Instead of standing still, it is constantly changing - any problems that are discovered are fixed quickly; it's very difficult to besiege a moving target. Exactly how fast it moves depends on what you are looking for - Linux is probably the fastest evolving Open Source OS; OpenBSD takes the slowly but surely approach. Exactly which approach is best depends on what the user wants - the way it should be.

Methodology is Irrelevent. You will be debugged.

[jd]

Every function, every procedure has a well-defined set of pre-conditions and post-conditions. What goes in the middle, and how many people are involved in the process, is all irrelevent.

Your testing is all very well-defined. If the pre-conditions are violated, then your input is in error. Your routine should determine this (how is unimportant) and exit safely. To test this, run the routine in a test harness and see what happens when you enter "normal", extreme and erronious data. (Ok, hands up! How many of you have heard exactly the same thing from Comp Sci lecturers, throughout school and University? Just cos they're lecturers doesn't make them wrong. At least, not all the time.)

The next round of testing is the post-conditions. If your routine exits and violates a post-condition, then the logic in the routine is faulty. The case being tested is not being handled correctly, according to the specification. So you fix the routine. Big deal.

Who defines the pre-conditions and post-conditions? That's simple. For IP-based networking, the IETF RFC's define those very nicely. For device drivers, the specs for the device do the same. Then, there are POSIX and UNIX98 standards docs. Since Linux is a mish-mash of BSD and SysV, the specs for both of these are usable.

All in all, the problem with Linux is NOT that there aren't enough formal specs (there are plenty!) but that Linux doesn't have any wide-spread test harnesses, or databases of pre/post-conditions.

If someone (anyone!) could come up with a way of plugging ANY Linux module into a test harness, and pound it with different cases, and then have the responses checked against the pre/post-condition DB to see if the module violated the specs, you'd have ALL the formal testing you'd ever need and auditing would become a breeze.

Dibs Linux for B1 before Windows!

Be All You Can Be

[Mandi Walls]

"Trusted Software" or trusted systems in general are supposed to meet a spcification that was written by the DoD in 1983 (which was an update to docs written in the early 1970's) that outlines appropriate guidelines for access to remote systems and embedded software.

Specifically, it wants all access to all objects on the system to be fully logged, leveled security, and blatant marking, plus whatever else is in there and too dry to read.

However, remote access to systems is a job not only for the operating system of the host, but also for the network it runs on. Being that networks in 1983 were a little different than they are now, I would hope that a system that was meant to provide access to possibly classified data would rely on more than simply the security of the selected operating system, regardless of the openness of the sourcecode. The system in that case would take into consideration the OS, the firewall, and the network connection from client to server. The possibility probably exists to buld a system based on Linux that could be trusted, but would need to be spec'd out with "system" referring to more than just the OS of a host computer.

When it comes down to it, would you really want the good name of Linux drug in the mud by some military stiffs who can't secure the Army web servers?

--m

Re:Be All You Can Be

[nhw]

"Trusted Software" or trusted systems in general are supposed to meet a spcification that was written by the DoD in 1983 (which was an update to docs written in the early 1970's) that outlines appropriate guidelines for access to remote systems and embedded software.

That's almost correct: at this point, you're referring to Orange Book, or DOD 5200.28-STD. It was last updated (as far as I know) in 1985. Otherwise, I agree.

However, remote access to systems is a job not only for the operating system of the host, but also for the network it runs on. Being that networks in 1983 were a little different than they are now, I would hope that a system that was meant to provide access to possibly classified data would rely on more than simply the security of the selected operating system, regardless of the openness of the sourcecode.

Orange Book is specifically about computer systems, not networks, or indeed networked computer systems. If you're interested in what the NSA/DoD has to say about networked systems, then you should probably be looking at the Red Book; aka NCSC-TG-005, which is available somewhere on the NCSC's public webserver: Radium. This server is a tremendous resource to those interested in trusted computer systems; the nice people at Fort Meade will even send you a CD containing the full website, free of charge, if you ask them nicely.

Cheers, Nick.

What "community"?

[afc]

First of all, I think your mention of the Linux community and how it prides itself on its haphazard development model is a bit misleading. Even the Linux kernel itself is not developed in the chaotic manner you described (parts of it, specially the in-the-works LVM, have formal specs and desing).
What you seem to miss though, is that not all free software projects are developed in quite the same way. The contrast between Linux and OpenBSD is just the tipof the iceberg. Many more projects have such a close knit assembly of core developers who add features following a formal design, and use formal tests to ensure that the builds are OK.
The argument you seem to have missed in that lecture is that there's no reason why an openly developed free software cannot have thourough, formal design and testing, and there's no guarantee that a closed development has it either.

He's setting a specfic definition of "trusted"

[Get Behind the Mule]

Gene Spafford's argument seems to proceed simply as a tautology from his definition of "trusted", if I've understood the summary correctly. By this definition, a system is "trusted" if and only if a formal specification and testing process exists, and the system satisfies the spec and passes the tests. Thus it's trivially true (if we accept the definition) that a system that doesn't satisfy these criteria isn't "trusted".

It is *not* true, however, that an Open Source system could never satisfy this definition. Set your formal specification and get your Open Source coders to work on fulfilling the spec. When they're done, then voila! A "trusted" Open Source system.

Alternatively, one could reject Spafford's definition of "trusted", as not matching the intuitive notion of trust. One could reasonably argue that "trust", in the common and intuitive sense, can only be realistically achieved by extensive peer review. I would furthermore argue that satisfying a formal spec is not enough for trust, because a spec might fail define a system that most of us would intuitively view as trustworthy.

If all he's saying is that all we need is a spec in order for a system to be "trusted", without saying what such a spec has to be like, then I say he's wrong; because a spec can specify any kind of untrustworthy foolhardiness you imagine.

To demonstrate this, I hereby give a formal specification of "trust": A system is "trusted" if and only if it crashes at least once for every six hours of operation. The formal test is: Run the system for sixty hours; if it crashes ten times or more, then it's "trusted". There you are, a formal spec and testing process. But hardly anyone could describe such a system as "trusted".

BTW, although I'm disagreeing with him, I remember Gene Spafford with great respect as a major driving force in the early days of Usenet, and the author of an O'Reilly book on security. I'm a bit dismayed that so many Slashdotters don't recognize him.

open source != good design

[Anonymous Coward]

He certainly has a point in that the design of open source programs often leaves something to be desired.
Also, there are too many open source projects that were started by inexperienced designers and programmers, and get reworked over and over to meet quality and security standards.
Maybe, now that Linux is getting more and more attention, a next level should be started: some kind of "open specification and design" system.
One that allows new projects, or new versions of existing projects, to be specified, designed and documented before the coding starts. "open source" focusses a lot on the actual code, and we all know that this is only a small part of a successfully functioning software system.

That's not quite true...

[vanix]

Where the code comes from should be irrelevant -- if the spec is good and the code actually matches, all is well, regardless of origin.

If I can't see the source, what proof do I have that it matches the spec?

Re:That's not quite true...

[OAB]

If I can't see the source, what proof do I have that it matches the spec?
Well, you could always test the binary against the spec (which you should do EVEN when you have the source).

Re:That's not quite true...

[0xdeadbeef]

But without the source you might never know if it had "hidden" functionality.

Re:That's not quite true...

[bcaulf]

The owner could sell you a source license without redistribution rights.

A zen story

[hey!]

Once there was a young monk who saw another young monk from a rival temple on the road.

"Where are you going!" he said in a rude voice to the rival monk.

"I am going wherever my feet take me" said the rival in a mysterious voice.

This flustered the first monk. When the first monk went to his masters and related this, they beat him, and said "You fool! Ask him, 'What if you had no feet?'"

The next day, the monk saw the same rival walking down the same road.

"Where are you going!" he challenged.

"I am going whereever the wind blows," replied the rival solemnly.

This flummoxed the first monk, who was not expecting this. Again he related this to his masters, and they beat him, and said "Idiot! Ask him, 'What if there were no wind?'"

Thinking he had this figured out, he lay in wait for his rival, who in due course came down the road.

"Where are you going?", he challenged.

"I am going to the market to buy vegetables" said the rival.

---
The point of this is that when somebody is thinking on a deeper level and carefully factoring in your own methods of reasoning, he can defeat you. The Morris worm was a perfect example.

I agree that open source is not a panacaea, but neither is formal specification and testing. Paranoia suggests multiple and orthagonal methods for enhancing security, not relying exlusively on one strategy.

...and in the REAL world...

[eldurbarn]

Oh, yes! "Trusted" software requires a formal spec, and a testing spec designed to assure that the original spec has been satisfied. A lot of research has gone into how to derive the testing spec from the design spec, but in the real world I have never, ever seen a design spec that didn't need change after change after change.

The entire concept of trusted software is predicated on the notion that the user knows what he wants, that this desire will not change and that it can be captured in a specification. That is sheer folly.

Whom do you trust?

[jabber]

Open source is more likely to be free from intentional 'features' which compromise security, because the source has been stared at by hundreds of eyes without the same nefarious goal. Contrast with Microsoft, where "Netscape Engineers are Weenies!"...

However, if the source is open, your own developers can put in whatever 'features' they want.

Are you more worried about external intrusion by a monopolistic corporation, or internal moles and unhappy workers?

What policies would you place on open source code that would keep it 'secure'?

can commerical software be trusted?

[crazy_speeder]

it doesn't matter how the software is delivered, only who you can trust.
take Micro$oft, they deliver an os environment with undocumented features. how trustworthy is that!?

BTW

[FascDot Killed My Pr]

I commented earlier poking a few holes in Dr Spafford's argument, but now I'm posting again with a totally different point.

Let's say he's right: Open Source isn't a security panacea. So what?

This is only a big deal to the ESR's of the world because they try to make arguments about using "Open Source" software based on business needs (like security, cost, bugs, etc). But that's not why I (a non-business, after all) use Linux (and friends). I'm in it for the freedom. And no amount of specs and formalism will give you freedom.
--

You're right, depressingly.

[Karmageddon]

You are absolutely right, Cuthalion! I searched the discussion for "orthogonal" and found your comment. While I was doing it, you got modded right up to the top! so, the hated moderation system does work pretty well on the upside. :)

Anyway, I said "depressingly" in my subject line because there are a whole bunch of people commenting down below who don't see what is so obvious to you. To them, open source means baggy pants, cap on backwards, dissin' the man! You can see that view also in ESR's debate that was up here yesterday, too. Sheesh, folks! Open source is about getting your hands on the source, that's all. It's not about no plans, no deadlines, no testing, just like it's not about more plans, more deadlines and more testing.

That said, let me add one not terribly original point: a system that is tested and certified by lots of committees and agencies, and it is open and open source, and it still passes all the tests and certs, is a system that is probably pretty secure. The various public key encryption systems come to mind as examples.

Security testing..duh!

[tojo400]

If I understand this correctly, he's saying that becuase its open source it can't be secure?

My experience with software as programmer and system admin is that the user community drives security. As a sys admin, its my job to use products with the appropriate level of security available and in place. This being true of all similiar folks, natural selection of processes and software overall, IMHO, will drive towards higher levels of security and quality.

Along with this, I believe many of the programmers involved in open source are also consumers and also familiar with standards. Security standards are well documented and even specd out in some cases.

I'd also like to agree with the original poster about existing 'closed source' software and OS. Many holes have been and will continue to be found in existing OSs. Open source just speeds the recovery along vs closed system based on risk/income.

Rant done,

TJ

Look at both the sides... not just one.

[rkt]

I'm sure he had his reasons to say what he did. But its incomplete unless you look at both the sides.

1. Open source is only as much chaotic as the maintainers want it to be. I've tried developing for open GNU products and belive me when I say it, it is a pain in the *** to get a patch built into the main code for some people, and for the others the maintainers don't even think twice. Still there are others where 10 different groups have 10 different tree of the same code and try to merge them every few months... this is chaotic. However the linux kernel is one of the best maintained opensource projects I've noticed... if you could just imagine how many people are contributing to it you would appretiate what "linux" actually means.

2."Trust" again is a weird word. Do you trust MS on Office2000 ? How do you know they don't have a code in there which will turn you into a borg ? Atleast I'm sure linux kernel doesn't have anything like that... and millions of people who have seen, studied, and written to the code can vouch for it.

3.Again, the word opensource need not mean that the development is also opensource. I think there are too many journalists out there who mixup words like "opensource", "open development" and "freeware". Whats common to all opensource is that it can be seen and studied by everyone. MSIE is free, but not open at all. And the problem of "trust" which you spoke about involves only in situations where development is also open. For example Plan 9, from lucent is a closed development... (I think this is a good example).

The way I look at it is that, if something is not chaotic then its probably invisible to you. Nothing in this world is perfect... chaos is a relative term... and I don't care if linux development is chaotic... 'cause it works for me.

rkt

a.out / ELF

[logistix]

Probably the biggest example of why Open Source systems can't be trusted from a contratual standpoint. This runs contrary to the open source ideologly that you can change something completely if it makes the software better.

Assurance != Trust

[ballestra]

This notion that software must have formal specs and testing in order to be trusted is similar to the notion in the manufacturing industry that you must be ISO 9000 certified in order to be trusted to produce quality products. ISO 9000 is said to be a quality assurance standard, but it is basically a rigid certification process to show that business processes are specified and standardized. In other words, it doesn't mean the manufacturer makes good parts. In fact, it makes no measurements or judgements with regard to actual product quality. It just means that the company uses the same design process, the same production process, and the same testing process for every product, and that all of these are specified and audited. It's an assurance that no one does anything except "by the book". The book may be recipe for quality or not, but they are certified to be following it regardless. So if the manufacturer makes products of a certain quality, you can trust that future products, designed and built with the same processes, will have similar quality. A competitor may build superior products, but lack the same rigid procedures (maybe they trust the intelligence and experience of their employees), and therefore not be certified.

ISO certification is a great comfort to purchasing managers who prefer trusting a bureaucratic process to trusting individuals or their own judgment. This is similar to companies that require job candidates to have a certification, rather than independently assessing the candidate's skills and knowledge. It's not meant to be an equal opportunity process. It's meant to be a discriminating process that allows a decision to be made without anyone having to exercise their own judgment and thereby risk their reputation. It means you aren't risking your own reputation, and you don't trust anyone else's.

The fact is that making judgments of quality or security is difficult, and most people are lazy. Nothing prevents anyone from coming up with a way to measure security and putting OpenBSD to the test. This mentality, however, would make it an imperative that the software be retested with every change. Any what assurance is there that the test itself, or the person conducting it, can be trusted. ("We'll need to see some certification").

Certain types of people will always have greater confidence in the legal recourse to hold someone else accountable than they have in their own judgment. It's just too bad that those people are given so much credit.

A System's "Mileage" Counts, too

[Ricdude]

Most companies that purchase custom written software require a strict process known as "Verification & Validation" (V&V) to be performed in order to certify a system as meeting their requirements. IEEE has standards (IEEE.1012, iirc) that cover what should occur during this process. These companies also usually have a clause to the effect "If your system isn't up to par on the documentation, a good history/track record may be sufficient to supplement available documentation". The idea is that even though your software may not have an independently reviewed test plan derived from requirements documents, etc. that you're software shouldn't be excluded from consideration as long it has a history of working well and accurately.

For the Linux kernel systems, this V&V process amounts to verifying that the screwdrivers used to build the house meet your living requirements. So long as Apache continues to serve web pages, and a server can fairly reliably server files, mail, news, mailing lists, etc. there is a general consensus that the Linux part is trustworthy.

I wonder what he thinks of Microsoft's OSs, where they are known to deliberately mess with OS internals in order to affect performance of competing applications. The email regarding how to adversely affect PalmOS users to the advantage of WinCE users springs to mind... Is this a system I should trust?

Devil's Advocate

[bee]

Think of it this way: Gene Spafford (who I've known for a long time, back to the days when you got a Big 7 Usenet group created by sending him email) isn't slamming Open Source, he's merely playing devil's advocate. I don't think that any of us will claim that the current state of open source software is software perfection; he's just pointing out that in theory, a specification is easier to read and debug than source, so if you *really* want a secure bit of code, you write a secure spec, and then guarantee that the code meets the spec.

What doesn't work is having the source code *be* the spec, because if you run with that far enough, you end up with Microsoft Word, where the specification of Word's .DOC is defined as 'how Word displays and prints it' which leads to madness, wailing and gnashing of teeth, and many other bad things. Spaf has a very valid point; think of his point as a goal rather than a criticism.

---

As experienced as this gentleman is in security

[shaldannon]

I wouldn't just go around dismissing him. It's particularly bad to dismiss him on the grounds that his arguements are based on (his) financial well being. The man gets paid to be a professor. His status in the security community comes from his work in security (as a researcher).

One of his goals as a researcher is to develop security testing packages. Dan Farmer, under Spafford's direction, wrote SATAN to help people find the holes in their systems--and patch them.

I think this man is more concerned with developing a secure world than he is by profiteering off a particular economic model.

OK, it's possible to miss a point. We all remember Ken Thompson's remarks about Linux, and I remember being in a lecture hall where Owen Brown and Gordon Bell both trashed on Open Source. It's very possible that Spafford missed this as well. However, as an earlier post pointed out, Spafford's lecture seems to be aimed at a controlled, replicable, process (gee...that sounds like software engineering). As much as many of us hate to admit it, most open source software is designed by the code-and-fix method. I have the feeling that this was one of his main points. It's hard to set up a detailed testing model which handles all of the inputs and outputs (black-box) to see what a routine will do when the routine is evolving into existence.

Finally, I don't think we should "steal" from Dr. Spafford. Aside from the fact that he gives his information out for free (it's payed by research money but donated to the community at large), it's illegal, immoral, and, from a socio-economic point of view, inappropriate to steal.

I didn't have the opportunity to sit through his lecture, but I wish I could've. I'm sure it was quite interesting to those who didn't let certain biases cloud their thinking.


if ($user =~ m/shaldannon/i) {
print "\n-- $user :)\n"
}

Re:As experienced as this gentleman is in security

[otis wildflower]

I think this man is more concerned with developing a secure world than he is by profiteering off a particular economic model.

I agree, my issues are largely related to the academic vs. real-world differences. OSS works pretty well in the real world, but it doesn't fit into a traditional academic perception of security design (though peer-review of code and algorithms _is_ a standard tenet of secure design). Perhaps it was unfair to put the caveat at the top of the note, it should not have conveyed that much emphasis, but I still stand by my belief that Dr. Spafford may have his objectivity clouded somewhat by institutional oldthink and, possibly, by conflicting interest.

However, as an earlier post pointed out, Spafford's lecture seems to be aimed at a controlled, replicable, process (gee...that sounds like software engineering).

Yes, that's why I said (in that earlier post I referred to) that while we can agree that software designed by small teams of competent designers and coders makes for stronger, more secure software, that isn't the actual point. The point is, in the real world, we have to deal with all kinds of software from different companies and groups, and often the decision process for selecting software isn't the most logical or objective process. So how do we live in that world? Dr. Spafford puts forth a view of a software world in which we'd like to live, my thing is we don't live in that world, it's not coming anytime soon, so how the hell do we deal with what we have to deal with, while doing our best to improve matters when we can? Again, it's academic vs. real-world. Both can appreciate the Right Thing, but you can't always get it in the Real World, for a variety of reasons. It's a respectful difference of opinion, not a flame.

Aside from the fact that he gives his information out for free (it's payed by research money but donated to the community at large), it's illegal, immoral, and, from a socio-economic point of view, inappropriate to steal.

Good artists borrow, great artists steal. And smart artists properly attribute.


Your Working Boy,

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

Re:Trusted unrelated to reliable/secure

[null_session]

(Note, NT's C2 security used to involve no NIC, but I think they fixed it)
Just as an aside, there is signifigant evidence to the effect that Microsoft paid for their C2. Specifically, the people originally hired to do the C2 evaluation later quit and went public with the information that Microsoft attempted to bribe them into certifying NT. Why did you not hear about this? The same reason you probably didn't know that www.microsoft.com.br was defaced over Mermorial Day weekend, (that story was only available in Portuguese) Microsoft has considerable weight with the media in this country.


Now on to more important topics... If open source is by definition an untrusted system, then why did the NSA contract a secure version of Linux? I can't think of the name of the company off hand (it's a firewall company out of California) but I know that the NSA contracted them to build an NSA certified secure system, for use by the NSA (and later everyone else) based on Linux.

And BTW: Alex, before you start whining that I'm just an anti-NT zealot, I am also an MCSE and while I agree that being an MCSE does not make you a moron, I would hope you realize that Microsoft does NOT test for the administration skills you really need.

Re:Trusted unrelated to reliable/secure

[alexhmit01]

But if you notice, then the NSA is contracted someone to build a secure Linux. That secure Linux MIGHT be Free Software (or internal only), but it wouldn't be developed as open source.

Free Software - Software available to all respected the rights RMS believes are important

Open Source - Source available, can modify source, etc., not as many guarantees as free software

Developed as Open Source - Bazaar approach, many eyes, many contributers, anyone can submit code, roll their own patches, pressured to accept all patches, chaos, etc. Produces some really neat stuff, but it is totally chaotic.

There is a distinction there. The "Open Source Model" of millions of programmers cannot produce something to a strict spec, as that requries careful management, coordination, etc., the Mythical Man Month still holds.

Anything can be made Open Source/Free Software. there is a difference. Being Open/Free merely involves licensing, Open Source Development is the chaotic model that Mozilla, Linux, and a few other projects function with (Apache?). Others have been more controlled (the BSDs, Xfree86, GNU, etc.) while still being made available as Free.

On the NT thing: I'm not whining about it, I'm getting sick of the nonsense I see here. Microsoft's tests don't test much, they test a bare minimum. However, I'm sick of being called a moron because I know systems other than Linux. I routinely use Linux and NT, some Solaris, and learning FreeBSD and OpenBSD, unfortunantely I'm just not smart enough to realize that Linux is all you need. :)

Re:Trusted unrelated to reliable/secure

[jtgold]

Some of us actually learned are shit to get it, instead of just memorizing study guides.

Clearly spelling and grammar are not part of the MSCE requirements... ;-)

Problems with his argument.

[Gleef]

First, the big fallacy in his argument: Open Source is not the Bazaar! Specifically, there is nothing to stop a person from getting a group of programmers together, writing up a formal spec, paying them to write code, paying a third party to do a formal audit and testing it against formal standards, and then releasing it under an Open Source license. It wouldn't cost any more than the analagous proprietary effort he's presumably advocating.

Secondly, you can use the Bazaar to reduce the cost of developing such software. Take a Bazaar-developed program that does pretty much what you want it to, draw up a formal spec, pay some programmers to audit the program and bring it up to spec, and then go through the formal testing. If you pick wisely, this could greatly reduce the cost of such development, and it should comfortably meet his definition of "Trusted".

Thirdly, I question whether formal specifications improves security; granted, that's no consolation if you're working for an organization that requires it. Formal specification merely means that some thought went into design before the program was written (or modified in the above example). It is very difficult to test a specification for security problems, for obvious reasons. Also, it is easy to write a program that matches a formal specification, yet introduces subtle security holes.

Fourth, there is no reason why you can't perform formal testing (for what it's worth) on any piece of Open Source software, Bazaar or not. Then you have a formally tested program. You must refrain from upgrading without running through the testing procedure again; just like proprietary security software.

The bottom line is, if you want formally trusted software, you've got to spend some money. Open Source will not prevent this, Free Software will not prevent this, neither the Cathedral nor the Bazaar will prevent this. That doesn't mean they should be excluded from consideration.

----

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.

Nothing STOPPING OpenSource from having specs

[mr]

There is nothing stopping OpenSource code from having formal specs and a well thought out design process.

Does Mr. Spafford think Kerberos insecure?

Last time I checked Kerberos has a formal design spec, peer review AND is opensource.

I do not see that Microsoft products qualify as secure. Where is the formal design spec? The peer review? It doesn't look better on the closed source side of things, but I guess Gene didn't want to grind that axe eh?

Re:Methodology is Irrelevent. You will be debugged

[nhw]

Every function, every procedure has a well-defined set of pre-conditions and post-conditions. What goes in the middle, and how many people are involved in the process, is all irrelevent.

All very well for purely sequential programs that start at A and run straight through to B...

Unfortunately, most real world programs have loops, and proving things about even moderately complex loops is Quite Hard (anyone who has done anything involving the proof of loop invariants and termination conditions will know what I mean), most especially if these proofs are attempted 'after the fact'.

Even then, if you can do that, you run into the problem that many systems are not purely sequential, but have some concurrency involved in their operation. Reasoning about concurrency is also Quite Hard, as anyone who has played with CSP, pi-calculus or any of the other process calculi out there.

Finally, you suddenly butt up against the problem that any formal axiomatic system that is sufficiently powerful to do anything useful (say, arithmetic) is also incomplete, so there will be true propositions in your code that you cannot prove. Blame Godel.

Cheers, Nick.

Simple. . .

[ishpeck]

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

Simple. Real world usage. If somebody breaks security, the answer is staring you in the face. (Now, of only the network admins at a bank would be as gutsy as me. . .)

He's missing something more fundamental

[casmithva]

Just because a product was developed with formal design and test specifications doesn't mean the product's trustworthy. I've no doubt that companies like Microsoft, IBM, Sun, Apple, Netscape, etc. use formal specifications and processes for everything, yet they've all made a science of deploying flawed, untrusthworthy products. I'm personally of the opinion that the people directly or indirectly involved with the implementation of a product play a much larger role in its eventual trustworthiness than the presence or absence of formal design and testing specifications. If developers aren't meticulous with their coding -- e.g., making sure the code's readable, maintainable, consistent, etc. -- and diligent with unit testing (and, in C and C++, memory analysis with something like Insure++ or Purify), then there's a greater chance that the result will be unreliable dribble. Likewise, managers of these products can easily override recommendations from testers and decide to release the product, flaws and all, just so release dates can be met; after all, there seems be the mindset in the commercial world that being first to market with a flawed product is much better than being second to market with a solid product.

You can have reckless or disciplined developers in both the open- and closed-source worlds. You can have and not have formal design and test specifications in both the open- and closed-source worlds. You can have rigorous reviews in both the open- and closed-source worlds. It just all depends on the mindset and discipline of the people actually doing the work. Let's not forget the space shuttle developers.

I, personally, don't think closed-source software, by definition, is more trustworthy than open-source software -- and vice-versa. But it's a lot easier to ascertain the trustworthiness, security, reliability, etc. of open-source software than it is of closed-source software because, in the open-source world, you've got the code, giving you the option and ability to do your own reviews, free of spin control from the developer(s) or prosecution via stupid laws like UCITA, and to fix any defects you find. That is what makes open-source code so powerful, in my opinion.

Trusted Code

[Veteran]

Code can never be more trusted than its authors. How could anyone trust source code that can't be seen? How does anyone know that it meets the specs to which it is designed? Closed source code is based on "Trust us - we know what we are doing".

What is to keep someone from writing an open RFC style formal spec and then allow the open source community program to the spec? Open source is all about programming to standards.

The code can be tested by the writer of the RFC as part of the creation standard. In effect that RFC writer becomes the lead programmer on the project.

One thing you might consider here. . .

[ishpeck]

I'm no security expert, or anything, but if you copy security "standards" from somewhere else, doesn't that mean somebody will already know how to break your security when they find it?

Maybe breaking up the patterns will make it harder to breach your systems.

trusted OS benchmark

[Ora*DBA]

Has noone heard of the Department of Defense "Orange Book" (actually I think the latest standard may be a different color)? When commercial OS vendors say they are 'C2 out of the box, B1 when you buy blah-blah-blah)', that is what they refer to as the standard for setting security levels of trusted systems. Why wouldn't that be the place to start? My enthusiasm for Open Source is based on the fact that the finished products are at least as good, and often superior, to commercial implementations. For the corporate marketplace to accept open source software as a realistic, viable alternative, the OS vendors (Red Hat, BSDI, Corel) must be able to equal (if not better) the HP-UX and Solaris' of the world by any objective measure.

Formal specs don't make it secure...

[DevTopics]

I think that adhering to formals specs don't make your software more or less trustable. Formal specs are a good thing, no doubt. But take a look at CERT advisory or BugTraq: most security problems don't stem from bad designs but from bad implementations (e. g. buffer overruns). It doesn't help if your spec says "don't allow buffer overruns". Now just let assume that you have a perfect formal design for a secure system. Vendor X implements his system according to this design... or so he claims. How do you know? You just have moved your trust from the specs to the Vendor X... which does not help, even if the Vendor X has never before been caught by bad implementations (and such a vendor does not exist). If the system is open, at least you don't have to trust, you can see for yourself. Formal specs will make it easier to discuss implementation details. You need a formal test to see if it is implemented right. And if these formal tests exist, you can apply them no matter if the system has been hacked together, is open source, closed source or any combination. And still, in practice, you will get caught occasionally, even if the test will support the illusion that everything is OK. Security is a process, not a state. Never be fooled into thinking a system is secure because you can't spot a flaw. Design is theory, implementation is practice. It doesn't matter a bit what a theory tells you... you can ONLY trust the practice.

Haiku

[YASD]

Call me chaotic
Formal specs are safe but dull
While I live, I hack

------

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

Re:Formal Specs? RFCs!

[Chris Mattern]

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

The question isn't whether it *works*, it is
whether it is *trusted*. The Web works but is
scarcely trusted. If the Washington DC Metro
(subway) had brakes that worked as reliably as
the web, I'd refuse to go to work in the mornings.

Chris Mattern

Re:Formal Specs? RFCs!

[Tower]

If anything that my life depended on was as unreliable as certain prolific consumer operating systems and programs, I'd never leave my house/room/bed...

The trust in this example was trust that it works the way it was supposed to, not trust as in security... there is a difference.

Re:Formal Specs? RFCs!

[dijit]

Unfortunately the person posting this comment doesn't know what RFC stands for.. Request For Comments. This means that people must adhere to the requirements to make them interoperable at a basic level -- Example IPSEC. Unfortunately, there are plenty of ways that companies interpreted this "standard" and guess what -- most of the implementations didn't work together. Hence the rewrite of the RFC. To make sure that the standards are trusted, they must be very specific so that not only the code can be verified to be secure, but also the assumptions and the ideas.

// dijit

dijit-at-half-truth.com

CCSA,MCP

Re:Formal Specs? RFCs!

[Tower]

Thanks, but I do know what RFC stands for... of course they get updated and changed, but that's why there are version numbers on them, too. That's why there are always newer versions of the various RFCs. My point was that they are the closest thing to a community formal standard that there is for many protocols, etc.. I agree with your point that different interpretations can cause interoperability problems - yes, that's why they get revised. The trust mentioned in the article had more to do with the functionallity of the program than it did with security. What the professor seemed to want is to see documented multi-level code reviews for function verification.

Please don't assume knowledge of another person when you have nothing to base your assumptions on - doesn't put you in a good light, especially when you are dead wrong. Try reading and understanding the posts and the article first.

Well, let's value-add formal tests

[Tom7]

It seems clear to me that if there was a market for a formally tested linux code base, a value-add company like RedHat or Caldera could do the work necessary to create a branch which was tested and certified, and sell that.

Right now I think most people fall for "open source" hype much more than "formally tested" hype, so that's probably why we don't see this (yet).

OK

[Art Tatum]

1) Free Software projects, as they stand now, don't conform to all the necessary standards to be considered "trusted" in the formal sense of that word.

2) Almost nobody cares. I certainly don't. Nuclear power plants, NASA Mission Control, and the CIA care but I don't. Let them use something else.

3) Trusted doesn't mean Linux, OpenBSD, or xpilot suck, it just means that we have no idea if they meet the appropriate standards. Now, if some enterprising company would like to take the source code and go through the rigorous and expensive process of testing it and making it conform, I'd think that was pretty cool. The source code is out there, and they're welcome to it. This is Free Software, remember.

Trusted != Secure

[blurred]

A trusted system does not necessarily mean that it is secure.

I can specify a (software) system in a formal way using formal languages like Z or TROLL (TROLL really is a formal specification language, honestly). But this does not mean that it has to be more secure, it only means that I am able to define the systems behavior *exactly*, so that the resulting software system behaves in a predictable way.

This is working fine in theory but to my knowledge there are no working (as in usuable) tools to automate the derivation of the software system from the formal sepcification. So you are still left with several gaps in the design/implementation process.

Proofing of your specification is simple: Transform your spec into predicate logic clauses und do a resolution :-) (the transformation produces an awful lot of clauses so your complextity grows *very* fast).

Until this process is fully automated, formal specification and *verification* (!) is too difficult and cumbersome for widespread use.

So this talking about trusted/untrusted systems is completely unrelated to any Open/Closed Source security debate.

+++ after all, it's just my thoughts +++

bye,
blurred

listen to him

[dpaton.net]

Spaff (and I've met him once or twice. Brilliant, but kinda prickley) is saying that by definition a trusted system bneeds to be developed using very well defined goals and requirements. Lats time I checked, other than some rather broad sweeping statements (many eyes = fewer bugs) there were no hard-and-fast plans for the goals of the various free unicies.

Don't attack him for what you think he meant..it's well known in the security community. that trusted systems are built to very strict standards.

So get some standards and quit bitching.

-dave

The gulf between specfication and tesing

[tongariro]

While I agree with Dr. Spafford points to a certain extent, I would be very surprised if there are 10 organizations in the world who knows how to cross the abyss between specification and testing on an large scale in industry or government.

Academics loves formal methods and industry avoids it like a plague for the most part because there are no perceived benefit.

Grunt: I want to formally specify this program so we can do proof of correctness later".
Manager: "Does this mean the program will be bug free and, by the way, how long will take do do this formal specification and all that proof stuff?"

And the discussion degenerates from there...

Formal specification is very hard for any non-trivial sized programs (say 250KLOC+) and if anyone says otherwise, they are full of BS. OpenSource projects by their nature do not lend themselves to formal specification and testing. Does that means they are more secure than close source or vice versa? No, of course not. It all comes down to the quality of:

the requirement

the design

implementation

the testing

For OpenSource projects, the middle 2 is usually done quite well (or someone else will redo it for you :-) but the requirements changes constantly as someone else enhance the S/W to do that other thing. Testing is uneven as normally there are no formal test plans.

6 years ago, in a different life, I started a project to close the gulf between specification and testing on real world sized programs. That work continues and may one day bear fruit. See http://www.ispras.ru/~RedVerst/ or the North American mirror at http://207.236.16.49/RedVerst/. The work is brutal both theoretically and practically and required far more brain cycles than what my poor little brain can generate. I am just glad I am not doing it. :-)

Art versus Science

[winterstorm]

What exactly do you trust OpenBSD to do correctly?

If you can't formally describe what it is supposed to do, then you can't trust it to do that. There is difference between the work trust as used by your mother to describe the safe predictability of the behavior of her family and the word trust used by computing scientists who make no assumptions.

Nuclear Weapons & Linux A1-Sauce

[Anonymous Coward]

I would agree that open-source systems have the greater opportunity to be more secure than their closed-source proprietary counterparts. However, security is not all or nothing. It's a matter of how much you need, and how much you can afford. A company needs to protect its trade secrets more than I need to protect my computer checkbook program. A government needs to protect its information more than a large company needs to protect any of its intellectual property. An Oracle Dbase on a pack of carefully administrated linux boxes is probably fine for a company to keep its important, sensitive information. However, a government and a military organization, in particular, need much more rigorous security. There are formal specifications for serious computer system security: http://www.radium.ncsc.mil/tpep/process/faq.html
For comparison, Microsoft NT, specially configured, was certified "Class C2: Controlled Access Protection". Sun's most secure OS, Trusted Solaris 1.2, made "Class B2: Structured Protection". Could an open-source project produce a B2 system? What about achieving "Class A1: Verified Design"?

It's not black-and-white

[p3d0]

They make it sound as though a system is either "trusted" or "non-trusted". However, how many formally-proven systems do you actually ever use? Probably not very many.

Of the remainder, I trust the open-source programs more than the closed-source ones as far as security goes.
--
Patrick Doyle

It's "Trust" not "trust"

[jopasm]

There seems to be some, confusion about
what is meant by "Trust". Notice it's spelled with a capital "T"? It has a specific meaning. It's not "I trust my home firewall to protect me from most attacks", it's "This product has been built with XYZ design goals in mind, with strict auditing controls to ensure compliance". See Redfang's post http://slashdot.org/comments.pl?sid=00/06/21/13332 22&threshold=0&commentsort=0&mode=thread &pid=198#206 for a better explanation than I can give.

Sensationalism!

[Anonymous Coward]

This article seems to have been posted from a viewpoint that doesn't-quite-follow-it. This definition of "trusted" and "formal specs" is no arbitrary definition; it's a discussion of mission-critical software in genuine software-engineering-as-a-science terms. This doesn't reflect on basic coding of software, but on the science of create a mathematical solution to a mathematically designed problem. The discussion is not oriented towards writing a desktop, or often even server OS or application. Be glad we use formal specs! It means your airplane won't BSOD on you.

A formal spec is a mathematical document (and a painful one at that; to define a stack takes several pages of symbolic gunk!). To learn how to write formal specs is at least an undergraduate course of its own-- to learn to do it well and fully is several courses of work.

There's a point to using a formal spec. Because of its mathematical nature, a formal spec can be verified for completeness. In addition, depending on the implementation language, a program can be mathematically verified to be compliant with the spec (this trick works best with ADA). That's the definition of trusted. Not only have we formally described what the software does, but there are rigorous mathematical/logical means of proving that the software does what it should.

This doesn't say that it's impossible to create trusted software with available source code. This does say that ad-hoc bugfixes are not verifiable mathematically. And I thought a college degree was a total waste of money :P

In summary, it's not that I don't use Linux. It's just that I wouldn't expect Open Source to produce a Hard Real Time OS for keeping the local nuclear power plant from exploding.

Trusted to do what?

[HiThere]

Open Source is good at ferreting out bugs, but for this purpose it is orthogonal to proper design.

The particular strength of Open Source is that it difficult to hide what the software is doing. This is improved by structuring the program well. Trapdoors become more difficult to conceal, etc.

If we claim that Open Source and Structured Design are orthogonal, then the optimal place of the matrix (optimax) is where they intersect. But please remember that degree of trust is a problem with more than two dimensions.

Trusted my arse

[pac4854]

Just knowing that Windows NT has been successfully evaluated at C2 makes me doubt the validity and usefulness of the entire TPEP program. Might as well just design a new security spec(OSS-SEC) around the existing Linux kernel and submit the product for testing.

Does Open Source have back doors? Well Maybe yes.

[Big Torque]

The point I wish to make is not something I think is happing but that it could happen and we all need to understand the problem and the solution. A close friend of mind told me of a story where Ken Thomson added back doors to UNIX by modifying the C compiler. The source code of the compiled programs where clean but the compiler added the back doors. He did this back in Bell Labs with the first C compiler. The whole in Free or Open Source software that is that you need to compile your program with a binary program not the source code. Even if you use GCC you still need to compile your fist GCC program with some other binary compiler you must get and trust form somewhere. You are stuck in this chicken egg problem in which you must trust some one else's compiler. In turn the person or company you got the compiler from must trust someone elses compiler. If the government or anyone else wanted to crack into the GNU/Linux world they would make a compiler that put in back doors in to GNU Login, Telnet, FTP, etc programs even the Kernel. They have the source code and often not changed. They know what to do. They will be able to make the compiler know how to recognize and these programs and how to modify them. Now for the scary part they also know how to put this ability into GCC. So when you compile GCC it becomes as corrupt as the first compiler. There is no way to know about the first binary program the compiler you must be able to trust. The solution to fix this is clear. The first compiler should be written in assembler. This allows the program to be dissembled and checked. It can be a very simple compiler for you can add the other features by compiling your GCC code with it. This way you have clean source code and clean first binary compiler and clean system that can be proven to be free of back doors. This problem is a threat to closed source software as well but the lack of open source code makes it harder to know what the compiler needs to recognize and how it needs to modify the programs. With the use of an assembled compiler you can take this weakness of Free, Open Source software and make it a very strong point. I do not know if a C compiler written is assembler is available. Maybe one needs to be written for every platform x86, PPC so on. I know that everyone I know and myself who has and does compile programs always use and trust their first binary compiler. Is this happening I do not know but as long as we don't have a provable clean first compiler we will never know.

Spaf's right

[PotatoMan]

Spaf is absolutely correct that 'Open Source' has no bearing on security. Free software is about freedom, and Open Source is a marketing ploy. Neither philosophy has anything to say about security.

I disagree that a trusted system must be designed from a specification. I assume Spaf is not foolish enough to think that a spec is any more magic than Free software in terms of assuring security. He seems to imply that a trusted system must be designed and built from scratch. This is most certainly not true. Reimplementing an OS from scratch is hardly necessary to ensure security. Certainly, it is necessary to have a formal specification that can guarantee the security of your system meets the proper criteria.

NSA uses COTS OS'es for classified work. What they have is a process which certifies that an OS meets some level of security. They also test the actual installation of the system, including covert channel analysis. While I am sure the NSA has 'purchased' a source license to all Microsoft products, there is hardly a need for them to build an OS from scratch.

Whether you use Windows, Unix, VMS, or Spaf's Trusted OS, the process for securing your system is the same.

commerical vs. proprietary

[MrChips]

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.

<rant>
I really wish people (especially slashdot editors) would get the terminology correct. It's commercial vs. non-profit and proprietary vs. free/open source. These are orthogonal concepts. There is nothing weird about a company that sells open source software. Lots of companies do it these days. RedHat (like all other software companies) sells nothing but commercial software (by definition).
</rant>

Regarding the topic of the article, I certainly wouldn't trust proprietary software. I can't even figure out how it works, let alone what it's supposed to do. I also wouldn't trust a car that didn't let me open the hood and see how it was constructed. I see nothing inherent in the open source model that prevents adherence to design goals, certifications or regulations.

Trusted systems? Standards?

[Octoberfest]

I've said this before but I'll say it again:

It is not the responsibility of the Linux distribution or the OSS developers to make their software secure.

High security computing is a process, not an out-of-box solution you can buy or download from a website or FTP server.

GPL software is designed to be fixed and improved, and while Dr. Spafford may have a point with "infosec standards", I can give you an example where the GPL actually improved the security of the Linux kernel.

The following is available at www.rootshell.com:

[ http://www.rootshell.com/ ]

Date: Tue, 1 Jun 1999 17:43:17 +0200
From: Piotr Wilkin
Subject: Linux kernel 2.2.x vulnerability/exploit

I'm sorry if this has been noticed before, but since I did't find anything
in the archives, I post it here. There seems to be a bug in kernels 2.2.x
(tested on 2.2.7 and 2.2.9), that causes them to panic when they are sent a
large number of specific ICMP packages. I think the problem comes from the
combination of the mangled header length (shorter or longer ihl's don't
cause hangup) and the random ICMP packets (random type/subtype and source
address) this program sends. Windows 9x and FreeBSD 3.0 seem to be
unaffected.

When an ICMP denial-of-service attack threatened Linux kernels 2.2.9 and pre-2.2.9 (at that time, most distributions shipped with 2.2.9 or pre-2.2.9)
debian used 2.0.36 or something, the exploit was not only posted, but immediately fixed by none other than kernel hacker extraordinaire Alan Cox.

Besides the internet security alerts, CERT, rootshell, etc, i don't believe that this even made the evening news in most major markets. Unlike Outlook Express exploits, Linux bugs get fixed, and they get fixed quickly.

So if you want a secure system "solution", get a system and unplug it from the internet and build a brick wall around it, hire some armed guards, and only use one-time pad passwords. I'm not joking, and some of this is even suggested by Dr. Spafford and Simson Garfinkel in their seminal book, "Practical UNIX and Internet Security", which I read and enjoyed about 2 years ago.

Anyways, I think Bruce Schneier's article about OSS and security that appeared in Linux Magazine a while back was more informative and stressed the strengths of OSS for system security.

Re:Open Source is Absolutely NOT Darwinian.

[Kaufmann]

THANK YOU! The fact that this ridiculous, absurd and fallacious dichotomy between "macro-evolution" and "micro-evolution" has been so widely propagated (and, in fact, is accepted by pseudo-scientific creationists despite the huge amount of evidence against it, simply because it's a nice, cozy way to acknowledge the existence of the evolutionary process while still managing to shove a God of the Gaps into it) is a true tribute to the idiocy of today's "anything goes", "everything is true if you want it to be" postmodern society.

I, personally, have had enough of it. Nobody, I repeat nobody, gets to shove postmodern dogma down my throat.

Why do spec's matter?

[bbqBrain]

The real evaluation of a system should be in TESTING. So who cares if you didn't develop your software by a formal set of specifications? Draw up a comprehensive suite of tests that will "prove" the system to be reliable, and judge the trustworthiness of the system by its performance in these tests.

Unless, that is, you want to blow an inordinate amount of money on closed-source development. I imagine this argument for trustworthiness of software is used often in government agencies very big on documentation, process, etc...not that any of these are bad in moderation. But government agencies do have a budget to spend every year. If they operate efficiently in one period, they will be expected to do so in the future (i.e., their budget will be cut). "Oh, no! We've got to spend the taxpayers' money wisely!"

In the ABS example, simply run rigorous tests of the system to ensure that it behaves properly in all conditions. If it fails and the car smashes into a wall at 50 mph or the brakes lock up, no, of course you can't trust the system. If everything operates correctly, what the hell is the problem?

Re:Why do spec's matter?

[scheme]

In the ABS example, simply run rigorous tests of the system to ensure that it behaves properly in all conditions. If it fails and the car smashes into a wall at 50 mph or the brakes lock up, no, of course you can't trust the system. If everything operates correctly, what the hell is the problem?

The problem is that you aren't sure that your tests cover all the cases and that you haven't left anything out. More importantly, you aren't sure exactly how the system should react in all situations. For instance, what should the maximum response time on a component of the system should be? If you don't specify this then you can't test it to make sure the system responds correctly. BTW, you need specifications like this in order to make sure the system can handle the environment its in and doesn't say start applying the brakes too late.

Basically what the formal spec does is it lets you determine how much testing you need to make sure that you've covered all the cases and that the program will respond the way the spec says it will. Personally I would prefer a software that went through this sort of procedure rather than the first public release of some open source program controlling the brakes on my car or the controls on the plane I'm flying in.

what is this spec?

[josepha48]

It would be nice to know what the requirements are of this spec. If the spec were or is an open spec it would then be possible to make Linux, OpenBSD, or any other OS abide by this spec.

I think that it is important to understand as some have pointed out that trusted does not mean secure. This is one of those english language semantic things. Trusted means that they have a set of requirements that this OS / program is supposed to do and it does them. Basically they can trust that if this happens the software will do what they wanted it to do. Secure means that if someone tries to hack in or exploit a buffer overrun then the system wont let them. OpenBSD is secure, NT is trusted. This does not mean that NT is not secure, it is in its own right, but I wont get into that. It also does not mean that OpenBSD cannot be made to be trusted either.

The advantage to them of Open Source would be that if the sytem is not trusted, they have the source and can make or have the system made into a trusted system.
Wouldn't it make more sense for them to take a secure system and make it trusted as well?

Just my .02 cents, but I think that the goverment needs to start rethinking some of its policies of doing things.

send flames > /dev/null

doctor?

[KarmaHo]

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

What exactly does "Dr. Spafford" have a doctorate in? Whatever it is, it certainly hasn't got a thing to do with computer science. Maybe marketing. Maybe he has Ph.D in F.U.D.

So this means...

[Anonymous Coward]

That all programs have to be proven mathematically in order to work?

(Yes, I know that's not *exactly* what the guy was saying, but taking it a step further helps me prove my point.)

IIRC, just proving something correct or secure doesn't actually mean it will work. In the last book I read, an example was given of a program that would do word wrap for text. It went through the entire process of planning, documenting, and at each step they did proofs of correctness on their psuedo-code and their actual paper code before ever entering it into the computer. The actual program that they ended up typing up had countless errors (not working on one line pieces of text, really long words screwing it over). Working from those mistakes, they went back to the design process and tried to fix them, and re-proved the program "correct". As it turns out, even more bugs.

All that work for a 20 line program.

As I told my calculus professor once, "That's alot of work just to get it wrong."

Yes, proving something mathematically, or going through all the design processes to create a program can help make it stable, secure, and all those other great things, but the guy forget one of the most important things in finding holes and bugs. A test suite... and what better test suite then thousands of smart users using the program every day?

The long-winded AC

Yikes .. don't turn this into a holy war just yet

[xyst]

I think people are mildly misinterpreting this. There was no bias mentioned against open-source software whatsoever, just the mention that many open source projects do not contain outlines and whatnot for what they'd like to achieve as a project, and without having goals set have no method to be gauged sa to how secure they really are. However, this is just as true for open-source as it is for closed-source projects, and what makes it even more scary is the fact that they may meet a standard outlines in their product, but with a closed-source solution you have no way to prove that it was implemented and designed in a secure method appropriately. Closed-source products already imply a level of trust when you run their software that most people don't consider -- certain applications can do whatever they like behind the scenes and you may not even know about it. I believe the makers of rz/sz z-modem transfer suite attempted to implement an accounting system to see who was using their code silently, and because it was open-source, this was caught and dealt with. Who knows what various Microsoft or other-vendor closed-source projects are doing behind the scenes?

-gnp

There's no compiler for the specification

[KurtP]

This notion, that a formal specification somehow implies good design and testing, has always been incomprehensible to me. I have read numerous specifications. In no case has one been sufficiently detailed that I would consider it a basis for trust of a system. I have literally never seen such a specification. Invariably, they are littered with inconsistencies, bugs, and ambiguities. Obtaining C2 trust, by following the "specification" tells me relatively little about how vulnerable the system actually is.

Reference implementations are another matter altogether. I can examine their specific semantics, find specific vulnerabilities and strengths, and in general evaluate them precisely.

Which points to the old adage - "There's no compiler for the specification" - which makes the point fairly well. Natural language is an awfully ambiguous instrument for specification, and even the most careful specifier makes errors which can go undetected in the specification for an indeterminate period.

I personally find open and available source a _far_ stronger basis for trust than any detailed specification and planning.

informal hackers verse formal standards

[Sheik Geek]

>Trusted systems are built according to a formal >specification and are tested and confirmed >against a formal testing and standards process. Most hacks are out exploited by two ways. 1) Poorly implemented standards, 2) creative uses of resources. When the standards are not open and completely available hackers will reverse engineer. The linux Creative Labs DXR-2 driver. Other Hack would involve creative, non-standard, or even informal uses of resources. Using programs or item for things they were not intended to do.

My experience is quite different

[Quincunx42]

First, let me start off by saying that automation !(necessarily)= good testing. It can, but does not guarantee a trusted system. As for Dr. Spafford, I don't see why he thinks open source projects can't be put through rigorous (standardized) test to achieve "trustablility". Automation could take care of most of this, but it all goes back to design. If the code AND tests are not designed properly, then you don't have jack.

Are you talking about mixing testing and design with coding? That's a bad idea.

(please correct me if I'm misunderstanding) The quote above explains why Spoing has such a difficult time with automated scripts. My personal experience has shown me that the ONLY way to successfully automate a project is to have developers and testers working tightly together from the very start (including design phase). Without having QA review the initial design, and keep close contact/communication with the developers throughout the rest of the process, automation is useless.

When working this close, creating automated tests prior to handling the code no longer becomes theoretical. Scripts do not "break" as they are updated with the new changes before testing the next release. Yes, automation is a development project in itself, but can be worth it if done correctly. The idea that "Mixing coders and testers in the same group is just a bad idea on multiple levels" is what creates messy situations in regards to automation. However, if you're talking about coders testing their own project, then I agree. Otherwise, you're describing glorified beta testing (throwing code "over the wall" to testing).

Re:My experience is quite different

[Spoing]

Are you using automated testing across an entire project? If so, and you find it benificial, tell me how. I've only found limited application of it, and it required quite a bit of maintenance to get those results.

1. Scripts do not "break" as they are updated with the new changes before testing the next release.

This doesn't sound like the earlier posts. Script changes after the specifications are created isn't the same as scripts that are made once and run throughout the project. Making updates can suck up an amazing amount of time.

Are you talking about testing at the end of a cycle, ongoing, or both? The projects I tend to do usually have a GUI-intensive part covers a few hundread forms plus related specialty screens. That part doesn't work well with automated tests. The backend parts do, though, since the interface to them tends to change very little.

For me, testing starts with a formal test plan (from the spec), occurs constantly, and the remaining time is used to plan for the milestone releases and do documentation. Automated testing is time consuming and isn't worth setting up for most rapidly changing projects. In limited parts, yes, across the whole project noooo.

1. However, if you're talking about coders testing their own project, then I agree.

Yes, definately. Each group talking as early as possible and hashing out the details is definately benificial.

I wouldn't dare create a script for something that's changing on a regular basis unless it were small or I had a big staff (about ~1/2 size of development group).

If you get away with this kind of thing and don't drive yourself mad, I'd like to know how!

Re:My experience is quite different

[Quincunx42]

One of my former employers had a product with 14 applications and nearly everything was automated. Maintaining the scripts was a daily process, but only consumed an hour or two each morning at the most (15 minutes to review results if nothing went wrong).

We would start automation as soon as we had even the smallest idea of what was to be built. Daily communication with the developer allowed me to change my scripts to match the (new) expectation if anything changed.

It's hard to separate GUI testing from data testing (as far as determining a ratio), since some scripts did both, but it was very GUI intensive. For me, automating the GUI was the most beneficial because it allowed me time to create more intelligent tests instead of wasting my time with thousands of "dumb" tests (i.e. click button; expect dialog... ad infinitum).

Automation is very time consuming initially, but if planned and written correctly, the payback can be HUGE since the team isn't bogged down with mindless tasks and can focus on bigger issues instead of "buttonX displays dialogY = pass". We had a team of 6 QA to 30 devs, so it was hardly a 1:2 ratio. It's just a matter of making it part of the (daily) routine, keeping informed of changes, and writing code/scripts that are easily modified.

Open source is not for everyone

[Natak]

I'm excited about open source just as much as the next slashdot reader. I am amazed at what open source has is capable of, and I'm sure open source will continue to amaze me as time goes on. I know this sounds closed minded of me, but open source is not for everything. Let me give two other examples of software development of trusted systems: life support systems, and missile guidance systems.

What makes open source successful is the community. One strength of the community is a very large group of talented QA. If something does not work as it's suppose to, someone WILL catch it. (Who knows maybe even fix it). Now lets try this with life support systems, First you down load the latest code and put it on your life support system. You know there can be issues with it, but hey its free and lots of people worked on it, more so than any other life support system to date. But damn it doesn't work as its suppose to. Well just fix the code and check it back in.

What about missile guidance systems. I know of a software house in Ogden, Utah that writes such systems for the air force. From what I know, they have one hell of a development process that results in less than one bug in a million lines of code. I assume I don't have to explain why this is important to the air force. (Talk about mission critical software). From what I've heard about this development process is that it works, and works well.

The two examples I've given are of critical systems that have to be trusted by their nature. I'm not saying that trusted systems can't benefit from open source, they can. The way I see it, open source works best on high profile, very horizontal market (commodity) projects that don't expect the highest level of trust.

I think its arrogance to think that software development is only OS's, Web browsers and web servers; There's a lot more types of software written every day out there. Its also foolishness to think open source can solve all development problems. Yes tt's obvious that the two types of systems I named above would never be open source, all I'm doing is explaining some of the reasons why. Natak

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

Well, DUH!

[spitzak]

Of course Linux does not follow a formal spec. Nor does Windows, or BSD, or probably the system the NSA uses, or the SABRE airline system, or your bank or insurance company, or anything even remotely interesting.

A "spec" is just as complex, or more so, than the system it describes. Exactly how do mortal humans write a "spec" that does not itself have "bugs"?

In fact the source code is probably the most accurate "spec" around. At least we are guaranteed that the implementation matches...

Re:Does Open Source have back doors? Well Maybe ye

[ReconRich]

This is all true, but there are bigger, closer dangers than invisible back doors. They're called buffer overflow exploits, and they're the #1 primo way of getting root on box. While a buffer overflows can be found on closed source systems (happens all the time), you can save a lot of hard work by looking at the code -- Plus it takes a lot less effort to turn a buffer overflow into a rootkit when you have the source. Instead of putting the effort into proving a good compiler, put the effort into the code that the compiler compiles. BTW, even things that people think are VERY secure have holes... I recently read about a buffer overflow exploit in Kerberos. Having your KDC rooted is a Bad Thing (tm)

-- Rich

Yes, but not always

[Ozwald]

I believe that Open Source can be trusted, but not because it's Open Source. The software I have seen and downloaded have come from hard working ethical developers bent on providing the best software they are capable of. This compared to Windows shareware that tend to be crippled in ways that hide their bugs in the name of "not available in unregistered version".

As of now, you can download any program from Freshmeat and use it without worring about it being malicious. Atleast right now.

But I am wondering about the future. Although a program running can only clobber files the user running it owns, installing programs generally require root. Any program that is installed by "make install" or "rpm -i" are going to require temporary root access during install.

What I am asking is, is there a way of installing shared applications on a system without root? Is it possible to log in as a user that is capable of installing applications into /usr/local without being able to destroy other peoples files? If so, why doesn't anybody do it?

Ozwald

Open or Close is irrelevant

[Skapare]

Neither open source nor closed source by itself makes a system secure. There are way too many systems, both open ones and closed ones, that are swiss cheese, to even think that security can derive from either mechanism.

With regard to security, what open source would allow you to do is verify whether or not a given system truly is designed to a rigid trusted specification. None are now, and OpenBSD seems to have the greatest potential. But I'm absolutely NOT going to trust the security of a closed system just because the marketing folks, and their hired security consultant, says it's perfectly secure.

The question I think is this: If you do have a system you believe is truly secure, does making it open source compromise that security? I believe that if it did, it is flawed in design and can't possibly meet spec.

Where closed systems get an advantage with regard to security is when they are really not secure. That advantage gained is a delay between market introduction and discovery of its insecurity (perhaps by reverse engineering).

So your Corvette doesn't have a portapotty

[Art Popp]

Wah wah wah.

Would you want your pacemaker microcode to be writen by the people who created the burned-metal skins for XMMS? Me neither.

Trusted software is not worth the cost and is inappropriate for our 95% of what Linux users do. It helps to make my point if you substitute the words "Mathematically Proven Correct" for the word trusted.

It's a slight simplification, but it eliminates the notion that Linux isn't trustworthy, because of course it is. It is more than trustworthy enough for what we want it to do. It is vastly more trustworthy than any software developed in Redmond, WA.

Formal standards and procedures slow the evolution of a software product to a crawl. For a pacemaker this is fine. For a hype-versatile desktop OS this is silly.

My actual point, be careful what you wish for. Every version of RH software has more cool features added then the last 3 versions of HPUX. This is an excellent trade.

It's not open-source, it's UNIX.

[Animats]

The problems:

• Security cannot be achieved by debugging.
  Read the decade of CERT advisories for Sendmail and BIND to convince yourself of this.
• Linux, and UNIX, contain some terrible basic security-related design decisions.
  The notion of "root" is bad enough, but "set-UID to root" is worse. This results in far too much code being trusted. In particular, it should be impossible to run non-trusted code as root. This means no root log-ins, for example. In a secure system, as your privileges go up, the amount of software you're allowed to run goes down. In a sandbox, you can run anything. As administrator, you can only run a few tools that do very specific things with lots of checking. This is completely alien to UNIX.
• Fixing known holes only protects against the inept.
  A serious attacker will find their own holes, and will keep quiet about them until they break in and steal something. Fixing known holes protects against script kiddies.
• If you don't have a security model you can write down on a small piece of paper, you can't enforce it.
  DoD has a simple security model, which is reasonably enforceable. See the Orange Book. There's Linux support for it. You take a performance hit and can't run some popular software. But in that direction lies real security.
• Discretionary security doesn't work.
  With discretionary security, users can turn off security. "chmod 777" is the usual way. With mandatory security, if you're processing SECRET information, nothing you or your programs can do makes it non-SECRET. The problem with discretionary security is that it's extremely difficult to tell if the system is in a secure state, and it's very easy to make a change that opens a security hole.
• Secure systems are no fun
  OK, you've got a secure system. Want to run Napster? No way; it's acting as a server and transmits your files. Want to download a game? If it will run in a sandbox, OK, but it can't talk to other players. Running a web browser may be OK, but the browser will be shot down if it tries to launch MS Word to read a .doc file. And the browser will need some work to live within the restrictions of a secure system.

A secure open-source system is quite possible. But it won't be Linux as we know it.

Linux-privs

[jeffry_smith]

No one has mentioned it yet, but there is are efforts (with overlap among those involved) to add formalized security to Linux:

Linux-privs

SGI's B1 code

So, the benefits of Open Source combined with the trusted security of specifications

He is right

[X-Nc]

No Open Source OS, and 99% of the propriatary OS' aren't and likely can't be clasified as "Trusted Systems". There is an actual, formal definition of a "Trusted System" and it has nothing to do with how much any one trusts it. It has to do with specific procedures and designs that follow a very exacting standard. This doesn't mean that Linux or OpenBSD aren't secure. Security is not the same as Trusted in this respect.

For an example of a "Trusted System" you might want to look at something like MLS+ (which is the only trusted system I've ever had hands-on experience with). Once you see what a real trusted system is like you'd be very glad that Linux, et. al. aren't in the same catagory. It's not easy working with an OS that won't let you do things like cd or ls and such.

---

Nothing/Noone should be trusted! Trust Code??????

[iv20]

Trusted - Firm reliance on the integrity, ability, or character of a person or thing. Security - Freedom from doubt, anxiety, fear, risk or danger. Standard - An acknowledged measure of comparison for quantitative or qualitative value (dictionary.com) I have arrived at a place in my life where I can't and don't trust anyone or anything. The idea of trusting code is silly nonsense to me. So no, Open source cannot be trusted. Wen I explain the great divide between open source and commercial software, I say something like "Linux is a version of a virus that will eventually be responsible for bringing the current evil empire crumbling down. The barbarians from the north brought rome down, and a student from the north Linus Torvalds will be a God who returned to being a man after starting the fire. Linux was/is created/maintained for beauty sake never for the sake of profit or in adherence to a standard" I think Dr. Gene Spafford and the whole civilized would be crazy to rely on or trust the integrity of a work of art like code and should be damn scared of a world without their security and standards. I look forward to our species (human animals) abandoning technology and all other remnants of civilization when it comes time. Until then those of us who tell computers what to do, dont much care what their account balance reads, and really dislike being a user at the end of the day should throw our fuel/code/art into right fire. Chaotic = Beautiful Ordered = Enslaved Jeffro@iv20.com (Note to self, this is the first 2 cents you have contributed to that wonderful work of art know as slashdot, your interfacing with profitware to do it, you have been adding your art/code to the pile not the fire, and you are almost out of your cage/lease. We think it would be nice if you made to jump from Enslaved to Beautiful)

Real World

[ibpooks]

Fuck organized tests. Linux is developed in the real world to solve real problems. It doesn't really matter if it's been developed in a secure planed test lab--- Linux developers write code to work in the real world that protect against real world threats.

Word games

[Troy2000]

If you pay close attention to what that guy said, what he's done is *define* the words "Trusted System" to mean a system which has been verified as trustworthy by some well-defined producedure or test.

He can bake up any definition for "Trusted System" he wants - it doesnt mean he's right.

What about TrustedBSD

[lomion]

In the works is a trusted BSD, TrustedBSD. It is aiming for some of what that doctor wanted, if not all. Nice thing is you will be able to pull the changes (eventually) back into FreeBSD on which it is based.

So let's formalize it.

[Nicholas Vining]

As part of a paper that I put together a while back as a rebuttal to the "Linux Myths" thing by Microsoft (which, unfortunately, I never got around to releasing...), I seem to recall that one of the complaints was that Linux didn't comply to any formal security standards. The rebuttal that I used at the time was that is was solely through lack of money, and not through quality.

An approach that we could look at would be to have a free, (as in beer, as in speech), funded by donation, organization to test and issue security compliancy licenses in a well thought out, academically proven manner to open source software. While it would mean that the closed source world might not acknowledge it immediately as a standard, it would mean that we could then say "Hey, we're using academically developed processes, just under a different name, and ours might even be better than yours."

The real challenge would be figuring out if we can conduct an academic review under an open development model. That would be cool.

Nicholas

Re:So let's formalize it.

[warmi]

You saying that companies like RH _can't_ afford to pay for testing and eventual certification with formal security standards?

Without access to the source code, it's useless.

[Kaz Kylheku]

If you cannot see the source code, then all the formal design or testing amounts to nothing. At best, you have someone's guarantee that the system is secure.

Also, empirical tests are insufficiently strong to prove anything. You can test the binaries ad nauseum and not find every security flaw.

So basically, this is just another bullshit attack on free software.

Too simple, was Re:I agree with him

[coolgeek]

IMHO design specs cannot encompass what is required of a system to be "secure". There are too many clever and devious hackers that will find the hole in the design. Besides, as we have seen, they never adhere to any "test plans" when illustrating a vulnerability.

OTOH, if your design specs are broad, such as "Can survive many weeks on the Internet, while being subjected to review and/or attack by anybody, friendly or hostile without causing a loss of service or revealing sensitive data", I believe Linux and other free or open source software has the best chance of satisfying this requirement.

What I see here in the Author's question and Dr. Spafford's opinions is really a philocophical choice. In two dimensions, it's Darwinism vs. Creationism and Full Disclosure vs. Obscurity. I choose Darwinism + Full Disclosure.

Free, not open source

[LoonXTall]

proprietary vs. free/open source

Nope. Proprietary vs. free. As Apple and Sun are trying to prove, open source != free. Open source is merely an attribute that can be attached to any program, and is often misleading because it _is_ attached to all free ones.

-- LoonXTall

Can we trust ...

[wlj]

OK. Can he demonstrate that he was constructed and tested to the same standards :-) If you know who did the work, you are trusting the person rather than the process. (Which still says you should be cautious ...)

Chaotic?

[deno]

His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state.

It may be true that lot of free software starts its life chaotically. However, claiming that big, succesful projects are developed chaotically is complete nonsense. The proces of specifying the direction in which free software moves is different from what people working in traditional software developement may be used to. Maybe these new organisatory schemes are difficult for Dr. Spafford to understand, but claiming that developement of "Apache", "Gnome", "KDE"... are chaotic is complete nonsense.

As for the question wether Open-source project can become "thrusted" or not, this depends on only two factors:

• Goals of the project
• Your personal definition of "trusted system"

If these two are in synch, chances are that Open source project will reach the state where you can trust it much faster than a project coded in traditional way.

What is Trust?

[jaklein]

I've crashed my NT desktop at work twice so far today. My Linux box at home never crashes. I think you definition of "TRUST" is too qualified and prefer my more emotional one.

Linux-devpt model - not a formal method

[nvm]

The way Linux and other open-source projects have been developed do not belong to any of the 'traditional,formal S/W development life cycles'(water-cycle model,etc). These are just evolving models. The metrics reliability & quality (if thats what they mean by trustedness)of a s/w are defenitely not judged just by "how many people are working and how many bugs have been debugged",but they are like how easily can we detect/fix a bug?how easily can we make modifications? etc. Thats what the CMM is also about.
All that he's trying to say is that if a s/w devpt. life cycle was rigorously followed, probably most of these bugs would not have arised.
But neverthless, this could be a new model of s/w development!!

Can modern processors be trusted?

[Silver A]

Since, according to an article in Ars Technica, modern processors will effectively rewrite code at execution time, can any program or OS running on a recent processor be considered a "trusted system" by the definitions used by Dr. Spafford and others?

Wow.

[mindstrm]

They are mixing up the development model with the final product.

Can "Linux" be trusted? What do you mean by "Linux"?

If you mean a particular kernel version, as released by Linus... there you have it. Can you trust it? depends on your criteria. Do you *need* to trust it, or can you simply take a certain version and stick with it?

Linux is more about a process than the technology.. open source is about lots of developers working together in a scientific (as opposed to market driven) way to produce better code and better software.

Re:Wow.

[Al Wold]

I think what he is referring to is the "end product". If I were to go out today and say, I would like to setup a Linux system and see how secure it is, I would probably choose something like Redhat, install it and evaluate it. With this in mind, there are plenty of security holes. Look at all the applications that come with Redhat. So, it isn't necessarily "Linux" that is insecure, but the distribution. Of course, how can you use Linux without a distribution?

I agree, somewhat.

[Al Wold]

Software which has the source code released to the public is usually a lot easier to find security holes in than the commercial software. Lets think about it like this... If you were a l33t hax0r, would you try and disassemble/debug a commercial binary-only program looking for vulnerabilities, which you might have trouble even getting ahold of in the first place, or would you just open up the .c file of a free program and look for stupid places where things like sprintf are used unsafely? I know what I'd do! That doesn't mean there are more holes in free software, just that they're easier to find.

He also has a good point in that things like Linux aren't developed to any particular standards. If you look at something like OpenBSD, they have sacrificed progress in things like device drivers, hardware support, and new features. As much as someone may say this isn't a "standard", it sure is in my opinion. They have done this so they can spend time doing exhaustive security audits to make sure the system is safe. With Linux, it seems that getting new features, hardware support, applications, etc. is more important. You could call this a standard too. And, this is why Linux is more popular, but if I'm putting together a multi-user server, I know which OS I'll choose.

Mr Dr. What'shisname just doesen't get it.

[MrJerryNormandinSir]

This Dude must get paid by Sun and HP to shoot his mouth off. Linux is as secure as you want it to be.

Re:Does Open Source have back doors? Well Maybe ye

[Schnedt McWapt]

Plus it takes a lot less effort to turn a buffer overflow into a rootkit when you have the source.

Good point. However, for some mysterious reason I notice that the 'no such thing as security through obscurity' people have backed into the corner, put their fingers in their ears, and are chanting 'na na na na.'

How About Secure Computing's products?

[dijit]

Here's an example that debunks both philosophies: Secure Computing's OS incorporated with their firewall product Sidewinder. There has been no Open-Source involved, no security problems, and guess what -- They have an excellent development methodology. Their development adhered to a strict set of guidelines and the product was not released until it was ready.

Just because you open-source code and/or have a publicly defined set of criteria to match doesn't mean that it's good or secure. Unfortunately, most companies release software before doing rigorous testing and hire cheap Comp-Sci graduates with no experience to write their software. Just because it works doesn't mean it works well. If we want good and/or secure software, we have to convince software companies that it's what we actually want and we can wait. Trusted systems (Like Trusted Solaris or Sidewinder) just have to prove that they adhere to their development methodologies and the criteria set forth by the certifying party. Trusted doesn't necessarily mean secure.

// dijit
dijit-at-half-truth.com

Re:How About Secure Computing's products?

[Rakarra]

Secure Computing's OS incorporated with their firewall product Sidewinder. There has been no Open-Source involved, no security problems

Uhhhh... you sure about that? Sidewinder runs a (heavily) modified version of OpenBSD. Audited, ACLs added, networking code rewritten. But there's still open source in there.

I don't know about other Open Source developers...

[namlhaz]

But I certainly build my own code to a very tight specification which I think out in painful detail ahead of time, even if I never actually write it down. Before my current project goes out the door, I'm making sure all comments are crystal-clear and sufficient to count as *documentation*; and I'm also putting in a separate file with suggestions on how to make modifications so as to be consistent with how I've implemented everything to date.

Could it be the..

[Mr. Last Post]

..last post?

Re:Does Open Source have back doors? Well Maybe ye

[warmi]

Gee, one can't even trust Thomson these days ...

trusting open source = reflexive systems

[basile.starynkevitch]

I (Basile S.) do agree with the poster. I do not claim that closed source is better. We all know it is worse (all things being equal). What is needed is more than OpenSource: it is reflexive systems. See www.tunes.org for more. Informally and in brief, a reflexive system knows about itself and can enhance, reason, prove, and check itself (or parts of it). I am convinced that reflexive system are the next step. They will supersede open source systems. (Actually, complete open source systems -such as a fully open, source form, Linux distributions- are already reflexive in an ill and poorly defined way, and perhaps some old Smalltalk or Lisp machines also where reflexive) (Proof-carrying code, a la Peter Lee, are also somehow partly reflexive). The difficult part is doing a full reflexive system. This mostly means start from scratch. Regards

Re:Not quite.

[GregWebb]

Er, one thing. Z isn't a programming language, it's a specification system. I'm sure my Z lecturers would agree that I'm no expert on the subject, but from all I was ever taught about it there simply isn't enough information in there to produce code directly from the spec.

Don Knuth's comment is worth bearing in mind, but it's a distraction in many ways. He's saying - or at least appears to be saying - that he has proved that the fundamental design and architecture is correct, but isn't certain that, in the translation of specification to code, he hasn't made a typo or two. That's still possible, but a very different source of bugs.

The problem with the standard 'open source' development model is that it's too chaotic to tightly control adherence to specs, IMO. That's what our original source here seemed to be talking about when he doubted whether 'open source' development could ever produce trusted code.

Your last two paragraphs seem to miss the point somewhat, though. A trusted system needs to have the specification tightly drawn up before a single line of code is created, if we wish to have any serious prospect of trustworthiness. If you try and draw up a 'de facto' specification after the event, it's inevitably going to contain problems as you're merely documenting behaviour that isn't necessarily trustworthy in the first place. Trusted reimplementation may be possible, but I'd still want a new codebase.

BTW, before anyone gets annoyed, the only reason I've been referring to 'open source' development as opposed to open source development is that, in this context, it implies something about the structure of the development team and that's mostly what's relevant. I could produce a project with a tightly controlled, exclusively internal team which decided to publish its source as it was going along. We'd still have source which was open but it wouldn't be conforming to what's normally accepted as the open source development model.

OCL: formal specification in UML

[GreyFairer]

Being a formal methods student myself, I'd like to point you to a specific feature in OO software engineering with UML, the well-known Unified Modeling Language.

It's called OCL: Object Constraint Language, and it can be used to model formal limitations on methods accessing your objects. A usefull site might be: OCL Home

This language could be fit not only to specify your goals, but also to 'prove' in a mathematical way, that your implementation is following the specification. At the Univ of Karlsrühe, the Key project is specifically aimed at developing software while always checking the specs automatically.

Maybe that is the direction that secure software should take, whether it's Open Source or not: first specify a formal "Security Constraint" in OCL and then start programming.

--Grey

Should we trust "specifications"?

[bkirkby]

Isn't this really just an issue of semantics? What the Prof. is saying, is that a formal specification will define what security is. While this may work in the academic world, REAL security is only proven over time in application. -bk

Trusted does not mean anything!

[Sq]

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?

I don't see the problem.
The fact that the system is more trusted does in no way imply that it is actually more secure.

There is great number of people that trust win98 security model.