The pre-patched kernel they are releasing is OPEN SOURCE. I don't think I should have to repeat that, and I will fight the urge to do so.

If you actually read any of my posts, you would see from my first one that you just did repeat it
As for the rest of that argument, I'm actually glad you pointed that out, because that is exactly the point I was trying to make until you turned this whole thread into a pedantic flame-war over what the definition of a distro is. I was pointing out that debugging a kernel and identifying potentially exploitable code is not something you can do by skimming over an entire kernel. There are a whole lot of people who are a whole lot smarter than either of us and are much better programmers who are writing and auditing the kernel all the time and still miss some of the bugs. If you think you can 'skim' through an entire kernel and identify all the bugs, well by all means do me and the rest of the linux community a favor sign up for the kernel mailing lists and let Linus and Alan know you got it covered. My point is that auditing a kernel is not some trivial task and things do make it through the process. Just because it has been 'audited' does not mean it's bug free (hence my pointing out the two recent kernel vulnerabilities). Look at OpenBSD, that is probably the most audited source code available, yet bugs have made it through (albeit rare). Do I seriously think that the NSA put backdoors into the code, I doubt it. Do I implicitly trust the NSA, no. There has been plenty of other distros/patches/software/whatever, that I haven't installed because I don't necessarily trust those behind it. You trust the NSA, good for you. I don't and yes that is my opinion (as I've stated), but that opinion is based on past actions of the NSA that I feel are relevent. If Double-Click offered a new linux-based browser, I would probably be suspicious of it as well.

I don't mind discussing this with you, but please leave out the "shut-up, you don't know what your talking about" fourth-grade-ish comments.

By the way, wasn't it the NSA that developed the Skipjack crypto algorithm, you know, the one with the backdoor so that the NSA could crack it if they "needed to for national security"?

The NSA patches might not do something as obvious as to "phone home" to an NSA server, but they might leave a very buried, very obfuscated backdoor in the kernel that would allow the NSA to remotely access your box, or maybe not even that, but allow them to decrypt encrypted partitions if they were doing forensics on your box, etc...

I have to echo the sentiment of those urging caution: The NSA has a track record of presenting "helpful" things to the public that actually have backdoors that let the NSA spy on us more.

Maybe this is a good time to point out that OpenBSD doesn't even receive federal funding any more and all the crypto is developed outside the United States

I'm just gonna say this, Capt., I was NOT talking to you on my last post.

Thanks....

For accuracy, Skipjack is the algorithm with _rumoured_ backdoor. The actual standard that had the backdoor was EES ( ``Escrowed Encryption Standard'' ). It had a builtin key designed to give access to government agencies. If you are interested in this have a look for ``Clipper Chip''.

As a note about the thread: I would tend to trust this component. You can quite clearly run through the sources ( as it is in LSM form, you can see it does not touch code other than to hook the LSM calls ). You do not even need to view such things the AVC and such like, purely the interactions with the hooks. Many of the people currently working with SELinux are _not_ related to the NSA, and quite a few of the people involved in it's development do not appear to be NSA ( from their accreditation, though for the paranoid among you I cannot verify they have NO connection ). Considering the amount of people who are actually likely to enable a system like this ( whether due to relative difficulties in learning the system or due to paranoia ), I doubt it is considered a prime candidate for such a backdoor as people are describing. Yes, all may have to do is a log a key here and there -- but, a) you can tell exactly what this system is doing ( try reading some of the whitepapers at the site as well, they are quite interesting ), b) the fact the entire project would be worthless if anything like this ever occurred.

People can make up their own minds, but I personally would use this...if I did not think RSBAC was better , and was not a GR Security fan ( not as thorough as the other systems in terms of full integrity, but that learning mode is really nice =) ).

BS, this is propaganda started by Liberal idiots, there is no Medical or Scientific basis to prove this since Cell phones have not been around long enough for long term studies.

Now, Repeat after me........Open Source..............means just that, if you know HOW to read "C" programming code you can inspect everyline of code to see what is there..........there is no way that anything can be hidden!! Again Repeat after me........Open Source, Open Source........geeze

Quote:

Originally posted by 320mb BS, this is propaganda started by Liberal idiots, there is no Medical or Scientific basis to prove this since Cell phones have not been around long enough for long term studies. Now, Repeat after me........Open Source..............means just that, if you know HOW to read "C" programming code you can inspect everyline of code to see what is there..........there is no way that anything can be hidden!! Again Repeat after me........Open Source, Open Source........geeze

I agree with all here. And for the record, I really feel quite safe trusting the U.S. Intel agencies. And finally, I would rather have my cell calls overheard and my e-mails intercepted then be uncertain that my next plane ride will get to the airport without unplanned detours through tall buildings. I have thought this over all day.

You don't seem to get it, do you? Sure all the source is there, but who's going to audit it, in it's entirity, and understand completely every function of it? There was an open source auditing project started some time back and funded by DARPA where you were supposed to audit pieces of the kernel... guess what? No one signed up!

Even if people do audit it, there are so many ways to obfuscate code it's not funny. There could be covert channels through timing, information leaks, etc... I've read some documentation and commentary on Linux kernel code, and half the time the reviews who were security experts writing professional works, such as books for O'Reilly had no idea what was going on. Some of the comments in the kernel even indicate people that have edited it have no idea what the heck the original code was supposed to do. There is no single person who understands the entier kernel, not Linus, not any one. It would be very simple to use off-by-one situations, etc to leak information.

As for being able to watch what the code does... HAH!. I'm reading the book Security Warrior right now and it's highly revealing into some of the faults of Linux. It's written by two expert security experts, who know a lot of old-school hackers, such as +Fravia, and the book was proof-read by Fyodor. These guys point out some serious flaws with debugging tools in Linux that makes it extremely difficult to figure out what Linux ELF binaries and glibc libraries are doing.

I highly recommend reading Security Warrior for anyone who wants to understand reservse engineering and specificly how to debug Linux programs.

Quote:

Originally posted by chort Even if people do audit it, there are so many ways to obfuscate code it's not funny. As for being able to watch what the code does... HAH!. I'm reading the book Security Warrior right now and it's highly revealing into some of the faults of Linux. It's written by two expert security experts, who know a lot of old-school hackers, such as +Fravia, and the book was proof-read by Fyodor. These guys point out some serious flaws with debugging tools in Linux that makes it extremely difficult to figure out what Linux ELF binaries and glibc libraries are doing. I highly recommend reading Security Warrior for anyone who wants to understand reservse engineering and specificly how to debug Linux programs.

Yes, OK Chort, you never stop to amaze me! The true length of the core Kernel code does make the reading a challenge! Ever been to a Barnes and Noble?

There is a difference between signing up for US government funded scheme for auditing, and the amount of people who would gain personal satisfaction from finding that the NSA were trying to cheat us all. There is also a difference in relation to the amount of people who will read over the SELinux code if they are going to use it. Linus, and therefore mainstream Linux, has a lot of trust in the community -- the NSA do not share this trust. The other problem is, that the people who are capable of doing a full audit of any complicated part of the kernel do not want to do so because: a) they are too busy with work or whatever, b) they are an evil evil blackhat, and would rather keep the problems to themselves .

Conceded, but if you actually read the code we are referring to in this case you will see that it is not obfuscated. It actually fairly clean and straight-forward. A lot of developers of systems not working for SELinux now use the code.

There are a couple of books that seem generally regarded as high-quality ( and at least two of them are O'Reilly ), though none of them cover the entire kernel in detail. I would agree, as someone who has worked privately on the kernel, that most people do not understand the full kernel -- because there is no need to ( fortunately or unfortunately? ). Although, somebody like Linus may not understand specifically what a bit of Assembly is doing ( if he does not code for that architecture, for example ), I would think that he would not pass code that he cannot verify as correct -- and since all patches to the main source tree are, supposedly, going through him...

OFF-TOPIC: in case anybody does not want to read it...

I will have to pick up a copy of that, then. The problem about debugging in Linux is well documented. We have nothing compared to SoftIce in Windows. However, projects you may be interested are listed on a page within Fenris ( a project that you may be interested ), the link is < http://lcamtuf.coredump.cx/fenris/other.txt >. Do not be put off that some of the projects listed are well-known projects.

I heard about skip jack it was humored that a back door was built in...

Yep, that's pretty much it in a nutshell (OK, it's more than that, but if you really want to boil it down...)

Hmmm, very interesting. A quick glance reveals this:
5) Name: the dude
Desc: A nice non-ptrace debugger, our savior!
URL: http://the-dude.sourceforge.net

Which looks highly interesting. Getting away from ptrace is a good thing!

Hmmm, so there are two pieces? I knew there was a key escrow piece built into it, where two different databases held a key, and when combine they could decrypt a message. Wasn't the Skipjack algorithm the encryption routine used on the Clipper Chip, right? It's just that the EES was the escrow system for the keys, yes?

I'm going to have to go back and reread that section of my CISSP prep guide.

First, I reveal my biases. I would prefer to see the NSA abolished and I don't trust them. I believe they were the most formidable and frightening enemy of computer security and privacy, at least during the 90's. I watched the Clipper fiasco with interest; I listened to the huge numbers of rumors - many of them creditable - about backroom deals and strongarm tactics to deny strong crypto to the public; I used to skim the cypherpunks mailing list every day or so, etc, etc. Long story short, I think the NSA is bad.

But SELinux is NOT a secret covert plot to break into your computer. It is one of the genuinely productive things the NSA has done. Mind you, I don't believe it's really a proper use of taxpayer money, but it's not like they're using it against us, in this case

Also you hugely exaggerate the difficulty of auditing SELinux. For example, their latest patch against the latest kernel adds roughly 2,000 lines of code (estimating here). There are many people who are capable of understanding changes of this size, particularly people who are already connected to kernel development. While there are rightly many watchful eyes on the NSA's doing, particularly in the security community, nobody has cried foul on any of these ~2000 line patches. It is pretty safe to assume that the code is just exactly what it appears to be, nothing more.

Mind you, there's other stuff that comes with SELinux, much of it harder to understand. Personally my guess is that there isn't a single backdoor in the whole thing, but if there is, some security expert would become very, very famous by exposing it...

Of course, there is a certain advantage to promoting theory that SELinux contains extremely well-hidden backdoors. Namely, the theory is very difficult to disprove. Sure, you can argue, nobody has ever FOUND the nefarious backdoors in SELinux, but that's only because they're so unimaginably hideously well-hidden.

Yes, Skipjack was the encryption routine, but ( as far as I can make out from ``Security Engineering'' ) it is not Skipjack itself that definitely has the backdoor ( thus, the backdoor in it was only rumoured to still exist ). It was not a hole in Skipjack, itself per se.

I've got Security Warrior, its my to read list.