Linked by Thom Holwerda on Sun 30th Oct 2005 15:53 UTC
Red Hat "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.
Order by: Score:
High five
by youknowmewell on Sun 30th Oct 2005 18:25 UTC
youknowmewell
Member since:
2005-07-08

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.

Reply Score: 1

For many this is irrelevant but...
by shotsman on Sun 30th Oct 2005 18:37 UTC
shotsman
Member since:
2005-07-22

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.

Reply Score: 2

Lazarus Member since:
2005-08-10

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! ;^)

Reply Score: 1

v Linux and security
by Anonymous on Sun 30th Oct 2005 18:54 UTC
RE: Linux and security
by DigitalAxis on Sun 30th Oct 2005 19:48 UTC in reply to "Linux and security"
DigitalAxis Member since:
2005-08-28

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.

Reply Score: 1

RE[2]: Linux and security
by Robert Escue on Sun 30th Oct 2005 20:52 UTC in reply to "RE: Linux and security"
Robert Escue Member since:
2005-07-08

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.

Reply Score: 1

RE[3]: Linux and security
by DigitalAxis on Sun 30th Oct 2005 22:40 UTC in reply to "RE[2]: Linux and security"
DigitalAxis Member since:
2005-08-28

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

Reply Score: 1

RE[4]: Linux and security
by Robert Escue on Mon 31st Oct 2005 00:26 UTC in reply to "RE[3]: Linux and security"
Robert Escue Member since:
2005-07-08

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.

Reply Score: 1

RE[5]: Linux and security
by DigitalAxis on Mon 31st Oct 2005 05:47 UTC in reply to "RE[4]: Linux and security"
DigitalAxis Member since:
2005-08-28

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?

Reply Score: 3

RE[6]: Linux and security
by Robert Escue on Mon 31st Oct 2005 13:02 UTC in reply to "RE[5]: Linux and security"
Robert Escue Member since:
2005-07-08

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.

Reply Score: 1

Ye right
by Anonymous on Sun 30th Oct 2005 19:01 UTC
Anonymous
Member since:
---

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.

Reply Score: 0

v care
by Anonymous on Sun 30th Oct 2005 19:03 UTC
RE: care
by Anonymous on Sun 30th Oct 2005 22:48 UTC in reply to "care"
Anonymous Member since:
---

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

Reply Score: 0

RE: care
by Bitterman on Sun 30th Oct 2005 23:20 UTC in reply to "care"
Bitterman Member since:
2005-07-06

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.

Reply Score: 1

Re: Linux and security
by Anonymous on Sun 30th Oct 2005 19:08 UTC
Anonymous
Member since:
---

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

Reply Score: 1

fedora?
by Anonymous on Sun 30th Oct 2005 19:27 UTC
Anonymous
Member since:
---

will this be in fedora first?

Reply Score: 0

RE: fedora?
by Rahul on Sun 30th Oct 2005 20:24 UTC in reply to "fedora?"
Rahul Member since:
2005-07-06

[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

Reply Score: 1

v free software GPL opensource programmers
by Anonymous on Sun 30th Oct 2005 19:32 UTC
RE: the security of a cypher... key
by Anonymous on Sun 30th Oct 2005 19:36 UTC
Anonymous
Member since:
---

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

Reply Score: 0

Anonymous Member since:
---

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.4x10^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.7x10^38 keys! So, this means that it should take 1.7x10^38/10^12 = 1.7x10^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.5x10^7s/year. Thus we have 1.7x10^26s/1.5x10^7s/year = 1.1x10^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.

Reply Score: 1

bosco_bearbank Member since:
2005-10-12

My computers can run 24 hrs per day (instead of just 12) and hence crack the cipher in half the time <g>

Reply Score: 1

Anonymous Member since:
---

nice, a cluster that crack the cipher in 500 million times the age of the universe

Reply Score: 0

Finalzone Member since:
2005-07-06

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.

Reply Score: 1

Finalzone Member since:
2005-07-06

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

Reply Score: 1

v closed/open
by Anonymous on Sun 30th Oct 2005 19:38 UTC
RE: closed/open
by somebody on Sun 30th Oct 2005 23:03 UTC in reply to "closed/open"
somebody Member since:
2005-07-07

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.

Reply Score: 1

Fedora
by Finalzone on Sun 30th Oct 2005 19:43 UTC
Finalzone
Member since:
2005-07-06

Fedora is mostly focusing on cutting edge technologies and was not meant to be used in large enterprise,
http://www.redhat.com/software/rhelorfedora/

Reply Score: 1

Good work
by Anonymous on Sun 30th Oct 2005 21:18 UTC
Anonymous
Member since:
---

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

Reply Score: 0

RE: Good work
by Rahul on Sun 30th Oct 2005 21:30 UTC in reply to "Good work"
Rahul Member since:
2005-07-06

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

Reply Score: 1

Anonymous
Member since:
---

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

Reply Score: 0

youknowmewell Member since:
2005-07-08

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.

Reply Score: 1

Powered by TCS
by Anonymous on Mon 31st Oct 2005 19:15 UTC
Anonymous
Member since:
---

Red Hat's trusted capabilities are powered by Trusted Computer Solutions.
http://www.trustedcs.com

Reply Score: 0