“There have been a couple of runs at trusted operating systems in the past, but the difference between what’s out there now and what we’re announcing is that, in the Linux world, we’ll have trusted capabilities in a standard distribution,” said Paul Smith of Red Hat.
Go RedHat! This will be good for all Linux distros. The winds of change seem to be picking up speed, and this will only strengthen them more.
For those of us who use Linux professionally, it is good news.
To have RedHat and SUSE certified as a Trusted OS is great news. It shows those who doubt that it is anything but a toy OS that it is just the opposite.
For the majotiry of Linux users today, this news is irelevant but they should take heart that the OS they are using is up their with the best in History.
IMHO, Linus should be proud of his baby coming of age.
This is an accomplishment, yes. I’ve got CentOS (based on RHEL) running on a box here and its fantastic.
But you’re right, it means very little to most people using Linux, as the technology and testing doesn’t exist in most Linux distributions. Once RedHat recieves this certification, it won’t apply to even the clostst dirivitives, like the previously mentioned CentOS.
Still a big step forward tho, but I’d be more inclined to say that RedHat employees should be proud (and with years of bad experiences with RedHat under my belt, I find it painful to say that, but I’ve got to be honest! ;^)
As linux have their source code available (GPL) I don’t believe in security in linux operating system/distros, I’m afraid linux could have black holes, and using it in governments is for sure not secure. Any malicious programmer could advantage from source code of linux to exploit security. Windows is more secure, because windows is closed source.
Ok, let’s look at that.
Situation A: Open Source
Programmer A is a good guy. In the process of reviewing source code he finds something bad, and says “ooh, that’s bad, let me fix that”. He then sends the code back to the developer/community and says “I found something wrong.” Or, he informs the programmers at company C where something is going wrong.
Programmer B is an evil guy (with a goatee, naturally). He pores through the code and finds something bad. He tells all his friends where the problem is and they make exploits. He’s competing with Programmer A and D to find exploits.
Programmer C is another good guy, who pays attention to the Evil Programming Community (Motto: We wish we had handlebar mustaches). He finds out what Programmer B is doing, and sends a patch (or a notice) to programmer D.
Programmer D works at the company. He works away on his source code and internal testing, trying to spot chinks in the armor. He gets input from Programmer A, and finds out what Programmer B is doing from his contact with programmer C.
Situation B: Closed Source
Programmer A is a good guy. The most he can do now is notice if something goes wrong.
Programmer B plugs away trying to find exploits. It’s much, much harder going, but where there’s a will, there’s an evil way (Much mustache twirling). Anything he finds is widely disseminated and widely exploited.
Programmer C watches the Evil Software Community and figures out what they’re up to, but there’s not much he can do about it. Maybe he contacts Programmer A to try to work on a stopgap, but that’s it.
Programmer D works at the company, scanning his code, trying to spot problems with in-house testing before Programmer B hits pay dirt.
Now, which scenario is safer? In the open source situation, there’s three people helping secure the software and one person trying to destroy it. In the closed source scenario there’s… call it half a person trying to destroy the software, and one person trying to save it. (and then there’s the blindness that comes from knowing what you meant to write, and failing to notice that that’s not what you wrote down- that’s why I sometimes get someone else to help me proofread my English papers.)
This all depends, of course, on the relative concentrations of type A, B, C and D. I’m willing to bet there are more (though few) type A programmers than type B programmers, and more type D programmers than type C programmers.
While your scenario is interesting, here is another possibility. Programmer E is a professional programmer that works for organized crime or is a “hacker for hire”. He discovers a security problem with an operating system and tells only people who are interested in paying him to exploit these systems for profit. If the stakes are high enough, there will be “players” out there who are willing and able.
While this could be true for any operating system, it is particularly true of Open Source efforts, where the code is readily available. I also think you overestimate the capabilities of a lot of programmers who work on Linux. Many are not trained security analysts and I am sure a number of them are “cutting their teeth” writing code for various Linux distros.
Does getting the ability to limit access to resources through Mandatory Access Control improve security, not necessarily. It is just another tool that has to be used very carefully and well documented so that it does not create a security hole that can be exploited.
Oh, I’m assuming these people are very few in number- in no way could I qualify as a type A programmer, I barely have the skill (if even) to look at someone else’s code and figure out what the particular snippet DOES… I’m just making assumptions, and I don’t think either model really qualifies as perfect.
If we wanted to go there, imagine another programmer, Programmer F: He THINKS he knows what he’s doing, but despite his best intentions his fixes accidentally contain more bugs. (yet another thing for Programmer D to watch out for, but at least he has a bug report if the patch is awful)
I was assuming that I’m talking about skilled programmers, and I’m assuming (for a hypothetical program), # of (F >) D > A > B > C = E
Reality probably differs, especially if the project team consists entirely of type F programmers, in which case the sysadmin probably shouldn’t have that program on their network. I think there are plenty of very good programmers in the Linux community, so I wouldn’t count Red Hat in that category…
Edited 2005-10-30 22:41
Read the comment by somebody, because he has a point. The vast majority of testing is based on valid input, not invalid. For that it would require writing fuzzers and other tools to test the invalid input.
Another thing to consider is mistakes, nobody is perfect:
http://www.securityfocus.com/bid/15217
Security is not just about keeping the bad guys out, but limiting the opportunities for the bad guys inside the firewall to do damage.
Well, I’d take Somebody‘s comment as an argument that more eyes looking at the program are more likely to find problems- and if someone with experience can help fix them, that’s a good thing. Yeah, it’s easier for the bad guys to find problems, but it’s also easier for good guys to fix the problems they spot. I subscribe to the opinion that the benefits of increased openness outweigh the potential problems, and thus Open Source is not inherently less secure than Closed Source.
At least I think we agree that security through obscurity is a terrible way to go?
Most definitely security through obscurity is bad, unfortunately it is practiced on a daily basis by people who do not see the benefits in upgrades. A previous place I worked at we had several SunOS machines running because the management would not spend the money on updated applications (and an OS upgrade). Some of these machines had direct connections to the Internet, you get the idea.
I’m just a little more cautious than most people.
Yes and we all know closed source is moreeee secure …. ye right
Come on the argument closed/open is sooooo 1980 … get your facts right 
Anyways it’s good we migrated a lot of server recently to RHEL 4 and we have 100% faith in what direction redhat is going too, first SELinux and now TCP… I hate TCP when it comes to DRM but using server side is a good addition to your computer security.
take care though as this certification stuff is a way to lock the market.
Indeed, what will you want else than redhat then ?
What will happen in a world everyone uses redhat ?
Did you know that the whole very big majority of kernel developpers are from red hat, and that they make the decision over the kernel design ? Over what’s getting into kernel ?
What you do if linux become finally another product, taking away much of yhe freedom we gave into it ?
Because its slowly happening.
And redhat is here to make money, not to make you happy, they cannot be clearer about it.
Did you know that the whole very big majority of kernel developpers are from red hat, and that they make the decision over the kernel design ? Over what’s getting into kernel ?
Bullshit. http://www.livejournal.com/users/kernelslacker/29911.html
And redhat is here to make money, not to make you happy, they cannot be clearer about it.
so far they’ve been doing both. If I like Redhat anymore as a company id have to get paid too. This is a excellent company and deserves every pat on the back it gets.
Lame troll but I’ll bite, with some help from Wikipedia. Security through obscurity has been proven ineffective long LONG ago.
The argument against security by obscurity is based on Kerckhoffs’ principle from the late 1880s, which states that system designers should assume that the entire design of a security system is known to all attackers, with the exception of the cryptographic key: “the security of a cypher resides entirely in the key”. Claude Shannon rephrased it as “the enemy knows the system”. Historically, security through obscurity has been a very feeble reed on which to rely in cryptographic matters. Obscure codes, cyphers, and crypto systems have repeatedly fallen to attack regardless of the obscurity of their vulnerabilities.
Software which is deliberately released as Open Source can never be said, certainly in theory, and in practice as well, to be relying on security through obscurity (the design being publicly available), but it can nevertheless also experience security debacles (e.g., the Morris worm of 1988 spread through some obscure — if widely visible to those who bothered to look — vulnerabilities), though the frequency and severity of the consequences have been rather less severe than for proprietary (ie, secret) software. The reason for this divergence has been attributed to the theory that many eyes make all bugs shallow (see Linus’s law).
will this be in fedora first?
[i]will this be in fedora first?[i]
The code is likely to be in Fedora first with many of the pieces like MCS and MLS SELinux already in the development treee but Goverment establishments require a commercial certification against a product and this is what RHEL 5 targets
If free software foundation could change GPL licence versions, someday we will have a GPL closed source licence:) The source that programmers have done as a hobbie will be used by the company’s that own that code…
PS: the opensource programmers are sooooooo stupid.
>>>RE: the security of a cypher resides entirely in the key
Are you kidding:) we programmers could always find the key using BEOWULF clusters:P and if we have the source, more easy is to find the key, because we know the code structure:)
I’ll take it that you are not a cryptographer. So, you can easily find a key with a beowulf cluster? Lets see…suppose we have symmetric key block cipher (we’ll choose a 128 bit blocks) with a 128 bit key. A symmetric key cypher is basically a function E:KxP->C where K is the keyspace (set of all possible keys), P is the plaintext space (set of all possible plaintext blocks), and C is the ciphertext space (set of all possible ciphertext blocks). With a 128 bit key, the keyspace has a cardinality of 2^128 (think about it!). 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 = 3.4×10^38. Now suppose you had a machine that could try 10^12 keys a second (thats 1 trillion keys a second, and trying a key takes more than a single operation, so we have a machine that is a multi THz machine). How many seconds would it take on average to find the key with a brute force method? Well, on average, you would only (!) have to search half of the keyspace, which in this case would be 1.7×10^38 keys! So, this means that it should take 1.7×10^38/10^12 = 1.7×10^26 seconds. How long is this? Well, there are 3600s/hour, and 12 hours a day which gives 43,200s/day, or 15,768,000 = 1.5×10^7s/year. Thus we have 1.7×10^26s/1.5×10^7s/year = 1.1×10^19 years, which is approxamately 1 billion (!) times the commonly accepted age of the Universe! So, even if we had an ideal Beowulf cluster of 1 billion (!) of these multi THz machines, it would still, on average, take a length time on the same order as the age of the Universe!
Indeed the security of a cipher is in the key, and has to be, as this is the only mathematical way to guarantee security! Its all about combinatorial explosion. The number of possible keys is enormous, and grows exponentially with the size of the key. This is why even though 56 bit keys have been considered insecure for well over 15 years now that a key size only twice as large is secure to this day despite the fact that todays machines are several orders of a magnitude faster than the machines of 15 years ago.
My computers can run 24 hrs per day (instead of just 12) and hence crack the cipher in half the time <g>
nice, a cluster that crack the cipher in 500 million times the age of the universe
Good luck. By the time the crack will be reveal, you will be already a fossil unless someone will manage to transfert a spirit to a computer.
Good luck. By the time the crack will be revealed, you will be already a fossil unless someone will manage to transfert a spirit to a computer.
Note: I was fixing a typo from the reply.
Edited 2005-10-31 19:42
If you are a hacker/programmer I think you will agree with me, it’s more secure a closed source than a opensource source, if you think otherwise, you are absolutly wrong!
If you are a hacker/programmer I think you will agree with me, it’s more secure a closed source than a opensource source, if you think otherwise, you are absolutly wrong!
Wrong. And I write closed source, with as much OSS as my job allows me (but that is not too much, mostly patches and some old apps). Although customer always has option to access source from me if certain conditions are meet (something like NDA).
There is a big difference when many people see the sources and don’t see a bug, than when one (coder or company) hopes that no one will find the flaws because they can’t see the sources. Most of bugs are caused either with wrong input (unexpected from coders side) or wrong usage. Problem is that coder mostly works with his application by the book and his input is almost always what software expects.
Fedora is mostly focusing on cutting edge technologies and was not meant to be used in large enterprise,
http://www.redhat.com/software/rhelorfedora/
http://www.toptechnews.com/story.xhtml?story_id=13000CYMIQMQ
Nice accomplishment, but the Linux crowd will have to thank the American NSA for it instead of RedHat.
I only have two worries with it: a/ boxes with the LSM framework and no use of SELinux (rootkits will love this), and b/ braindead admins who rely on RedHats SELinux policies without understanding them at all (and turning them off if they interfere with some configuration change). Note that writing correct policies for SELinux is quite a challenge, as you need a fair bit of knowledge of both userland and kernel to do it right.
I’d also like to notice that FreeBSD (-current, with a lot of the TrustedBSD goodies) has more features for being evaluated as a ‘trusted os’ than RedHat which has only the SELinux MAC/TPE implementation. But they probably won’t have the big spending sponsors to get it evaluated…
Nice accomplishment, but the Linux crowd will have to thank the American NSA for it instead of RedHat.
Red Hat partnered with NSA and maintains a lot of the user space tools ane employs a good number of SELinux developers, created the targeted version of the policies and enabled them in default for Fedora and RHEL as the first mainstream operating systems to have MAC based security as a core model instead of a one off product
It is also a area where a lot of other vendors like IBM. TCS., HP etc are working together
”
I’d also like to notice that FreeBSD (-current, with a lot of the TrustedBSD goodies) has more features for being evaluated as a ‘trusted os’ than RedHat which has only the SELinux MAC/TPE implementation.”
Would be interesting to hear what they are
That is not TRUE, continue reading:
1024-bit encryption should no longer be considered pristine, creation of a machine capable of breaking 1024-bit crypto on the order of minutes or even seconds:
http://slashdot.org/it/02/03/25/2125211.shtml
And that keys as long as 2048 bits can now be broken.!
http://www.schneier.com/crypto-gram-0203.html#6
Now, did you believe me that 128 bit don’t take a universe age to desencrypt (decode) ???
Wrong, wise guy.
From that same slashdot article:
http://it.slashdot.org/comments.pl?sid=30026&cid=3225732
One other thing, that article talks about a multi-hundred-million dollar or even one-billion dollar computer to crack that key. Not your run of the mill beowulf cluster.
As for that other link, I don’t think you’ve even READ it all, just the first paragraph.
“Last fall, mathematician Dan Bernstein circulated a paper discussing improvements in integer factorization, using specialized parallel hardware. The paper didn’t get much attention until recently, when discussions sprang up on SlashDot and other Internet forums about the results. A naive read of the paper implies that factoring is now significantly easier using the machine described in the paper, and that keys as long as 2048 bits can now be broken.
This is not the case. The improvements described in Bernstein’s paper are unlikely to produce the claimed speed improvements for practically useful numbers.”
He then goes on to say why this is so.
As it is, you’re totally out of your league. Next time take more than a few minutes of searching slashdot before coming in with your snide retorts.
Red Hat’s trusted capabilities are powered by Trusted Computer Solutions.
http://www.trustedcs.com