View Full Version : Selinux = NSA-Backdoor?

guest1234567 Someone pointed out that Selinux might be a NSA-Backdoor:



http://etbe.blogspot.com/2006/12/se-linux-on-debian-in-5-minutes.html

http://www.schneier.com/blog/archives/2007/01/nsa_helps_micro_1.html

http://blogs.techrepublic.com.com/opensource/wp-mobile.php?p=37



On the one hand, it does protect our systems before worms and “normal” user cracking. But on the other hand it might grant NSA a backdoor in case they would want to use it.

I know, Selinux is open source, so it seems clear that someone would someday stumble over it, when reviewing the code. But how can we be sure, that somebody ever would audit the code thoroughly? Perhaps it is well hidden in the code, maybe in some harmless looking lines, or scattered across the whole code in tiny bits, which are waiting to receive a secret signal and then get activated? Who could possibly find it, given the fact that Selinux is such a complex program. That even to handle it is too difficult for most users. And the sheer size of the program and it's depending parts. May well be over hundred's of thousands lines of code.

Facing all this, i cannot be absolutely sure, that this code is really clean.



What is your opinion? Just paranoid, or perhaps a good point?

rjstaaf I can understand your concerns and they are probably warranted considering how much the US Constitution has been trampled on these days. I am sure you aren't the first one to have these concerns either. I seriously doubt though that even the NSA would be able to hide the necessary code in software where the source code is freely available and looked at on a regular basis.

Dan Paranoid, I'd say. But that doesn't mean you're either right or wrong.



However, If this causes you concern, you have many options. One of which is to either not use/enable/install a distro that has SELinux in it, or instead use/purchase what you feel may be a safer alternative.



It also occurs to me, that if the NSA really wants to know what's in my computer, all they have to do is either get a warrant and come fetch it, or even easier, just knock on the door and politely ask if they can look. Might be nice if they called first, though. Just so I can have a fresh pot of coffee ready.





Dan

Iron_Mike YES, we did put in a BACKDOOR, after all we were instrumental in designing system. How else could we monitor people such as yourself. We see all and know all, we know what porn, drm protected music, even what beer you drink. Remember we are watching.........





Director

National Security Agency

ATTN: Information Assurance Policy, Procedures, and Insecurities Division (141)

Fort George G. Meade, MD 20755-6722

RHamel Yeah, a back door in open source, that no one noticed. lol

ElJoeb YES, we did put in a BACKDOOR, after all we were instrumental in designing system. How else could we monitor people such as yourself. We see all and know all, we know what porn, drm protected music, even what beer you drink. Remember we are watching.........



Not the back door I was thinking of <shiver>. If this is a valid concern, its a valid concern for all open source software, because it would apparently be easy to hide this from people.

Dan YES, we did put in a BACKDOOR, after all we were instrumental in designing system. How else could we monitor people such as yourself. We see all and know all, we know what porn, drm protected music, even what beer you drink. Remember we are watching.........





Director

National Security Agency

ATTN: Information Assurance Policy, Procedures, and Insecurities Division (141)

Fort George G. Meade, MD 20755-6722 Yeah ... about that. Hate to ask, Mike. But could you possibly please re-task a satellite over my neighbor's backyard? I can't find my weed-eater!





Dan

bradchaus in order for an se-linux exploit to work its first got to get through your firewall and tcp-wrappers defences. IMHO, if those are set up properly, it would be a hard task to get to the se-linux layer.



my 2 cents

Iron_Mike Yeah ... about that. Hate to ask, Mike. But could you possibly please re-task a satellite over my neighbor's backyard? I can't find my weed-eater!





Dan



Right where you left it Dan. Behind the shed...... ;)

Dan Aw, crud! Sure enough. Uh ... Thanks.

Nick Levinson The parts of the SELinux enhancements that are in the kernel or in other components that are frequently maintained by people other than NSA loyals are likelier to be seen as the kernel or those other components are rewritten from time to time, and NSA would have anticipated that. That means the main problem is with the other parts (files that are exclusively for SELinux or that are in components that are rarely maintained by other people). Perhaps that reduces the amount of code that should be re-examined.



One could examine code to be sure that every line of code (and every command, argument, etc.) has a legitimate purpose. That reduces the problem to one of finding dual-purpose code.



If you find code that appears questionable, either dual-purpose code or code lacking any apparent purpose, one option is simply to go public with the specific lines and challenge them in a forum. That's not very different from going public with other exploits that are likely already known to secrecy-shrouded hackers anyway, such as viruses that attack Windows. There's no big dispute about whether Linux vulnerabilities should be revealed, too, and that includes SELinux.



The NSA is highly reputed for its IT capabilities. Auditing the work of secret agencies has been an open issue because of the prospect of appearing to approve when one hasn't and thus of not serving the public nonsecret interest. But this is different because an outsider's audit of open source software can be done publicly, by many people working independently of each other, repeatedly regardless of prior results, without new permission, and without any cooperation with any secret agency, including the NSA. You don't have to tell anyone. And you can hang a banner announcing your intention right outside NSA headquarters (if they won't let you and they saw what your banner said, they're on notice). And then someone else can do the same thing, so if someone in black bribes you not to reveal your findings someone else can reveal what they find.



Besides, there's another reason -- or another objective -- that can be satisfied at the same time. Some of us who have faith in SELinux and prefer to use it also have problems. I had a problem installing Linux with particular settings in SELinux; I don't remember what the problem was that I experienced, but I wound up using a default setting without the particular adjustments that it offered. And I came across a topic in FedoraForum.org about difficulty using a website in a browser because SELinux objected to text relocation that usually isn't needed and presents a security issue (that's not my evaluation). In short, if SELinux seems to cause more problems than it's worth to administrators, the NSA won't achieve its published objective of aiding other Federal agencies with their information security requirements and of showing a model to mainline OS designers (I assume they don't mean Linux but perhaps they mean Microsoft) that this kind of security is feasible (leaving to mainliners how they'd implement it, and maybe they already have).



You can examine source code for illegitimacy, undersecurity, and for impediments to productivity, creativity, etc. (you could call that oversecurity) (I imagine gamers will encounter problems with SELinux, since games often push the limits of hardware and software, and advanced programmers having nothing to do with SELinux also want high performance from their programming setups, which oversecurity impedes.) Even if you find only one problem, that's a benefit to the rest of us.



Even if the most obscure parts of the SELinux source code were thoroughly examined during development and at first distribution as stable and passed strict scrutiny, times have changed, technology has developed, computers have gotten somewhat more capable and will only get more capable, and there likely are more people with relevant skills on both sides of the good/evil fence and in the gray zone. That's good reason to reexamine sooner or later.



Perhaps you should give it a shot.



--

Nick

Crito Say, hypothetically of course, someone were to put a malicious selinux policy update in the main fedora repository. How long before that replicated to all the mirrors and was downloaded to tens of thousands of machines? Sounds like a single point of failure to me.



SELinux solves problems I don't have and creates a bunch of new ones that didn't exist before. In fact, I'd say those who advocate its use are more paranoid than the NSA conspiracy theorists. I really have no need for it.

lazlow Crito



Your single point failure would apply to any part of the system. I would be more concerned about an iptables update being tampered with. In either case, I think it is highly unlikely that it would get through the "checks and balances" built into the system.



Lazlow

Crito Yet, bad updates get through these checks and balances on a routine basis already. Therefore, one should strive to create fewer, not more, single points of failure.



Fact remains SELinux doesn't solve any problems I've had or am likely to ever have on a desktop computer. All it does is create more problems for me.

lazlow There is a huge difference between buggy and malicious.

Evil_Bert The parts of the SELinux enhancements that are in the kernel or in other components that are frequently maintained by people other than NSA loyals are likelier to be seen as the kernel or those other components are rewritten from time to time, and NSA would have anticipated that. That means the main problem is with the other parts (files that are exclusively for SELinux or that are in components that are rarely maintained by other people).

But the NSA would have anticipated that you would have anticipated that, so they'd put their suspicious code right under your nose in the kernel and public-supported modules ...... But wait! They actually would have anticipated that you would have anticipated that they would anticipate that you would anticipate that they would anticipate .... #(&^%@*&^$.....



I think my brain just melted.

:D

Crito On a personal computer you should expect (and allow) applications to be used in ways their developers never imagined. I'd even go so far as to say that's the essence/spirit of OSS as a whole.



In my mind SELinux is only appropriate for a bastion server that needs to be locked down.

Dies But the NSA would have anticipated that you would have anticipated that, so they'd put their suspicious code right under your nose in the kernel and public-supported modules ...... But wait! They actually would have anticipated that you would have anticipated that they would anticipate that you would anticipate that they would anticipate .... #(&^%@*&^$.....



I think my brain just melted.

:D



LMAO.



Thanks!

Nick Levinson The main question is for people who want or need a higher degree of security but want it honestly done. If you buy a front door lock from a hardware store, you probably don't want the store owner keeping a copy of the key (which is why you might go to an out-of-neighborhood store and not say where you live). If you hire someone to install security and they toughen your front door but secretly remove your window lock and then tell a local break-and-enter crew your address, getting rid of security is not the answer.



If you don't need SELinux, fine. If too many of us who do need or want better security find SELinux too problematic, the NSA will likely want to tweak, revise, or overthrow and replace the enhancements, up to a point. And, frankly, if they lose interest or do it badly, the SELinux additions are under GPL or LGPL, so you can tweak, revise, and replace them without much limit without new NSA permission. So examining code is not a mere favor to the NSA, but an opening for you to offer a still better security system. Which is why I think the NSA will feel prodded to continue offering upgrades in response to problems you uncover. While general principles underlying its design may be almost timeless, specific steps are technology-dependent, and weaknesses are almost guaranteed to occur. Auditing and test-attacks are thus highly appropriate.



If someone were to put a malicious SELinux update into a main repository, propagation to mirrors would be pretty thorough and a lot of damage would ensue. But someone's likely looking at what gets into major repositories before propagation. Some bright cockroach can open a repository and put Venus flytraps in there, but if you've never heard of that cockroach you might not feel very trusting toward the critter. So only generally trusted, viz., well-known, repositories are at issue for most software. Presumably, submissions to them are vetted. And probably they are, because lots of virus and malware writers would love to insert a version of Linux that would email your credit card numbers and yet that's not happening much or at all, so someone must be vetting.



Firewalling is crucial but not enough. I assume SELinux is security against some internal manipulations that have external effects. iptables and hosts.deny are critical but problems in software elsewhere can cause problems even with perfect firewalling, as Win users notice. Maybe I can get away with less security than many other users and I'm just being paranoiac, but going public with a laptop over wireless from time to time makes me wary, and fixing my computers is an annoying drag that slows my real work. So I'd rather have security, SELinux seems suitable and has a great price, and the fact that its source code can be vetted by anyone willing to take it on, when Win's can't be except by governments (and maybe others with lots of money or a friendly Gates-keeper in a high place), I think justifies much more confidence in its quality. But only, of course, if some folks do the vetting. I'm not qualified to do it.



Care to try?



--

Nick

Iron_Mike The main question is for people who want or need a higher degree of security but want it honestly done. If you buy a front door lock from a hardware store, you probably don't want the store owner keeping a copy of the key (which is why you might go to an out-of-neighborhood store and not say where you live). If you hire someone to install security and they toughen your front door but secretly remove your window lock and then tell a local break-and-enter crew your address, getting rid of security is not the answer.



If you don't need SELinux, fine. If too many of us who do need or want better security find SELinux too problematic, the NSA will likely want to tweak, revise, or overthrow and replace the enhancements, up to a point. And, frankly, if they lose interest or do it badly, the SELinux additions are under GPL or LGPL, so you can tweak, revise, and replace them without much limit without new NSA permission. So examining code is not a mere favor to the NSA, but an opening for you to offer a still better security system. Which is why I think the NSA will feel prodded to continue offering upgrades in response to problems you uncover. While general principles underlying its design may be almost timeless, specific steps are technology-dependent, and weaknesses are almost guaranteed to occur. Auditing and test-attacks are thus highly appropriate.



If someone were to put a malicious SELinux update into a main repository, propagation to mirrors would be pretty thorough and a lot of damage would ensue. But someone's likely looking at what gets into major repositories before propagation. Some bright cockroach can open a repository and put Venus flytraps in there, but if you've never heard of that cockroach you might not feel very trusting toward the critter. So only generally trusted, viz., well-known, repositories are at issue for most software. Presumably, submissions to them are vetted. And probably they are, because lots of virus and malware writers would love to insert a version of Linux that would email your credit card numbers and yet that's not happening much or at all, so someone must be vetting.



Firewalling is crucial but not enough. I assume SELinux is security against some internal manipulations that have external effects. iptables and hosts.deny are critical but problems in software elsewhere can cause problems even with perfect firewalling, as Win users notice. Maybe I can get away with less security than many other users and I'm just being paranoiac, but going public with a laptop over wireless from time to time makes me wary, and fixing my computers is an annoying drag that slows my real work. So I'd rather have security, SELinux seems suitable and has a great price, and the fact that its source code can be vetted by anyone willing to take it on, when Win's can't be except by governments (and maybe others with lots of money or a friendly Gates-keeper in a high place), I think justifies much more confidence in its quality. But only, of course, if some folks do the vetting. I'm not qualified to do it.



Care to try?



--

Nick



On a semi serious note, do you really support what you just have written on a public forum??

Nick Levinson Yes. I don't know your local experience, Iron_Mike, but there's a history of hackers finding weaknesses, privately telling software makers about holes in their products, seeing no changes being made, and going public, after which the makers fix the holes (the makers having some justification for both of their steps). Roughly the same principle applies here. Public discussion helps. The NSA wouldn't want the same discussion being held only by enemy crackers telling only themselves before the NSA realized it, and the same is largely true of many admins and users of SELinux systems. I'm an admin and user of my one computer that has SELinux running, and I'd like to know about problems. No one's perfect.



If you have particular critiques of what I wrote, I'm happy if you post them. Thanks for bringing it up.



--

Nick

ShivaS It might be a stupid question but why the need for SELinux when there's iptables?

pete_1967 It might be a stupid question but why the need for SELinux when there's iptables?



SELinux is NOT a firewall.



http://docs.fedoraproject.org/selinux-faq/

http://www.nsa.gov/selinux/info/faq.cfm

drunkahol From a document I'm currently writing for a client:



<snip>

SELinux is a mechanism of Mandatory Access Control or MAC and provides significant enhancements over Discretionary Access Control systems or DAC. The Linux file system uses file permissions which is a form of DAC. Malicious or broken code can still have administrator access to the whole filesystem.



The SELinux mechanism allow policies to define permissions for how all processes (known as subjects in SELinux) interact with other parts of the system; files, devices, sockets, ports and other processes (known as objects). With this model, a process can be granted only the permissions it needs to be functional. Even if the httpd process is compromised by malicious code, it only has access to the processes and files to which httpd is allowed by SELinux.

</snip>



SELinux is not a firewall in any way shape or form. The security it provides is for processes that are ALREADY running on your system. IPTables works to prevent access to your system. But if someone get's your ssh key (for example), you could be in trouble. SELinux steps in by only allowing the ssh daemon access to certain areas.



It's a complex subject, so I'm unlikely to have cleared anything up. Hope it helps nonetheless.



Cheers



Duncan

ShivaS I've always thought that SELinux is an improved firewall ...guess I didn't read enough documentation.



So, it's better to enabled it than to be sorry ...

drunkahol I've always thought that SELinux is an improved firewall ...guess I didn't read enough documentation.



So, it's better to enabled it than to be sorry ...



I personnaly run with it enabled. It's come a LONG way in the last few releases. There are tools that let you know when it refused access to something. This will help you figure out how to change your policies to get everything working. I've only found one app that I need that won't work at the moment - NXmachine - because it puts an ssh key in an unexpected place. SELinux prevents the ssh daemon reading keys from that directory.



If it get's in your way too much - reduce it to Permissive mode. But then try and figure out what was causing the problem. Then try and fix the problem and get back to Enabled mode.



Cheers



Duncan

Dirty_DVD I did about 1/2 dozen installs of Fedora 8 Linux distro recently, on IBM Thinkcenter PCs. Fedora 8 includes SELinux by default. Each install was done on a desk near slightly oldish Telrad phones, that have intercom speakers. I had an Ethernet cable plugging in to the PCs for Internet access, but the phones are in no way connected to the network. And I **** you not, each time, the phone "chirped" precisely when I entered the root password during the install procedure.





Telrad Tenecs offers Linux messaging solution via TeleData Technology



New York, New York - TeleData Technology and Telrad Tenecs (a Telrad Networks company) today announced the execution of an original equipment agreement. Under terms of the agreement, Telrad Tenecs will bundle the TeleData Technology Linux messaging solutions in all shipments to its international dealer network for PBX equipment orders that specify messaging features for the release of emaGEN, a sophisticated and technology-rich voice mail system for small to large business enterprises. Initial shipments under the agreement will begin in, April 2002.



The two companies also have indicated that they will begin to work on an embedded solution that can be expected to ship later in 2002. The agreement will provide Telrad Tenecs with powerful voice processing features, including voice mail, speech recognition, unified messaging/unified communications, automated attendant and built-in IVR. TeleData Technology was the first company to commercially ship a Linux based solution in August 2001 and Telrad Tenecs will be the first to package the Linux product.



The tight integration by Telrad Tenecs of the TeleData Technology Linux-based messaging software will bring several substantial benefits to interconnects/resellers and their customers, including:





http://tinfoilhat.shmoo.com/logo.jpg

Evil_Bert .... near slightly oldish Telrad phones, that have intercom speakers. ... each time, the phone "chirped" precisely when I entered the root password ...

Yeah, I've heard those things can read your mind if you sit too close. I try to think in a foreign language, just in case. :p

Dirty_DVD Emissions from Bank Computer Systems Make Eavesdropping Easy, Expert Says



By DAVID O. TYSON



NEW YORK - A Dutch electronics expert told a banking security conference in Cannes, France, this month that bank computer systems, especially home banking systems, are easily breached because of their radiation emissions.



W. Van Eck, who has studied radiation leaks from video display terminals for four years, said that by using simple equipment costing less than $10, an ordinary television set, and a directional antenna inside a car parked outside a bank, it is possible to read the information displayed on almost any computer screen inside the building from as far away as 1,000 yards.



A U.S. government technical expert in Washington, who asked not to be identified confirmed that emissions can be picked up from some distance. "I certainly would challenge the $10 figure and the simple television set," the source said. "I think he's overstating his case. But from the standpoint of 'Could it be done?' - Yes, it could be done."



About 150 delegates from banks and computer security organizations attended the conference, called Securicom 85. In a technical paper, Mr. Van Eck spelled out measures banks may take to guard against emission leaks, such as metal screening or wallpaper and use of encryption. But if banks and other offices were to apply the most stringent security standards, Mr. Van Eck said, they would have to use equipment tested to government and military specifications. He told the conference that two such standards exist. In the U.S., it is the Nacsims 100A [sic, NACSIM 5100A] "Tempest" and its NATO equivalent AMSG720B.



Mr. Van Eck said that precisely what these standards require is classified information, and any discussion or publication of information relating to Tempest in the U.S. is forbidden by the National Security Agency.



http://cryptome.org/nsa-vaneck.htm





-----------------------------





Another method of of BIOS rootkitting is through ACPI, which is the hardware that controls power management of your system as well as provides temperature information to your operating system. ACPI has the ability to modify system memory and allow the attacker to deploy a rootkit. ACPI rootkits are independent of the operating system so will work on multiple platforms.



Black Hat 2007 : Day 2 : John Heasman (http://eecue.com/log_archive/eecue-log-724-Black_Hat_2007___Day_2___John_Heasman.html)

Evil_Bert The standards have moved forward a bit since 1985 ..... apparently ...... not that I'd know anything ... ;)



http://en.wikipedia.org/wiki/TEMPEST

drunkahol You could always use the latest case from Lian-Li



Case made entirely from 1/2 inch thick lead. Inside that there is a Faraday cage to boot!



Cheers



Duncan

Dirty_DVD BIOS writers are supposed to provide AML code (with the motherboard BIOS or the device itself) which helps each device implement parts of the ACPI specification. Systems implementing ACPI are required to run this code in a privileged mode when required. In other words, to implement ACPI, the Linux kernel must:



* Run arbitrary, binary-only code from outsiders...

* ...which implements a huge, complex specification...

* ...in kernel mode...

* ...with a bulky interpreter (built into the kernel)...

* ...hoping that there are no bugs or misfeatures in this code...

* ...even though BIOS code has been the source of endless headaches for years.



Once you look at it that way, it's not too surprising that people are wondering about the whole thing. As Alan Cox put it:



The fact that it takes more code to parse and interpret ACPI than it does to route traffic on the internet backbones should be a hint something is badly wrong either in ACPI the spec, ACPI the implementation or both



http://lwn.net/2001/0704/kernel.php3





Hey, its all way over my head.



However, I can duplicate the sequence of events related to my observation. Perhaps its nothing but an electromagnetic surge at that point of the install procedure, and its just a coincidence that it happens when entering the root password? Is it at that point that the OS takes full control of the hardware?

Dan Hmmmm.



Anybody else notice that "guest1234567" dropped this little gem into our forum ... and ran.



Hasn't been back since. <..:p..>





Dan

Evil_Bert ...Perhaps its nothing but an electromagnetic surge at that point of the install procedure...

Would seem more likely, but I obviously couldn't say for sure. CD-ROM drive winding up, maybe?



Why would they let it 'chirp', and draw attention to itself, if it was a feature?

Evil_Bert Anybody else notice that "guest1234567" dropped this little gem into our forum ... and ran.

Yes.



H*ll, I don't care if the powers that be know who I am - I've p*ssed off enough of them already. :p

drunkahol No - I think I'm confused. The new cases are made of a special thing called Blue LED. This must be the "premier" form of lead I presume. This high grade LED get's everywhere. Even some fans are made from LEDs.



Just to be safe, I'm going to make the computer room a little Faraday cage of it's own. I'll hide it behind the plasterboard of course, but I should be able to cancel out any signal from the room :-)



Then I'm going to unplug the ADSL modem just to be cer

Dan <-------- Lol!

Dirty_DVD No - I think I'm confused. The new cases are made of a special thing called Blue LED. This must be the "premier" form of lead I presume. This high grade LED get's everywhere. Even some fans are made from LEDs.



Just to be safe, I'm going to make the computer room a little Faraday cage of it's own. I'll hide it behind the plasterboard of course, but I should be able to cancel out any signal from the room :-)



Then I'm going to unplug the ADSL modem just to be cer







http://youtube.com/watch?v=7Qznsf0i1wQ :D

Dan For those who are not already paranoid beyond the scope of reason, this should help get you there.





Never piss off a federal law enforcement agency. They have a lot more money, toys and time than you do to get "even." Author unknown. Current whereabouts, unknown. <..:p..>

tornadof3 This might sound like a dumb question, but....



If the NSA played a big role in SELinux's development, does this imply the NSA/US government use linux as their main operating system?? (If so, surely this is a very positive endorsement) - always assumed US systems were windows/mac based. Too much watching 24....

Nick Levinson Roughly and briefly, the NSA's reason for developing SELinux, per their statement on their website, was that the NSA wanted not only to provide something for Federal agencies who wanted better security (probably not as good as their own in-house stuff but most Federal agences don't need that level of quality) but also wanted to encourage mainline developers (by which I assume they mean mainly Microsoft) to provide better security by proving the possibility (I assume Microsoft knew that already) and proving that customers would accept it (the problem there is that Microsoft probably knew that, too, but it conflicted with other customers' demands for productivity, moving the challenge to NSA or anyone else to find a workable balance that MS would be willing to implement and the buyers would be willing to buy and use).



--

Nick

lazlow Another reason is that with a lot of servers on the net running non-Micro$oft servers they needed a team that was fluent on the leading edge of this new software. The easiest way to do that was to have the team contribute.

Evil_Bert I think the NSA releasing SELinux source code was the smartest thing they've done.



They knew they had something good with SELinux (based on previous work as it was), but to develop it at the speed necessary to make it widely deployable meant harnessing the power of the OSS community.

RJFUatHOME Well, I haven't read thru this entire thread, but I personally appreciate the kernel level security that the NSA contributed to fedora. Any contribution to kernel level security is OK in my book. I'll simply say thank you.

Deltanoob Mike, can you please order a special forces strike against the Microsoft HQ? Thanks.

lol



But anyway, i don't think our good friend linus would allow that.

L0k1ky3 So don't you think a security program would be to likely of a place for the NSA to hide a backdoor? If the NSA where to try and put something in GNU/Linux we would find it pretty fast. There is way to many eyes on the code for some one to miss it.

bob A fresh post on a nearly 8 year old thread? Please let the dead rest! Thread Closed.

Powered by vBulletin® Version 4.2.5 Copyright © 2020 vBulletin Solutions Inc. All rights reserved.