Comments on: UNIX/Linux Offer More Security Than Windows: Evidence http://techrights.org/2009/01/16/unix-linux-security/ Free Software Sentry – watching and reporting maneuvers of those threatened by software freedom Tue, 07 Feb 2012 14:00:35 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Roy Schestowitz http://techrights.org/2009/01/16/unix-linux-security/comment-page-1/#comment-58682 Roy Schestowitz Sun, 18 Jan 2009 21:40:28 +0000 http://boycottnovell.com/2009/01/16/unix-linux-security/#comment-58682 You can use binary/source code signatures for your programs and compilers. Assuming your digital signatures come from a good source like CERT, then you at least have some confidence. Over in China, I suspect the GNU/Linux distribution they force-feed has some China-only surveillance facilities strapped onto it. You can use binary/source code signatures for your programs and compilers. Assuming your digital signatures come from a good source like CERT, then you at least have some confidence.

Over in China, I suspect the GNU/Linux distribution they force-feed has some China-only surveillance facilities strapped onto it.

]]> By: Jose_X http://techrights.org/2009/01/16/unix-linux-security/comment-page-1/#comment-58680 Jose_X Sun, 18 Jan 2009 21:36:11 +0000 http://boycottnovell.com/2009/01/16/unix-linux-security/#comment-58680 In the prior post, I ignored the obvious hardware issues that parallel. It's important to at least make sure companies like AMD exist to keep Intel somewhat honest. ..AMD/Intel to keep Nvidia somewhat honest. Etc. In the prior post, I ignored the obvious hardware issues that parallel. It’s important to at least make sure companies like AMD exist to keep Intel somewhat honest. ..AMD/Intel to keep Nvidia somewhat honest. Etc.

]]> By: Jose_X http://techrights.org/2009/01/16/unix-linux-security/comment-page-1/#comment-58679 Jose_X Sun, 18 Jan 2009 21:29:41 +0000 http://boycottnovell.com/2009/01/16/unix-linux-security/#comment-58679 [ http://cm.bell-labs.com/who/ken/trust.html Reflections on Trusting Trust ]>> The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. To add some: Reading source code tells all -- if you trust the build system binaries that will be used to turn that source into binaries. In particular, if you have the source to the build system components, it's easier to trust those build system binaries; however, the build system binaries have to be built themselves, this means you need an existing (simpler) build system. So do you have the source to that? And how about the source to the (even simpler) build system that built this last build system? At some point, dissembling very simple binaries upon which a multi-stage build process will occur may be what is necessary in order to gain the most trust.. or just be really sure you get your binaries from someone that has gone through that trouble. For example, the gcc system should have gone through a lot of care over the years (including back when gcc was much simpler). If gcc+co are safe, then everything else built upon it (eg, a whole distro since even other language platforms like perl, etc, could be built with gcc+co) should be as trustworthy as the sources to each of the component parts of the distro (ie, you can trust those sources that make up the distro if you trust the gcc build system). [ http://cm.bell-labs.com/who/ken/trust.html Reflections on Trusting Trust ]>> The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode.

To add some:

Reading source code tells all — if you trust the build system binaries that will be used to turn that source into binaries. In particular, if you have the source to the build system components, it’s easier to trust those build system binaries; however, the build system binaries have to be built themselves, this means you need an existing (simpler) build system. So do you have the source to that? And how about the source to the (even simpler) build system that built this last build system? At some point, dissembling very simple binaries upon which a multi-stage build process will occur may be what is necessary in order to gain the most trust.. or just be really sure you get your binaries from someone that has gone through that trouble. For example, the gcc system should have gone through a lot of care over the years (including back when gcc was much simpler). If gcc+co are safe, then everything else built upon it (eg, a whole distro since even other language platforms like perl, etc, could be built with gcc+co) should be as trustworthy as the sources to each of the component parts of the distro (ie, you can trust those sources that make up the distro if you trust the gcc build system).

]]> By: The Mad Hatter http://techrights.org/2009/01/16/unix-linux-security/comment-page-1/#comment-58568 The Mad Hatter Sat, 17 Jan 2009 03:24:30 +0000 http://boycottnovell.com/2009/01/16/unix-linux-security/#comment-58568 As an aside, has anyone read <a href="http://aaxnet.com/editor/edit029.html" rel="nofollow">2003 and Beyond</a> by Andrew Grygus? It's one of the reasons that I started to seriously pursue an alternative to Windows (and Microsoft), and it's an excellent evaluation of Microsoft's plans for the years ahead (and it's interesting to read it 6 years on, and compare what Andrew thought was happening, with what actually happened). As an aside, has anyone read 2003 and Beyond by Andrew Grygus? It’s one of the reasons that I started to seriously pursue an alternative to Windows (and Microsoft), and it’s an excellent evaluation of Microsoft’s plans for the years ahead (and it’s interesting to read it 6 years on, and compare what Andrew thought was happening, with what actually happened).

]]> By: Needs Sunlight http://techrights.org/2009/01/16/unix-linux-security/comment-page-1/#comment-58546 Needs Sunlight Fri, 16 Jan 2009 12:39:07 +0000 http://boycottnovell.com/2009/01/16/unix-linux-security/#comment-58546 I remember in 2000 when WIndows rootkits started to get popular, they're largely ignored by the press. I'd guess they're ignored because they bypass any and all AV software, and thus bypass the advertising money. They also go against the myth about Windows being securable that Gates folk like the public to bleat. Two interesting pieces: "Trusting Trust" http://www.acm.org/classics/sep95/ alternate link: http://cm.bell-labs.com/who/ken/trust.html "Exploiting Concurrency Vulnerabilities in System Call Wrappers" http://www.usenix.org/events/woot07/tech/full_papers/watson/watson.pdf The first link, "trusting trust", shows that no amount of bluster or bluffing can make Windows secure. Without full access to the source code for all components in the system and its applications back doors can be hidden all over. Two follow ups for that, also show that at the end of the day, you must have and be able to use the complete source code for the whole system and each and every component or application: http://www.dwheeler.com/trusting-trust/ http://www.schneier.com/blog/archives/2006/01/countering_trus.html The second link, "concurrency vulnerabilities", looks like it completely destroys the myth that add-ons can help. It *looks* like all currently existing security software for Windows can be bypassed without detection or recourse -- until such time as Windows is redesigned and rewritten from the Kernel on up. To pick on FOSS for a bit, the first two show why the decision to tolerate BLOBs in Debian and the downgrading of the Qt license to LGPL can lead to unmitigated disasters, either through insecurity, vendor lock-in, DRM, and hardware lock-in. I remember in 2000 when WIndows rootkits started to get popular, they’re largely ignored by the press. I’d guess they’re ignored because they bypass any and all AV software, and thus bypass the advertising money. They also go against the myth about Windows being securable that Gates folk like the public to bleat.

Two interesting pieces:

“Trusting Trust”
http://www.acm.org/classics/sep95/
alternate link:
http://cm.bell-labs.com/who/ken/trust.html

“Exploiting Concurrency Vulnerabilities in System Call Wrappers”
http://www.usenix.org/events/woot07/tech/full_papers/watson/watson.pdf

The first link, “trusting trust”, shows that no amount of bluster or bluffing can make Windows secure. Without full access to the source code for all components in the system and its applications back doors can be hidden all over.

Two follow ups for that, also show that at the end of the day, you must have and be able to use the complete source code for the whole system and each and every component or application:
http://www.dwheeler.com/trusting-trust/
http://www.schneier.com/blog/archives/2006/01/countering_trus.html

The second link, “concurrency vulnerabilities”, looks like it completely destroys the myth that add-ons can help. It *looks* like all currently existing security software for Windows can be bypassed without detection or recourse — until such time as Windows is redesigned and rewritten from the Kernel on up.

To pick on FOSS for a bit, the first two show why the decision to tolerate BLOBs in Debian and the downgrading of the Qt license to LGPL can lead to unmitigated disasters, either through insecurity, vendor lock-in, DRM, and hardware lock-in.

]]>