SE Linux, Unix, BSD, Windows, Trusted Module Platform, and the NSA.
-
This is NOT spam!
Published on September 17th 2013, the article goes on to describe the continued impact of the Snowden leaks. Asian Markets in particular have stopped purchasing American made equipment. A hard to admit and abrupt drop in sales of 40 to 50 percent.
Why?
Equipment manufacturer's as well as software developers have conspired with the NSA to build back-doors into their products. One such product is the Trusted Module Platform and SE Linux.
Here are some excerpts from the article:
Alas, Linux too is tarnished. The backdoors are there, though the code can be inspected, unlike Windows code. And then there is Security-Enhanced Linux (SELinux), which was integrated into the Linux kernel in 2003. It provides a mechanism for supporting “access control” (a backdoor) and “security policies.” Who developed SELinux? Um, the NSA – which helpfully discloses some details on its own website
The architecture has been subsequently mainstreamed into Linux and ported to several other systems, including the Solaris
operating system, the FreeBSD
operating system, and the Darwin kernel, spawning a wide range of related work.Here is the link to the article for those interested in knowing…
Here is another link to an article about how the German Security Service for Information Technology discovered the NSA Backdoors and why they banned Windows 8.
-
Sorry for resurrecting an old thread, but this topic really bothers me (I am surprised it did not get a response).
I don't trust American hardware/software anymore either. There is no way I would buy Cisco hardware, for instance. Last year I drilled several holes through our Cisco firewall and pitched it. I was so angry over all the spying allegations that I would have felt guilty even giving it away.
http://www.bradreese.com/blog/12-30-2013.htm
Yesterday I read something very troubling (and most of you probably already know this). In July 2013 Cisco bought SourceFire who is responsible for Snort.
Now I don't want to start a conspiracy thread, but if the NSA could successfully install backdoors in most of Cisco's and Juniper's firewall hardware without their knowledge (giving them the benefit of the doubt) how likely/easy would it be to compromise a pfSense package - especially given the open source nature combined with the complexity of the platform? It seems to me it would be very easy for the initiated to do just that. I have collaborated on software projects before and it would have been easy for anyone on the team to sabotage the project if they had an incentive.
I am sure someone here is tempted to send a link to the pfSense source code inviting me to look for the needle in the haystack. If it were so easy the TrueCrypt audit project would not exist.
Does the code go through any sort of check before it is released? I am very interested to know what the pfSense developers think but trolls can stay away.
http://www.blessedquietness.com/journal/theworld/Trolls-US-government-dividing-Americans-from-each-other.htm
-
Wasn't going to reply, but as soon as I moved the cursor to close the tab, I felt like replying.
IMNSHO unless you have personally designed, personally manufactured and personally assembled a pc, personally wrote an assembler for it, and personally wrote the software that runs on it, you cannot be 99.99% sure that that pc is "clean".
Now, where do we set the boundaries? You or the guy/gal sitting next to you will never perform the steps in the previous paragraph, so who do you trust?
The answer, and I'm sure I'll get a LOT of flame for this, is nobody. If you had the time to perform an audit of an UEFI system, you would have found out that the backdoors are started even before the OS loads. The only acceptable procedure for dealing with UEFI hardware? Burn it, and burn it good. A compromised UEFI system should not be allowed to be used ever again.
Let's go deeper than UEFI. CPU microcode that could disable your much beloved AES encryption. Yes, the microcode does need to be flashed on every boot, but that's what UEFI is there for.
Let's say that in the rare occasion you do get a nice clean hardware system (let's say no hardware bugs in it) then comes the choice for an OS. Closed source vs open source? obviously open source. Which, of the literally trillions of distributions of an OS do you, or better put, should trust?
Notice to flamers: Gentlemen, start your engines. This is your cue for starting to flame me.
"literally trillions of distributions" hides both the strengths and the weaknesses of open source. One of the strenghts is choice. The most serious weakness? Community fragmentation. On that I have to devote a small paragraph on what that actually means, since people get a hysteria infussed by their DNA when I mention that term.
Community fragmentation is taking a group of developers, and split them apart, maybe because your project is better, maybe because you are close friends with some of them and forked a project and they followed you, maybe because the stars had a strange alignment on a particular day and a dev community got split. Whatever the reason, communities should not be fragmented, for ANY reason. Back to the topic.
The reply is complete for the guys not yet following my way of thinking. To the others, please do read on.
The huge fragmentation in the open source community has lead to thousands of projects limping along development, with no clear sight on their future. One such example that will shock most of you? OpenSSL. Why was the recent heartbleed bug allowed to be put there? Because of the non-existent dev community (hold your flames) and lack of proper versioning control (again hold your flames a bit and let me explain).
Why was ther non-existent dev community? Maybe it was due to lack of funding. Maybe because there are tens of other projects doing their SSL by themselves (community fragmentation). One thing is clear: the change should have been vetted long before being put into the code, by an international community of volunteers. Which brings us to the lack of proper versioning control, which affect all of the open source projects.
The correct procedure to add a code snippet is to first make public the code snippet. An international team of volunteers then examines the code, documenting any of their findings and questions, and the code is resubmitted to the original author for corrections. After the corrections, the process is repeated, until there are no more corrections to be made. At that point the volunteer team votes on whether to include the finished code into the project's code base. A unanimous vote is required for its inclussion. Even if one of the members disagrees, then NO code will be included.
Dreaming aside, let's get on with the reality: Having 40 text processors and 50,000 webserver projects will never allow this to function properly. Yes I do understand the GPL's argument that people are free to fork off (no pun intended) but people should also understand the true meaning of the GPL, or any of the open licenses for that matter. It's not there so that I, as a software developer, can take a project that I don't like its menu, and fork it, taking with me a couple of my BFFs who were working on it with me. The GPL (and/or other licenses) are there in the event that I, as a software developer, working on a project, get run over by a mysterious black van with tinted windows. Or stop developing the project in any meaningful way. Or getting payed by a multibillion $ corporation to hand over my code and stop any further development. In my usual tone of posting, I will NOT accept ANY arguments to the contrary. That's the meaning of the open licenses, end of story.
We have now moved to humanity's next step in the evolution. Understanding the true meaning of open source licenses. As soon as humanity understands the importance of working on a SINGLE project sharing common goals, then our proper software versioning comes into play. The devs will start implementing the voting, and the code will begin stabilizing. Which brings us to a point I made a long long time ago on a debian mailing list.
Software should have exactly 2 (two) versions. -current and -testing. Why am I being a dictator and limit choice you ask? Because looking for bugs in a 10 year old software, a 5 year old software, a 2 year old software, the current software, and next month's software takes exactly (this is not a claim, it is a fact), 5 developers. Or a single developer, 5 times the time needed. Looking for bugs in -current and -testing takes (again not a claim, an actual fact) exactly 2 developers. Or a single developer 2 times the time needed. Now, since we are not proposing of black vans with tinted windows running around running over developers, the 5 existing developers could concentrate on the 2 versions. Which, by mathematics, brings us to the conclussion that bugs will be found,on average 2 times FASTER. Or take 2 of those developers and put them in the code inspection phase, and still finish faster.
Those not yet asleep, should be converted to my way of thinking by now. Any further resistance is just a knee jerk reaction of seeing the obvious, that we (and you, and that guy, and that gal) have helped hurt the open source community as a whole. Are you using ubuntu? Stop. Use debian. That's the proper upstream, report bugs to debian and soon debian will have the usability (excluding unity) of ubuntu, but with the rock solid performance of debian.
It may look as if the reply was offtopic, but it actually wasn't.
Without proper code inspection, without a clear upgrade path in the event that bugs are found and corrected, and without a >community< effort in making the software cleaner, then you just have to "trust the little voice inside your head". You just can't trust what other software people are writing for your own use.
Ok, so now we have established a way to import code into existing projects, and analyse those projects for bugs. What about a bug forcefully pushed into the code? That's where deterministic builds come to play. Without a clear signing and hashing of the binary being installed on your system, how do you know it was compiled from the same source as the binary is claiming? That isn't enough. Did Tom also get that hash result when he compiled the source? Did Mairy?
We took care of the code (and got into late 2046) now we have to think about motivating the developers into cleaning it up. Do you use a project? Donate to it. Ask them to fix bugs for you. Loved their response on a bug? Donate again. You don't have to donate thousands, just $1. Imagine if 1000 people did that per month. Would the developers have any motive into examining the code? Would they if 10,000 people did that per month?
What about companies using open source code for their work? Recommend them. Become familiar with them, as persons to persons (no horizontal action needed, optional if wanted ;D). Help them help the upstream communities. If they can't make a living, how do you expect them to donate equipment/money/man hours into the open projects.Ok I'm done. Flame away!
-
I don't spend too much time in these forums as I am far too new to pfSense, but I would hope that people in these forums are too civil to start a flame war.
You do make several good points, although I don't think the time/developer ratio is quite so linear. Sometimes a second person looking over the code will immediately catch something that the original programmer may not catch (ever not bother checking a portion of your code because you KNOW that method/procedure/whatever is rock-solid, only to later discover a bug in that section? Embarrassing…) At the same time 5 programmers cannot program 5 times faster than 1 programmer - maybe 3 times faster (there was a book written on this very subject a few years ago, sorry but I can't remember the title.) Anybody who has collaborated in a group can probably understand why.
But I get your point, there are not enough resources going into these open source projects.
When the heartbleed bug was uncovered I did not place blame on the programmer but rather on an essentially broken infrastructure (no, I can't offer a better solution). When details of how the openSSL organization is "funded" were described in the media it confirmed what I already know. A majority of open source software is written by people as a side hobby, not as a job.
When I cannot find documentation for a i.e. pfSense package I don't wonder why, I know that writing documentation is the most boring, unrewarding part of programming - and it is always the last thing ever done. Been there, avoided that. Nobody wants write documentation as a hobby, programming itself is more rewarding.
If I were one of the pfSense founders and it was uncovered that a pfSense developer intentionally inserted a backdoor into their code I would be livid. Such a revelation could have a similar impact on pfSense as it has had on some US corporations, and I hope it never happens. Is there a formal "code of conduct" that pfSense developers abide by?
and yes, I get it, everyone needs to draw the line somewhere. I was just hoping that someone on the pfSense inside could shed a little light on how pfSense software is vetted. I don't want to bring computer BIOS nor any silicon into this discussion simply b/c nobody here has any control over it and it just muddies up the discussion. I would rather stick to what can be (somewhat) controlled by pfSense.
Bruce Schneier did a good job summarizing how the NSA spy scandal affects people.
http://www.cnn.com/2013/07/31/opinion/schneier-nsa-trust/index.html
I said it in another post and I still stand by it, the NSA is a terrorist organization that has done severe damage to both American companies and our global reputation.
-
I agree with you on many of your points.
I also remember reading about the number of programmers vs the job they do in the Cathedral and the Bazaar, I'm sure it's a named law but it completely escapes me.
I brought my examples into the discussion to show that yes, the way we code right now is broken beyond any reasonable hope for repair. The whole system needs to be torn down, and redesigned from the ground up, with code inspection being an essential part of it.
Your point about open source projects being developed more like a hobby rather than as a job is valid though. I believe that in order to change this, companies need to realise that when they need a job done, they should search for an open source project that does the job for them, and instead of getting sucked into paying millions for a one off custom made solution, they instead funnel some of that money or even all of it into the project that does the job they need. That way the communities are supported, their developers get money to buy food (since they can't code much if they are dead) and the companies have a solution that works for them, and they avoid the vendor lock in.
How many companies have spent millions so far on solutions that stop working when the next OS version comes out? Either that or they get stuck on outdated and unpatched systems, which lead to their compromise. How many of those companies would be in the same position if they used open source software as a foundation of their systems?
Let's take ACME bank for example. ACME bank needs to make sure that their systems are secure, since they are after all a bank. They hire a programmer to write their custom bank software, and when he is finished, they hire someone to audit it. 5 years down the line, when the original software author gets run over by a black van with tinted windows, the bank is left at the mercy of the people doing the audit.
Rewind back the clock now. ACME bank searches for an open source software that does the job they need. Let's assume for now that they do find such a project. They get in touch with the developers to add a couple of things they need, the developers make the changes, and the software is rushed into production. The bank then audits the software through third parties and finds a bug. The developers fix that bug in a timely manner.5 years down the line ABC bank comes into play. They search for an open source project, and they find the one that ACME bank uses. They also get interested and start using the software. 5 years down the line they in turn discover a bug that ACME's auditors missed all those years. End result? Both banks benefit, since the bugs are fixed in the common code by its developers. Instead of investing millions, they invested a couple thousand into their software (excluding audits, since that's mandatory) which in turn fed the developers and supported the software's community.
I hope I'm making myself clear. As you said, we can't be sure that the hardware we use is clean. We can focus though on the software side, and try our best for it to be clean. Maybe 20 years down the line there will be options for us to design, manufacture and assemble our own custom made hardware, but for now, we just have to trust the companies doing it are not in bed with the NSA.
-
The core group that develops pfsense software is very small and known to Chris and i. Two of the main devs are outside the US and its jurisdiction.
Youll also need to worry about freebsd and the freebsd ports collection, of course.
While we take community contributions, these are reviewed.
I've also been a complete hardass about third parties calling their builds "pfsense".
Want to guess "why."? -
@gonzopancho:
The core group that develops pfsense software is very small and known to Chris and i. Two of the main devs are outside the US and its jurisdiction.
Youll also need to worry about freebsd and the freebsd ports collection, of course.
While we take community contributions, these are reviewed.
I've also been a complete hardass about third parties calling their builds "pfsense".
Want to guess "why."?OK, thanks Gonzopancho, hopefully you can understand my paranoia. Living in a surveillance state does that to people.
-
btw, when you said this: "I also remember reading about the number of programmers vs the job they do in the Cathedral and the Bazaar, I'm sure it's a named law but it completely escapes me."
"Linus' Law" (ref: http://en.wikipedia.org/wiki/Linus's_Law)
Note that it hasn't panned out so well in practice. Eric Raymond turns out to be wrong on a lot of fronts.
-
@jflsakfja:
How many companies have spent millions so far on solutions that stop working when the next OS version comes out? Either that or they get stuck on outdated and unpatched systems, which lead to their compromise. How many of those companies would be in the same position if they used open source software as a foundation of their systems?
Let's take ACME bank for example. ACME bank needs to make sure that their systems are secure, since they are after all a bank. They hire a programmer to write their custom bank software, and when he is finished, they hire someone to audit it. 5 years down the line, when the original software author gets run over by a black van with tinted windows, the bank is left at the mercy of the people doing the audit.
Rewind back the clock now. ACME bank searches for an open source software that does the job they need. Let's assume for now that they do find such a project. They get in touch with the developers to add a couple of things they need, the developers make the changes, and the software is rushed into production. The bank then audits the software through third parties and finds a bug. The developers fix that bug in a timely manner.5 years down the line ABC bank comes into play. They search for an open source project, and they find the one that ACME bank uses. They also get interested and start using the software. 5 years down the line they in turn discover a bug that ACME's auditors missed all those years. End result? Both banks benefit, since the bugs are fixed in the common code by its developers. Instead of investing millions, they invested a couple thousand into their software (excluding audits, since that's mandatory) which in turn fed the developers and supported the software's community.
Good example, thanks for it. Unfortunately this can only happen in a dream world. Here's the reason why:
Bank ACME and bank ABC are competitors on their market. It's against their interest to show the ways/workflows they use to make business. That's why they rather pay trillions more money to keep the source closed and their own property. They will never agree to share internal workflows and business secrets with each other… and computer software is more and more the base for business workflows everywhere. They will also never agree to share these things to public because then newer and newer competitors could come and decrease profits.
It's all about money and time, unfortunately. How fast can Cisco firewall be deployed within a big company? How many people can stand behind it? Are there any guarantees? Oh sure, many contracts can be signed and promises and lies, nobody cares really. Can't be the same with pfSense... this is the reality nowdays, and I can't really see how can it be changes.
Businessmen and politicians don't care about the community and honesty and trust. This whole NSA is nothing more than another method to try to get more money by gaining newer and newer business positions over the world. America doesn't want to allow to be overridden by China...
Every time I realise this I get more and more angry and start fearing about what a rude world we're living in. And I have two children I have to rise, what should I teach them...?
