[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1433793978.2356598.290097129.7DC53180@webmail.messagingengine.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
