Posted on 07/26/2013 9:28:42 AM PDT by ShadowAce
In the wake of the recent revelations that America's National Security Agency is spying on all and sundry, is it time for the Linux community to take another good, hard look at the NSA-developed Security Enhanced Linux?
The NSA's Security Enhanced Linux comprises a kernel patch to add security features, and patches to applications to allow them to determine the security domain in which to run processes.
The code was initially developed by the NSA and is under the GPLv2, the same licence as the kernel. Numerous individuals and companies have made contributions to the project.
Recently, Cyanogenmod, one of the more popular forks of the Android mobile operating systems, announced it would be incorporating SE Linux as part of its security features.
Asked whether a code audit was needed now, Russell Coker, a Melbourne-based developer for the Debian GNU/Linux project, who is listed as a contributor to SE Linux, told iTWire: "The SE Linux source is free for anyone to review. It's probably better reviewed than most kernel code because someone who finds a bug would get more fame for doing so than for finding bugs in most kernel code."
Russell, who has ported and packaged SE Linux for Debian, added: "It doesn't seem plausible that there would be anything inappropriate in patches publicly submitted by the NSA.
"Given that anyone anywhere in the world can submit a patch I don't think that we need to worry about patches coming from .gov email addresses."
Brian May, another Debian developer who is based in Melbourne, is credited with backporting Russell's work to Woody, a Debian release made in July 2002.
May, an open-source consultant, told iTWire he was no longer the maintainer for SE Linux for the stable stream of Debian.
"Unfortunately that is not the case," he said when the question of him being the maintainer arose. "I looked into SE Linux some years ago, but ran out of time to really get into it. I am a Debian developer, however."
However, May was confident about the integrity of the code.
"SE Linux is entirely open source software, that has been reviewed by many people," he said. "It has been merged into the mainline Linux kernel since version 2.6.0-test3, released on 8 August 2003.
"Linux has a reputation of being very conservative for allowing new features, this means everything would have been reviewed even more times by more people while pushing to have it accepted in the kernel release. If there were any concerns it would have been rejected.
"I am sure there would be a number of people very keen on finding backdoors in SE Linux for the sole purpose of discrediting NSA. Yet so far, I haven't seen any reports of anyone finding anything. I can only conclude that this is because there are no hidden backdoors."
He added: "PRISM, if the allegations are true, was designed around complete secrecy. SE Linux on the other hand has been a very open and transparent project for many years."
SEL does what it does well, but with the concern about backdoors, I wouldn’t want to use it.
The public dev community for Linux should be able to spot inadequacies and holes in their kernels, but if it’s done by the NSA under the guise of GPLv2, and nothing can be changed, we really have no idea what’s going on under the hood which is counter to the idea of the GNU to begin with.
If the source is available, you can inspect it before compiling it. Besides. . . . . No Such Agency is subtle. They’ll hide the backdoors in something EVERYONE uses, and never bothers to compile from source. Like Firefox, the BIND daemon, or SSH. . .
Yeah, but with BIND or SSH, you can always change the default port. Matter of fact, I usually do since they’re common.
These two clauses are mutually excluded. They cannot both be true.
No no no... if the NSA creates specific algorithms used in components and modules in Linux, and the source algorithm/hash isn’t revealed, it’s contrary to GPLv2. That’s what I meant.
That’s kinda my point. If it’s under the GPLv2, then the source/algorithm must be available.
Even under SEL?
I’ve not used any SE-enabled Linux kernels, so this is good to know. My apologies for the confusion, Shad.
No problem. Always good to have discussion.
As with most of the big secrets the “overlords” have, the answer is probably much more simple than a technical backdoor.
I have SE turned on. Following a model more like “least privilege”, it denies access to everything, then an SE “policy” is written by the admin and put in place to grant privilege. Linux as delivered comes with appropriate SE policies to function. But once you start writing your own programs or adding in new software, policies have to be written and applied by the administrator to give them access. (SE provides an easy tool that looks at the SE errors the new program generated and generates a policy to allow just what’s needed).
If SE is used reasonably well on a machine/host that is compromised other than full root access, SE presents a stumbling block for the attacker. The example is given in the doc of a situation where Apache is compromised; in that case, Apache would only be able to do what Apache is allowed to do, instead of read every world readable file in the filesystem.
Human beings being inherently lazy, most people at the first sight of difficulty getting their new program to run, simply turn off SE when they find out that SE is preventing their program from accessing a socket, etc.
I’d venture to guess that most machines running Linux don’t have SE turned on, thus, the only things an attacker need do are discover a host IP and compromise a service or password. Since most admins (users) simply make directories and files world readable, the attacker is then free to glean what they want from the filesystem. Also, most folks passwords are easily crackable.
Gubmint has both white hats and black hats operating; the world of espionage is one of recursive lies, so undoubtedly both gubmint and private sector black hats are trying to break into the unsuspecting public’s machines.
Here are some examples logged on my web server:
Attempts to use known hacks by 4 hosts were logged 8 time(s) from:
24.103.166.94: 2 Time(s)
^null$ 2 Time(s)
66.186.236.161: 2 Time(s)
^null$ 2 Time(s)
66.206.49.14: 2 Time(s)
^null$ 2 Time(s)
66.239.61.70: 2 Time(s)
^null$ 2 Time(s)
Connection attempts using mod_proxy:
183.60.48.25 -> tcpconn2.tencent.com:443: 3 Time(s)
222.73.10.148 -> 222.73.10.148:9610: 2 Time(s)
A total of 4 sites probed the server
24.103.166.94
66.186.236.161
66.206.49.14
66.239.61.70
Requests with error response codes
/: 6 Time(s)
/asp08111902.rar: 1 Time(s)
/php08112802.rar: 1 Time(s)
/w00tw00t.at.ISC.SANS.DFind:): 4 Time(s)
HTTP/1.1: 2 Time(s)
admin/scripts/setup.php: 2 Time(s)
3LZaArATH8x9fh&: 1 Time(s)
/?fp=f%2F7YkxLbdqFzUQ29T6QuhDUn7mdSTBU65R1 ... xoisvflURnYHUw&: 1 Time(s)
/?g1t2h=iii.X1VWa5vBcf1saf.vNs%23zFGFAAtEtE&t1m2k3=&: 2 Time(s)
//php-my-admin/config/config.inc.php?p=phpinfo();: 2 Time(s)
//php-my-admin/index.php: 4 Time(s)
//phpMyAdmin-2.2.3/index.php: 2 Time(s)
//phpMyAdmin-2.2.6/index.php: 2 Time(s)
//phpMyAdmin-2.5.1/index.php: 2 Time(s)
//phpMyAdmin-2.5.4/index.php: 2 Time(s)
//phpMyAdmin-2.5.5-pl1/index.php: 2 Time(s)
//phpMyAdmin-2.5.5-rc1/index.php: 2 Time(s)
//phpMyAdmin-2.5.5-rc2/index.php: 2 Time(s)
//phpMyAdmin-2.5.5/index.php: 2 Time(s)
/?g1t2h=X1VWa5vBcf1saf.JvV%23zFGGHbGFbF&t1m2k3=&: 1 Time(s)
/?g1t2h=X1VWa5vBcf1saf.vNs%23zFGFTFZGbb&t1 ... rxoisvflURnYHUw: 1 Time(s)
/?g1t2h=X1VWa5vBf1saf.Bf5%23zFGFGTzGFF&t1m2k3=&: 4 Time(s)
/?q=user: 1 Time(s)
/HNAP1/: 8 Time(s)
/MIVALine/HighlightKeywords.css: 3 Time(s)
/MyAdmin/scripts/setup.php: 13 Time(s)
/MySQLAdmin/scripts/setup.php: 2 Time(s)
/PHPMYADMIN/scripts/setup.php: 2 Time(s)
/PMA/scripts/setup.php: 1 Time(s)
/PMA2005/scripts/setup.php: 2 Time(s)
/SQL/scripts/setup.php: 2 Time(s)
/SSLMySQLAdmin/scripts/setup.php: 1 Time(s)
We must remember that the people “pulling the strings” subvert organizations like the NSA by controlling the people at the top of the organization, and by making small “organizations within an organization”. Most people in the NSA are simply doing their job and have no idea about any big “evil master plan”. They are just doing their job. They can help the public all day long by making tools like SE Linux - but that won’t thwart the efforts of the “org within an org”.
First of all, as I said, most people turn off SE Linux - the control is available right from within the graphical interface, you don’t even have to go on the command line to turn it off. Just a few clicks, and all your security “issues” “go away”.
Secondly, unix itself is a security nightmare; it’s both complex and at the same time rinky-tink. How many of us go through our entire filesystem and make sure our permissions are right ? What about the directories and files under our own /home directory ? Most do not keep their files only readable by Owner, so the root password is not needed to read our files. Let alone the operation of all those services, languages, the countless commands: mind-numbing complexity and minutiae. Yet it’s far less of a nightmare than Windows because at least, with enough digging, you can find out what’s going on, even if you have to get down to the kernel source, whilst Windows is just a complete, utter disaster that is a mystery - on purpose !
Every service in the present-day OS architectures offers hacking potential. So it’s far more likely that backdoors are hidden in things like printing services than in the security part of the kernel. Just take for example Apache - there are countless ways to make mistakes in configuring it that will allow instrusions and allow dangerous access once it’s compromised. I literally sat, line by line in the config file, googling each setting along with words relating to hack, vulnerability, etc. It’s a monstrous minefield of pitfalls. Simple rules of thumb - if you don’t need it, don’t install it. Contrary to popular opinion, once you get your machine secure, it’s secure - so don’t keep updating it. Anything you change must be thoroughly researched in order to “wise up” to the vulnerabilities before you make the change. Get your machine configured so that it will not respond to illegitimate requests and keep it that way. An upgrade then becomes a whole new project where one takes the time to once again review everything (all configuration, services, running nmap against it, etc.) - old and new - before you start using your machine for anything.
Lastly, to sum up, perhaps the simplest answer of all is accurate; NSA, and by extension, government, looks great in the public eye in terms of being interested in secure computing by taking the initiative to contribute SE to Linux - most of their employees will echo the comment that the private sector should secure their machines against the threat of some “cyber attack”. Yet - SE can actually be what it says it is (no backdoor), and still not do much at all to stop the “threat of cyber attack”.
The NSA has cover - they’re doing their job. The transnational financial oligarchy and their efforts (manufactured crises, control of leading politicians and diplomats, control of capital, leadership in espionage, etc.) are not impeded by SE at all.
That kind of configuration is difficult to implement and can be hard to use. So while we have the tool(s) necessary to make us safe from any snooping (including the "org within and org" government, it is rarely (if ever) used effectively.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.