Date: Mon, 08 Jun 2015 16:06:18 -0400 From: Colin Walters <walters@...bum.org> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com, Miloslav Trmač <mitr@...hat.com> Subject: Re: CVE request for polkit On Mon, Jun 8, 2015, at 03:44 PM, cve-assign@...re.org wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Your message seems to be about various security analysis posted to a > mailing-list thread with about 10 messages, accompanied by at least > two bug reports: > > https://bugs.freedesktop.org/show_bug.cgi?id=90837 > https://bugs.freedesktop.org/show_bug.cgi?id=90832 These two bugs I would describe as fixing the *same* problem in two different ways. > The original 2015-05-29 message seems to be about clients whereas the > first 2015-06-03 message seems to be about users or uids. Is there any > polkit documentation that suggests that two clients are allowed to > interfere with each other as long as they have the same uid? (This is > in the general case where at least one of the two clients is executing > with substantial restrictions.) By "substantial restrictions" you're thinking of things like SELinux policy domains? Currently, polkit is not ready to perform compartmentalization of that form - it treats equal uids as equal security domains. (Most importantly, uid 0 is treated as privileged, even if it's in a confined domain) > For purposes of CVE, we may be able to model this as a situation in > which the (realistically exploitable) counter wraparound is a clear > implementation error and can have a CVE ID, but the concept of uid > matching is a design change that is essentially outside the scope of > CVE. Would that be OK? That sounds right to me. I see uid matching as a fix for the wraparound. The default authority already restricts agents to only be able to register for subjects of matching uid. Or to turn it around, polkit in many places matches uids, this adds another one to fix a bug with cookie handling.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ