I have chopped your email up to respond to the easy bits first. > I looked at the mailing lists and found no one is working on this. > Please correct my understanding. I am new to kernel newbies, so this > is what i think before starting:- > 1. Contact Hans Grobler for starting up ? Don't do that. He wasn't offering to teach people he was just suggesting ideas. > 2. Find files with ioctl functions already implemented and do the > required assessment. > > Also, needed some advise on git branching to work on the kernel. linux-next. > "...From: Hans Grobler > - audit ioctl functions to make sure there is no way a user can crash > the machine or do sensitive stuff. For example, check for the > necessary capabilities. Check that no userspace pointers are accessed > directly. be careful with this... it takes a while to figure out which > ioctls are covered by the parent ioctl function (these can be nested > to great depths)..." > Looking for these sort of security bugs is fun. These days userspace pointers are annotated with the __user tag and Sparse warns if they are used incorrectly. "warning: dereference of noderef expression" We are pretty good about eliminating these kinds of bugs. You will find some warnings still, but the majority are false positives. Really this task is quite hard because people are constantly looking for security bugs. I do with Smatch. But in drivers/staging/ there are still quite a few left. Btw, most times when you think you have found a security bug in an ioctl, you really haven't. There is always some reason why the bug is hard to exploit. If you think you have found one, then let us know on the list and we can check it for you. (It's fine to discuss security bugs from drivers/staging/ in public, no one will get upset. I fix these sorts of thing regularly.) regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
