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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |