linux-kernel - Re: check capabilities in open()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100725054511.GB9018@albatros>
Date:	Sun, 25 Jul 2010 09:45:11 +0400
From:	Vasiliy Kulikov <segooon@...il.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: check capabilities in open()

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/