Require mentoring for picking up

Require mentoring for picking up

[Imtiyaz Hussain]

Hello list,

I have set up my test-box with help from Kumar Amit Mehta. I would
like to start kernel janitorial work and would like to take up the
below task found in TODO link (
http://kernelnewbies.org/KernelJanitors/Todo ):-

"...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)..."

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 ?
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.

Your advise will be helpful.

Sincerely,
Immi

Re: Require mentoring for picking up

[Logan Blyth]

I also would like help setting up a test box / getting started as a 
janitor.  Imtiyaz beat me to an email :)
On 07/02/2013 07:56 PM, Imtiyaz Hussain wrote:
> Hello list,
>
> I have set up my test-box with help from Kumar Amit Mehta. I would
> like to start kernel janitorial work and would like to take up the
> below task found in TODO link (
> http://kernelnewbies.org/KernelJanitors/Todo ):-
>
> "...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)..."
>
> 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 ?
> 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.
>
> Your advise will be helpful.
>
> Sincerely,
> Immi
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Require mentoring for picking up

[Dan Carpenter]

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