| |||||||||||||
The embedded long-term support initiativeThe embedded long-term support initiativePosted Oct 29, 2011 16:21 UTC (Sat) by fuhchee (subscriber, #40059)Parent article: The embedded long-term support initiative
"only bug fixes and security updates will be considered"
How do they intend to divine which mainline patches are security-sensitive?
(Log in to post comments)
The embedded long-term support initiative Posted Oct 30, 2011 7:23 UTC (Sun) by raven667 (subscriber, #5198) [Link]
They will make a guess, which will necessarily be incomplete, such that their secure kernel is still vulnerable to any number of issues that haven't been publicly discovered yet. Vulnerabilities are like that, they exist for years before anyone notices them.
The embedded long-term support initiative Posted Oct 30, 2011 8:44 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Who cares? Kernel is insanely vulnerable anyway. The only sensible way it to minimize the attack surface as much as possible.
The embedded long-term support initiative Posted Oct 30, 2011 14:56 UTC (Sun) by vonbrand (subscriber, #4458) [Link] Kernel is insanely vulnerable anyway. Care to quantify and prove this?
The embedded long-term support initiative Posted Oct 30, 2011 17:43 UTC (Sun) by raven667 (subscriber, #5198) [Link]
I think we are past that now, the lead kernel developers don't believe or claim that one can successfully run malicious local processes without the possibility of local root compromise. Look at kernel.org where they are no longer giving away shell access just for fun to reduce the attack surface area. No one is making the claim that the linux kernel is sufficiently free of vulnerabilities that one could host multiple malicious users safely on the same system. The talk now is about virtualization for security isolation, what is being done on a single system image isn't good enough.
The embedded long-term support initiative Posted Oct 31, 2011 10:43 UTC (Mon) by paulj (subscriber, #341) [Link]
Except the virtualisation systems, common ones at least like Xen and Qemu/KVM, don't seem to take any different approach to secure programming than the kernel does. They offer no more assurance of security than the kernel. While they might have fewer interfaces to their host than the kernel does to regular users, those interfaces can be very very complex (because performance is so important) and even arcane (e.g. for compatibility with x86 distributions - applies even with Xen sometimes). Xen and KVM regularly have issues that compromise host security.
Virtualisation does not seem a solution to me. Any systematic solution to security of hypervisors seems like it'd apply equally well to traditional kernels, surely?
The embedded long-term support initiative Posted Oct 31, 2011 18:04 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Sure, what you say is true but the important point is that the interface between the OS kernel and the Hypervisor is much smaller and more rigidly defined than the interface between a user process and an OS kernel. The Hypervisor has orders of magnitude fewer features and attack surface area and is therefore more practical to usefully validate.
The embedded long-term support initiative Posted Oct 30, 2011 21:37 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
raven667 said pretty much what I think.
Linux may be somewhat secure if one limits it to simple routing and firewall-related tasks. It's certainly not secure if one decides to use it, for example, to host world-accessible NFS shares or try to contain malicious local users.
And by this point in time, it can't really be fixed short of rewriting it in a safe language.
The embedded long-term support initiative Posted Oct 31, 2011 7:37 UTC (Mon) by Lionel_Debroux (subscriber, #30014) [Link]
Perhaps the number of vulnerabilities (multiple forms of DoS, information leaks, etc.), of various severity, which affect the kernel (as a special case of a huge piece of complex software), and are introduced and fixed by dozens every major kernel release ?
Counting CVEs is a weak measurement for the number of vulnerabilities, since only a small subset of vulnerabilities gets a CVE number.
A way to get a more secure Linux kernel is to use the large PaX/grsecurity patch, which prevents a number of classes of vulnerabilities from successful exploitation.
|
|||||||||||||