linux-kernel - Re: [PATCH] printk: Check real user/group id for %pK

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: <5248B724.8060408@gmail.com>
Date:	Mon, 30 Sep 2013 09:26:28 +1000
From:	Ryan Mallon <rmallon@...il.com>
To:	George Spelvin <linux@...izon.com>
CC:	akpm@...ux-foundation.org, dan.j.rosenberg@...il.com,
	eldad@...refinery.com, jkosina@...e.cz,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk: Check real user/group id for %pK

On 30/09/13 09:15, George Spelvin wrote:
> The basic idea is good, but I'm not sure if this is the correct permission
> check to use.
> 
> After all, a setuid program might also want to give filtered access to
> a /proc file with some %pK values.

Yeah. I'm not sure if this will break some applications (e.g. perf?)
which are expecting to be able to read %pK values if invoked setuid. The
problem is that allowing that can potentially be used to leak
information too.

> 
> The fundamental problem is that %pK is using permissions at the time
> of the read(), while the general Unix rule that setuid programs expect
> is that permission is checked at open() time.  pppd is an example; its
> options_fom_file() function (pppd/options.c:391 in the 2.4.5 release)
> does:
> 
>     euid = geteuid();
>     if (check_prot && seteuid(getuid()) == -1) {
> 	option_error("unable to drop privileges to open %s: %m", filename);
> 	return 0;
>     }
>     f = fopen(filename, "r");
>     err = errno;
>     if (check_prot && seteuid(euid) == -1)
> 	fatal("unable to regain privileges");
> 

Right, so the pppd application is actually doing the correct thing.

> 
> Now the whole struct cred and capability system is something I don't
> really understand, but it is clear from a brief look at the code
> that getting the appropriate credential through the seq_file to
> lib/vsprintf.c:pointer() would be tricky.

:-).

> 
> But it also seems like the Right Thing to do; other fixes seem like
> ineffective kludges.

Will wait and see what others have to say.

(also apologies for the badly formatted initial post. The mail client on
my other machine is apparently not configured properly).

Thanks,
~Ryan


--
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/