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: <20130929231531.12932.qmail@science.horizon.com>
Date:	29 Sep 2013 19:15:31 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	akpm@...ux-foundation.org, dan.j.rosenberg@...il.com,
	eldad@...refinery.com, jkosina@...e.cz,
	linux-kernel@...r.kernel.org, linux@...izon.com, rmallon@...il.com
Subject: Re: [PATCH] printk: Check real user/group id for %pK

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.

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");

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