Linux Kernel Security (was Re: Userspace data races)

[Lisa Kachold]

Hi Greg and Sarah, 

Thanks for your responses, please accept my apology for failing to edit the subject and not being clear as to my intent or questions.

Greg, of course we have no userspace race conditions in the linux kernel (similar to that reverse engineering under Micro$soft), however, we do have a good number of long standing issues (many in device drivers).

Here's a current issue:  http://www.linuxsecurity.com/content/view/159294

excerpt:  Software Description:

- linux-ec2: Linux kernel for EC2

Details:

Mathias Krause discovered an information leak in the Linux kernel's
getsockname implementation for Logical Link Layer (llc) sockets. A local
user could exploit this flaw to examine some of the kernel's stack memory.
(CVE-2012-6542)

Mathias Krause discovered information leaks in the Linux kernel's Bluetooth
Logical Link Control and Adaptation Protocol (L2CAP) implementation. A
local user could exploit these flaws to examine some of the kernel's stack
memory. (CVE-2012-6544)

Do we create new security issues only to have others come along and patch them or integrate security patches into our other work?

On Sun, May 5, 2013 at 9:06 AM, Greg KH <gr...@kroah.com> wrote:

Note, for new topics, please create a new thread, it's just proper
mailing list etiquette.

On Sun, May 05, 2013 at 08:36:10AM -0700, Lisa Kachold wrote:
> http://j00ru.vexillium.org/?p=1695
>
> A discussion of user space race conditions or aren't we glad we are not
> Microsoft developers?
>
> Which one of use will fix the extant linux kernel security issues?

I don't understand, do you think that Linux has this same type of error?
At first glance, I do not think it does, due to how we (hopefully)
enforce how we access userspace data from within the kernel.

thanks,

greg k-h

On 5 May 2013 09:54, "Sarah Sharp" <sarah....@intel.com> wrote:

On Sun, May 05, 2013 at 08:36:10AM -0700, Lisa Kachold wrote:
> http://j00ru.vexillium.org/?p=1695
>
> A discussion of user space race conditions or aren't we glad we are not
> Microsoft developers?
>
> Which one of use will fix the extant linux kernel security issues?

None of the mentors are Linux kernel security experts.

Sarah Sharp

Thanks for piping up Sarah, 

Are there such people, current working to fix security issues in the linux kernel?  Is linux kernel security compartmentalized to a certain subset?  I didn't see a program for it?

It was a motivating question.  Of course we don't have userspace race issue in the linux kernel; we do however have other linux kernel security issues; are those outside of the kernel project(s)?

Shouldn't we all have a good understanding of security issues in our respective work?

--

(503) 754-4452 Android
(623) 239-3392 Skype
(623) 688-3392 Google Voice
**
it-clowns.com
Chief Clown

[Greg KH]

On Sun, May 05, 2013 at 10:57:09AM -0700, Lisa Kachold wrote:
> Hi Greg and Sarah,�
>
> Thanks for your responses, please accept my apology for failing to edit the
> subject and not being clear as to my intent or questions.

Not a problem, just trying to convey some basic kernel mailing list
rules here, instead of having you find out the hard way later on :)

Oh, also, try not to top-post on your responses to email, the kernel
community doesn't like that either. Here are some reasons why:

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://daringfireball.net/2007/07/on_top

> Greg, of course we have no userspace race conditions in the linux kernel

I am not saying that at all, we might have them, I'm just saying that
thanks to how Linux handles userspace data accesses, the odds of us
having this same type of issue is quite low. We have automated tools
that help us check for this type of thing.

> (similar to that reverse engineering under Micro$soft), however, we do have a
> good number of long standing issues (many in device drivers).

Sure, we have loads of bugs, all the time. Any codebase the size of the
Linux kernel will have such things. All we can do is work to fix them
as soon as they are found, and try to use tools and processes to prevent
them from being introduced in the first place.

If you are interested in how the kernel community handles security bugs,
take a look at the file, Documentation/SecurityBugs

Hope this helps explain things better.

thanks,

greg k-h