On Sat, Jul 24, 2010 at 19:23 +0100, Al Viro wrote:
> On Sat, Jul 24, 2010 at 08:07:01PM +0400, Vasiliy Kulikov wrote:
> > Hi,
> >
> > I've found that some drivers check process capabilities via capable() in
> > open(), not in ioctl()/write()/etc.
> >
> > I cannot find answer in POSIX, but IMO process expects that file
> > descriptors of priviledged user and file descriptors of the same
> > file/device are the same in priviledge aspect. Driver should deny/allow
> > open() and deny/allow ioctl() based on user priviledges. The path how
> > the process gained this fd doesn't matter.
> >
> > So I think these 2 examples should be equal:
> >
> > 1) root process opened the file and then dropped its priviledges
> >
> > 2) nonroot process opened the file
>
> They most certainly should _not_. Consider the following mechanism:
> process A authenticates itself to process B
> B is convinced to open a file that wouldn't be readable for A.
> B passes descriptor to A.
> A reads from it.
> You are breaking that.
No, I mean that if driver allowed process to open the file, gained fd
should be the same. I say that if process A has _opened_ file, its fd should be the same
that convinced from B.
In your example and current implementation process A allowed to open
file, but it is not the same if B opens file and passes fd to A.
Example from drivers/char/apm-emulation.c:
static int apm_open(struct inode * inode, struct file * filp)
{
...
as->suser = capable(CAP_SYS_ADMIN);
...
}
apm_ioctl(struct file *filp, u_int cmd, u_long arg)
{
...
if (!as->suser || !as->writer)
return -EPERM;
...
}
Root can open apm file (as->suser would be true), pass it to
unpriviledged process and it would be able to suspend the system
(as->suser would be still true).
Unpriviledged process can also open apm file (as->suser would be 0), but
would not be able to suspend the system.
Also patalogical case :) unpriviledged process passes fd to root process
and root process cannot suspend the system.
Btw, the list of such drivers is much smaller, some of them just return
-EPERM and open() fails, it is OK. I'll resend more precise list soon.
--
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
