Re: PID reuse safety for userspace apps (Re: [linux-usb-devel] Re:[Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB viausbdevio)

[Linus Torvalds]

On Tue, 27 Sep 2005, Alan Cox wrote:
>
> On Maw, 2005-09-27 at 21:20 +0400, Solar Designer wrote:
> > The idea is to introduce a kernel call (it can be a prctl(2) setting,
> > although my pseudo-code "defines" an entire syscall for simplicity)
> > which would "lock" the invoking process' view of a given PID (while
> > letting the PID get reused - so there's no added risk of DoS).  The
> > original posting and subsequent thread can be seen here:
> 
> You can solve it just as well in kernel space without application
> changes.

Note that for at least signal sending, the security aspect is _not_ about 
whether the pid has been re-used, but about whether the _user_ matches.

This is most trivially seen by thinking about just a suid exec.

Sending a signal to a suid process should be disallowed even _if_ the
"struct task_struct" is still the same, which is why the oops fix
discussed in this thread is totally pointless - it has almost nothing to
do with security. Doing "get_task_struct()" may remove the oops, but it 
doesn't remove the security issues (pid wrapping is a total red herring: 
with get_task_struct you don't need to wrap pids at all, you just do a 
single exec on a suid executable, and off you go).

Now, the fasync interfaces are a bit inconvenient because they require the 
"struct file" to be around, since that's what also contains the owner 
information. That means that you have to track file lifetime in the urb 
submission.

I don't know the code, but if that's inconvenient, then the real solution 
ends up being to just do the permission checks by hand. Remember the 
uid/euid/pid at the time of the submission, and use them at completion.

I don't even think it's worth any general helper infrastructure: I suspect 
the interfaces are pretty broken as designed, and we should _not_ 
encourage them further. But it's not like the security check is more than 
three lines of code, so..

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/