[PCWorld]

Post your comments for Why Switching OS Platforms Is Not a Security Fix here

[LordInsidious]

Really the guy who just called disabling Java an 'innovative approach' to stopping OSX malware is calling others out on 'you're holding it wrong', really? What about OSX users who use Java, are they holding their mouse wrong? As for the rest of the content switching platforms because one got a virus and is therefore less secure is not an intelligent argument, but MS users have been telling that to Mac users for years.

[tonybradley]

LordInsidious, on 13 April 2012 - 02:04 PM, said:

Really the guy who just called disabling Java an 'innovative approach' to stopping OSX malware is calling others out on 'you're holding it wrong', really? What about OSX users who use Java, are they holding their mouse wrong? As for the rest of the content switching platforms because one got a virus and is therefore less secure is not an intelligent argument, but MS users have been telling that to Mac users for years.

I'm not following you. Users who use Java will continue to use Java. The proactive disabling of Java when not in use is not meant as a replacement for actually fixing Java. When vulnerabilities are discovered in Java, Oracle will have to address them, and Apple will have to incorporate the appropriate patch into its implementation as well. However, it is a core mantra of security best practices to uninstall or disable software that isn't being used, and the solution put forth by Apple takes care of the issue--at least for Java--to ensure that the potential attack exposure is as little as possible. Hopefully that will minimize the compromised machines and avoid this sort of attack in the future.

[LordInsidious]

tonybradley, on 13 April 2012 - 02:28 PM, said:

LordInsidious, on 13 April 2012 - 02:04 PM, said:

Really the guy who just called disabling Java an 'innovative approach' to stopping OSX malware is calling others out on 'you're holding it wrong', really? What about OSX users who use Java, are they holding their mouse wrong? As for the rest of the content switching platforms because one got a virus and is therefore less secure is not an intelligent argument, but MS users have been telling that to Mac users for years.

I'm not following you. Users who use Java will continue to use Java. The proactive disabling of Java when not in use is not meant as a replacement for actually fixing Java. When vulnerabilities are discovered in Java, Oracle will have to address them, and Apple will have to incorporate the appropriate patch into its implementation as well. However, it is a core mantra of security best practices to uninstall or disable software that isn't being used, and the solution put forth by Apple takes care of the issue--at least for Java--to ensure that the potential attack exposure is as little as possible. Hopefully that will minimize the compromised machines and avoid this sort of attack in the future.

And not holding an iPhone 4 on the bottom left side (I think that is the 'magic' spot) will minimize dropped calls. Saying not to use something that is perfectly reasonable to use just because bad people are looking to exploit it is not security best practices, don't try to equate Java to some one off program that has not been used in a couple of years.

[MichaelRousseau]

LordInsidious, on 13 April 2012 - 02:46 PM, said:

tonybradley, on 13 April 2012 - 02:28 PM, said:

LordInsidious, on 13 April 2012 - 02:04 PM, said:

Really the guy who just called disabling Java an 'innovative approach' to stopping OSX malware is calling others out on 'you're holding it wrong', really? What about OSX users who use Java, are they holding their mouse wrong? As for the rest of the content switching platforms because one got a virus and is therefore less secure is not an intelligent argument, but MS users have been telling that to Mac users for years.

I'm not following you. Users who use Java will continue to use Java. The proactive disabling of Java when not in use is not meant as a replacement for actually fixing Java. When vulnerabilities are discovered in Java, Oracle will have to address them, and Apple will have to incorporate the appropriate patch into its implementation as well. However, it is a core mantra of security best practices to uninstall or disable software that isn't being used, and the solution put forth by Apple takes care of the issue--at least for Java--to ensure that the potential attack exposure is as little as possible. Hopefully that will minimize the compromised machines and avoid this sort of attack in the future.

And not holding an iPhone 4 on the bottom left side (I think that is the 'magic' spot) will minimize dropped calls. Saying not to use something that is perfectly reasonable to use just because bad people are looking to exploit it is not security best practices, don't try to equate Java to some one off program that has not been used in a couple of years.

Your all over the map on this argument. I want what your smoking. Either that or you ran out of smoke and are doing a troll trip.

[LordInsidious]

MichaelRousseau, on 13 April 2012 - 02:55 PM, said:

LordInsidious, on 13 April 2012 - 02:46 PM, said:

tonybradley, on 13 April 2012 - 02:28 PM, said:

LordInsidious, on 13 April 2012 - 02:04 PM, said:

Really the guy who just called disabling Java an 'innovative approach' to stopping OSX malware is calling others out on 'you're holding it wrong', really? What about OSX users who use Java, are they holding their mouse wrong? As for the rest of the content switching platforms because one got a virus and is therefore less secure is not an intelligent argument, but MS users have been telling that to Mac users for years.

I'm not following you. Users who use Java will continue to use Java. The proactive disabling of Java when not in use is not meant as a replacement for actually fixing Java. When vulnerabilities are discovered in Java, Oracle will have to address them, and Apple will have to incorporate the appropriate patch into its implementation as well. However, it is a core mantra of security best practices to uninstall or disable software that isn't being used, and the solution put forth by Apple takes care of the issue--at least for Java--to ensure that the potential attack exposure is as little as possible. Hopefully that will minimize the compromised machines and avoid this sort of attack in the future.

And not holding an iPhone 4 on the bottom left side (I think that is the 'magic' spot) will minimize dropped calls. Saying not to use something that is perfectly reasonable to use just because bad people are looking to exploit it is not security best practices, don't try to equate Java to some one off program that has not been used in a couple of years.

Your all over the map on this argument. I want what your smoking. Either that or you ran out of smoke and are doing a troll trip.

I'd share if I was smoking but I'm not. I can see that the point gets lost without the context of ' http://www.pcworld.c...s_for_macs.html '. Essentially turn off Java, no flashback virus ('clever'). Don't hold a iPhone 4 that way, no dropped calls (not acceptable?). Point is you should be able to have a secure computer with Java if Java is supporting it just like you should be able to hold a phone the way you want.

[nonseq]

LordInsidious, on 13 April 2012 - 03:15 PM, said:

I'd share if I was smoking but I'm not. I can see that the point gets lost without the context of ' http://www.pcworld.c...s_for_macs.html '. Essentially turn off Java, no flashback virus ('clever'). Don't hold a iPhone 4 that way, no dropped calls (not acceptable?). Point is you should be able to have a secure computer with Java if Java is supporting it just like you should be able to hold a phone the way you want.

Your argument loses because there was no evidence of dropped calls caused by holding the iPhone wrong. The studies addressed antenna attenuation but not dropped calls. Nice of you to keep repeating the mantra (unsupported and unproven) as it renders the rest of your argument as specious.

[dtschmitz]

tonybradley, on 13 April 2012 - 02:28 PM, said:

LordInsidious, on 13 April 2012 - 02:04 PM, said:

Really the guy who just called disabling Java an 'innovative approach' to stopping OSX malware is calling others out on 'you're holding it wrong', really? What about OSX users who use Java, are they holding their mouse wrong? As for the rest of the content switching platforms because one got a virus and is therefore less secure is not an intelligent argument, but MS users have been telling that to Mac users for years.

I'm not following you. Users who use Java will continue to use Java. The proactive disabling of Java when not in use is not meant as a replacement for actually fixing Java. When vulnerabilities are discovered in Java, Oracle will have to address them, and Apple will have to incorporate the appropriate patch into its implementation as well. However, it is a core mantra of security best practices to uninstall or disable software that isn't being used, and the solution put forth by Apple takes care of the issue--at least for Java--to ensure that the potential attack exposure is as little as possible. Hopefully that will minimize the compromised machines and avoid this sort of attack in the future.

Folks,
This is Dietrich T. Schmitz, your Linux Advocate.
I've been watching Mr. Bradley for some time. Frankly, he needs to educate himself to the issues.

Here's an article I will share which I wrote recently:
http://2buntu.com/20...ty-modules-lsm/

Please read it and then come back.

Now, the issue here isn't that Linux can't get infected. It can, as can any other operating system.

What distinguishes Linux from OSX and Windows?: Linux Security Modules (LSM)

Essentially, I have been having this 'debate' with the Windows Tech crowd over at ZDNet for quite some time. So, I am quite used to the flamers who try to marginalize what I write. Bring it, if you think you can.

Linux wasn't designed with LSM built in. In fact, it came along as a modest 'design-in' change to set up a kernel 'hook' to pass control to an external dynamically loadable kernel module which when bound to the kernel at boot time will 'police' the actions of any profiled 'Application' and, THIS IS IMPORTANT, the KERNEL.

You see, what is happening in the Windows World is that Windows, all the way back to Windows 2000 is still using a legacy WinNT kernel. There is no equivalent to LSM in Windows or OSX.

LSM, when resident, will take each granular action taken by the Application, or, if a call is sent to the kernel, and compare it to its 'profile' and if the action is not defined will 'deny' otherwise, the action gets an 'allow' and the process id can execute.

This notion of having a third-party DKMS act as the 'police' makes LSM fool-proof.

Ubuntu Linux comes with LSM AppArmor and a profile for your Firefox. When Firefox is 'sandboxed' by LSM, any undefined action, or 'unintended side-effect' which is being used as an exploit to esclate privilege to launch a kernel 'root' administrative rights is simply denied.

So, you can if running Ubuntu with LSM be comforted in the knowledge that Zero Days will have no effect and your Distro will update your system within hours or days with a security patch.

No scrambling on Zero-Day.

Linux with LSM: The safest operating system on the Planet.

I stake my reputation on it.

Thank you Mr. Bradley

Dietrich T. Schmitz
Linux Advocate, Human Being

[linuxrants7xpg]

dtschmitz, on 13 April 2012 - 03:33 PM, said:

Folks,
This is Dietrich T. Schmitz, your Linux Advocate.
I've been watching Mr. Bradley for some time. Frankly, he needs to educate himself to the issues.

Here's an article I will share which I wrote recently:
http://2buntu.com/20...ty-modules-lsm/

It pains me that I can only +1 that comment one time. Very well said.

[bikdav]

This is just what I suspected all along. My argument is not the operating system, but the bad moves that too many people make on their computers. Instead of hopping from one system to another, there is an easier way to protect yourself. BE CAREFUL!

[Nuke61]

dtschmitz, on 13 April 2012 - 03:33 PM, said:

Linux wasn't designed with LSM built in. In fact, it came along as a modest 'design-in' change to set up a kernel 'hook' to pass control to an external dynamically loadable kernel module which when bound to the kernel at boot time will 'police' the actions of any profiled 'Application' and, THIS IS IMPORTANT, the KERNEL.

I'm curious... if LSM is executing at kernel level privilege, how does it 'police' actions of the kernel itself? Does a policing action require a privilege level greater than that which is being protected? I understand the protection of an application executing in User space being prevented access to kernel level space, but you're claiming that LSM's police KERNEL privileged code. How does that work? I read you article and you don't explain it.

[FF22]

LordInsidious, on 13 April 2012 - 02:46 PM, said:

don't try to equate Java to some one off program that has not been used in a couple of years.

Actually, Java IS a piece of software that has not been used in years on most user's computers - at least not in the web browser. Java was always an overshoot in the browser environment (which is funny, considering that browsers were the primary environment it was designed to run on), but with the advent of modern browsers and especially HTML5-features like Canvas, WebGL and even worker threads, it pretty much became totally superflous and essentially the worst choice of platform to implement anything on, at least on the web. The only reason to use Java on the web today is for compatibility reasons - which also means it should be disabled on pretty much all computers, except on those, that specifically need it due to said reasons.

[kronoscornelius]

The Linux kernel runs on Super computers and big blue chip companies. You can run that same software on your computer if you just open your mind. To say that the kernel run by Facebook and Google is equally save to Windows or Mac is bad speculation. In hacker contests, the Mac always goes first.

In Linux, you can be as save as your willingness to be inconvenienced by the security layers.

[MichaelBurrington]

Tony - why are you such a Linux hater? First you try to convince us that Linux is dead as a desktop, now you're telling us not to switch to Linux because it's not as secure as you think!

Your best argument is Linux isn't attacked much because it's not popular - that's absolutely not true - If Linux isn't so secure, why is it used for more than 20% of all web servers? These get attacked more than all the Macs and Windows PCs combined. When there is a failure, they get fixed, very quickly, and keep on going. Whatever is learned to secure the web servers gets passed down to the desktop versions, using the same kernel.

Windows is without question the least secure. Both Mac and Linux aren't half bad for security, but you can't stop people from doing stupid things. That's more of a problem than security of the operating system with either Mac OS or Linux. Windows takes months at times to respond to security threats, while both Mac and the Linux crowd respond pretty darn fast and they are both good operating systems (though I can't stand to have my pocketbook controlled by iTunes).

Anyway, please stop the Linux hate. If you don't like it - that's fine, don't use it. Maybe the rest of us who do know something you don't and you should ask why instead of bashing us.

[dtschmitz]

Nuke61, on 13 April 2012 - 05:31 PM, said:

dtschmitz, on 13 April 2012 - 03:33 PM, said:

Linux wasn't designed with LSM built in. In fact, it came along as a modest 'design-in' change to set up a kernel 'hook' to pass control to an external dynamically loadable kernel module which when bound to the kernel at boot time will 'police' the actions of any profiled 'Application' and, THIS IS IMPORTANT, the KERNEL.

I'm curious... if LSM is executing at kernel level privilege, how does it 'police' actions of the kernel itself? Does a policing action require a privilege level greater than that which is being protected? I understand the protection of an application executing in User space being prevented access to kernel level space, but you're claiming that LSM's police KERNEL privileged code. How does that work? I read you article and you don't explain it.

Here's a snippet from /var/log/kern.log showing LSM AppArmor blocking the kernel:

Apr 8 07:54:04 AOD260 kernel: [28117.140619] type=1400 audit(1333886044.450:178): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/video0" pid=4860 requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

[Nuke61]

dtschmitz, on 14 April 2012 - 03:03 AM, said:

Nuke61, on 13 April 2012 - 05:31 PM, said:

I'm curious... if LSM is executing at kernel level privilege, how does it 'police' actions of the kernel itself? Does a policing action require a privilege level greater than that which is being protected? I understand the protection of an application executing in User space being prevented access to kernel level space, but you're claiming that LSM's police KERNEL privileged code. How does that work? I read you article and you don't explain it.

Here's a snippet from /var/log/kern.log showing LSM AppArmor blocking the kernel:
Apr 8 07:54:04 AOD260 kernel: [28117.140619] type=1400 audit(1333886044.450:178): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/video0" pid=4860 requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Correct me if I'm reading this incorrectly, but that looks like the FIREFOX application, presumably running in User space, was prevented from accessing a Kernel level permission to open a video stream. If so, AppArmor is not blocking the kernel, it's preventing an application from performing an action that requires kernel privilege.

[dtschmitz]

Nuke61, on 14 April 2012 - 05:49 AM, said:

dtschmitz, on 14 April 2012 - 03:03 AM, said:

Nuke61, on 13 April 2012 - 05:31 PM, said:

I'm curious... if LSM is executing at kernel level privilege, how does it 'police' actions of the kernel itself? Does a policing action require a privilege level greater than that which is being protected? I understand the protection of an application executing in User space being prevented access to kernel level space, but you're claiming that LSM's police KERNEL privileged code. How does that work? I read you article and you don't explain it.

Here's a snippet from /var/log/kern.log showing LSM AppArmor blocking the kernel:
Apr 8 07:54:04 AOD260 kernel: [28117.140619] type=1400 audit(1333886044.450:178): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/video0" pid=4860 requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Correct me if I'm reading this incorrectly, but that looks like the FIREFOX application, presumably running in User space, was prevented from accessing a Kernel level permission to open a video stream. If so, AppArmor is not blocking the kernel, it's preventing an application from performing an action that requires kernel privilege.

I'll be happy to clarify. The kernel if bound to LSM MUST pass control (hook) to the LSM for any kernel process. It just so happens, that indeed Firefox process is the parent process but control of /dev/video0 is being facilitated by the kernel. Any application that uses operating system resources will have to spawn a child process to the kernel. audit is denying the kernel:

http://static.usenix...html/node3.html

http://static.usenix...t_html/img1.png

I hope that helps.

[Nuke61]

dtschmitz, on 14 April 2012 - 06:11 AM, said:

I hope that helps.

It confirms that this was an application that was denied access to kernel level privilege, and not a case of the kernel being protected from itself.

From Ubuntu:

Quote

AppArmor is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources.

AppArmor does not police the actions of the kernel, it polices the action of applications.

[dtschmitz]

Nuke61, on 14 April 2012 - 06:33 AM, said:

dtschmitz, on 14 April 2012 - 06:11 AM, said:

I hope that helps.

It confirms that this was an application that was denied access to kernel level privilege, and not a case of the kernel being protected from itself.

From Ubuntu:

Quote

AppArmor is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources.

AppArmor does not police the actions of the kernel, it polices the action of applications.

Nobody is running the kernel. The kernel layer is arbitrating application requests.
LSM examines both application level and kernel level policy. This is a kernel log showing the action (child process id) taken by the parent application. The process id is 'owned' by the kernel.

There is no equivalent in OSX or Windows.
If an exploit manages to inject a DLL, succeeds and then spawns a kernel priviledged request for administrative access on Windows, the kernel will simply process the request.

Here's a disclaimer by Google Engineers on the very issue:

Citation:
http://dev.chromium....C-Other-caveats

Other caveats
"The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer. Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.

In addition, third party software, particularly anti-malware solutions, can create new attack vectors. The most troublesome are applications that inject dlls in order to enable some (usually unwanted) capability. These dlls will also get injected in the sandbox process. In the best case they will malfunction, and in the worst case can create backdoors to other processes or to the file system itself, enabling specially crafted malware to escape the sandbox."

------------- citation end

Exploits on Windows cannot be stopped.
LSM does stop exploits and stands in the way of the kernel.

This post has been edited by dtschmitz: 14 April 2012 - 06:53 AM

[Nuke61]

I agree with "LSM does stop exploits and stands in the way of the kernel." but not your earlier claim of "will 'police' the actions of any profiled 'Application' and, THIS IS IMPORTANT, the KERNEL." LSM intervenes between applications and the kernel (i.e., stands between them), but it does not police action of the kernel. Let me be clear, I think LSM is a great addition from a security perspective, but I doubt the typical Windows or OS X user would know or even want to know how to use it, even in it's learning mode.

Quote

There is no equivalent in OSX or Windows.
If an exploit manages to inject a DLL, succeeds and then spawns a kernel priviledged request for administrative access on Windows, the kernel will simply process the request.

I don't know about Windows, but I think you're incorrect about OSX.

Quote

The really big news for most developers is that the app sandboxing from iOS is now here. The reason it’s big news is that pretty soon, any app on the Mac app store will need to sign up to sandboxing: apps that don’t will be rejected. But what is it?

Since 10.5, Mac OS X has included a mandatory access control framework called seatbelt, which enforces restrictions governing what processes can access what features, files and devices on the platform. This is completely orthogonal to the traditional user-based permissions system: even if a process is running in a user account that can use an asset, seatbelt can say no and deny that process access to that asset.

This sounds exactly like what LSM does, and it makes sense since OS X is Unix with an Apple GUI on top of it. However, just like LSM, the profile for an app needs to be activated. It clearly wasn't active for the Java VM, which is the entire reason for this PCWorld article and the large Mac outbreak.