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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
