Draft privilege escalation policy for comments
 

Hi, everyone. Since the big PackageKit brouhaha surrounding Fedora 12,
there's been a discussion surrounding the need for a policy about
privilege escalation in Fedora. Representing the QA group, we would like
for there to be such a policy in order to allow a meaningful review of
privilege escalation issues as part of QA's testing of Fedora releases.

I took this concern to FESco, who basically said they would be willing
to consider any policy that's brought to them, but won't initiate the
creation of one. I have asked the security list (which seems mostly
dormant), some security folks individually, and it's been discussed on
this list, but none of those seem to have been interested in actually
creating a policy. So in the end, QA decided we would propose a draft.
We realize this is entirely out of our area of expertise, but there
appeared to be no alternative. So, here's a draft policy for review.
This has been through three rounds of drafts within the QA group, and
includes content based on very useful feedback from members of Red Hat's
security team, particularly Miloslav Trmac. Thanks to him and to all
others who contributed to the QA group discussion.

Please do provide any and all feedback on the proposed policy. if we can
get it into a shape which most people on the list would find acceptable,
my next step will be to take it back to FESco for them to review.
Thanks.

You can find the draft policy at
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

Hi Adam,

On Fri, Jan 29, 2010 at 5:27 PM, Adam Williamson <awilliam@redhat.com> wrote:
> Hi, everyone. Since the big PackageKit brouhaha surrounding Fedora 12,
> there's been a discussion surrounding the need for a policy about
> privilege escalation in Fedora. Representing the QA group, we would like
> for there to be such a policy in order to allow a meaningful review of
> privilege escalation issues as part of QA's testing of Fedora releases.

Agree it makes sense for there to be a policy, thanks for looking at this!

> Please do provide any and all feedback on the proposed policy. if we can
> get it into a shape which most people on the list would find acceptable,
> my next step will be to take it back to FESco for them to review.
> Thanks.

So a general theme that seems to run through the policy of "don't
affect other users", and some things have exceptions (shutdown and
reboot), but others don't (change the system time, adding new
software). Is there a rationale for that?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

On Fri, 2010-01-29 at 18:40 -0500, Colin Walters wrote:

> > Please do provide any and all feedback on the proposed policy. if we can
> > get it into a shape which most people on the list would find acceptable,
> > my next step will be to take it back to FESco for them to review.
> > Thanks.
>
> So a general theme that seems to run through the policy of "don't
> affect other users", and some things have exceptions (shutdown and
> reboot), but others don't (change the system time, adding new
> software). Is there a rationale for that?

Well, reboot is a one-time operation; if there's only one user logged
in, they can only affect themselves by rebooting. Adjusting the clock or
installing new software isn't the same.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

Adam Williamson wrote:
> Please do provide any and all feedback on the proposed policy. if we can
> get it into a shape which most people on the list would find acceptable,
> my next step will be to take it back to FESco for them to review.
> Thanks.

>From the proposal:

> Add, remove, upgrade or downgrade any system-wide application or shared
> resource (packaged or otherwise)

The current PackageKit policy in F12 updates still allows upgrading (as
opposed to installing or removing, not sure about downgrading, does
PackageKit even support that?) packages without root authentication. Is this
intended to be changed as part of the proposal or should the proposal be
fixed instead (just remove "upgrade" from the sentence)?

> New and changed privilege escalation mechanisms

Is the bureaucracy in this section really necessary? AFAICT what was missing
when the F12 PackageKit change was made was the informative part of the
proposal, the maintainer just didn't know what he should be allowing and
what not. I don't think the enforcement part is really needed, maintainers
should be able to get it right on their own given the detailed list of evil
things to avoid which the proposal provides and I haven't seen any evidence
as to the contrary (again, the PackageKit example is not applicable because
the PackageKit maintainer did NOT have such a list to go by when he made his
change; there's no reason to believe he'd have made that change in spite of
it).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

On Fri, Jan 29, 2010 at 02:27:13PM -0800, Adam Williamson wrote:

> Please do provide any and all feedback on the proposed policy. if we can
> get it into a shape which most people on the list would find acceptable,
> my next step will be to take it back to FESco for them to review.
> Thanks.

I don't understand this sentence:
"with the exceptions that the 'cause to be performed' provision is waived
in this case"
maybe it already covers it, but there are more directories a user can
write to then just ~, /tmp, /var/tmp or /usr/tmp, e.g. /dev/shm and with
certain restrictions /var/spool/{cron,mail,cups,at}.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

On Sat, 2010-01-30 at 10:52 +0100, Till Maas wrote:
> On Fri, Jan 29, 2010 at 02:27:13PM -0800, Adam Williamson wrote:
>
> > Please do provide any and all feedback on the proposed policy. if we can
> > get it into a shape which most people on the list would find acceptable,
> > my next step will be to take it back to FESco for them to review.
> > Thanks.
>
> I don't understand this sentence:
> "with the exceptions that the 'cause to be performed' provision is waived
> in this case"

It means that it's okay for the user to indirectly cause changes to
happen, because that happens all the time. This particular clause
applies only to direct user actions.

> maybe it already covers it, but there are more directories a user can
> write to then just ~, /tmp, /var/tmp or /usr/tmp, e.g. /dev/shm and with
> certain restrictions /var/spool/{cron,mail,cups,at}.

full list of directories it's okay for an unprivileged user to write to
directly would be good...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

On Sat, Jan 30, 2010 at 1:20 AM, Adam Williamson <awilliam@redhat.com> wrote:
>
> Well, reboot is a one-time operation; if there's only one user logged
> in, they can only affect themselves by rebooting. Adjusting the clock or
> installing new software isn't the same.

Ok, actually "one time" feels like there's a more general principle at
work here, which is the degree to which the operation could
potentially affect other users.

For example, there's a pretty wide gulf between "install new desktop
app" (other users see a new menu entry) and "start or stop system
daemons" (can easily break printing, networking, or just crash the.
Changing the system time is in between there.

The reason I mention this specifically I'd like in the future to widen
this set a little bit for the "self managed" desktop target (i.e.
livecd download), specifically include at least "install new desktop
application from " and "initiate system update" in that set of default
privileges.

Maybe the way to think of system update is that the system comes by
default configured to update, and the privilege is actually to
optionally delay the update.

I think it's very important that we make typing in the root password
dialog a meaningful event, something that means "you are doing
something really unusual, are you sure?", like turning off SELinux.
If we require it for simply installing Firefox security updates it
greatly dilutes the warning/danger value of it.

So as long as we don't view this current list as written on stone
tablets but a flexible system (more in the sense of
guidelines/examples), subject to revision, I'm fine with it.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

On Sat, 2010-01-30 at 08:33 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Please do provide any and all feedback on the proposed policy. if we can
> > get it into a shape which most people on the list would find acceptable,
> > my next step will be to take it back to FESco for them to review.
> > Thanks.
>
> >From the proposal:
>
> > Add, remove, upgrade or downgrade any system-wide application or shared
> > resource (packaged or otherwise)
>
> The current PackageKit policy in F12 updates still allows upgrading (as
> opposed to installing or removing, not sure about downgrading, does
> PackageKit even support that?) packages without root authentication. Is this
> intended to be changed as part of the proposal or should the proposal be
> fixed instead (just remove "upgrade" from the sentence)?

That's odd. I made exactly that change in the second draft but it
somehow switched back in the third. I'd better review all second draft
changes tomorrow and make sure they're in the current draft as intended.

> > New and changed privilege escalation mechanisms
>
> Is the bureaucracy in this section really necessary? AFAICT what was missing
> when the F12 PackageKit change was made was the informative part of the
> proposal, the maintainer just didn't know what he should be allowing and
> what not. I don't think the enforcement part is really needed, maintainers
> should be able to get it right on their own given the detailed list of evil
> things to avoid which the proposal provides and I haven't seen any evidence
> as to the contrary (again, the PackageKit example is not applicable because
> the PackageKit maintainer did NOT have such a list to go by when he made his
> change; there's no reason to believe he'd have made that change in spite of
> it).

I think it's sensible, yeah. It's not really much bureaucracy; I don't
think it would ever be a good idea to introduce a new privilege
escalation mechanism without FESco knowing about it...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

Adam Williamson wrote:
> I think it's sensible, yeah. It's not really much bureaucracy; I don't
> think it would ever be a good idea to introduce a new privilege
> escalation mechanism without FESco knowing about it...

Right now we're in a phase where a lot of stuff (system-config-*, several
parts of KDE and some other stuff) is getting ported from running the whole
app under consolehelper or kdesu to PolicyKit mechanisms. This is generally
seen as a *good* thing. It'd be really annoying to have to go through a
FESCo vote for every single one of those.

At the very least, I'd suggest adding the following clause to that
paragraph:
"Any mechanism which requires administrative authentication to perform the
privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a
privilege escalation mechanism for the purposes of this paragraph."

Rationale: Such a policy does not impact the system's security as you have
to enter the root password before doing anything dangerous, so none of the
invariants under "Requirements" can be violated. And additionally, you can
always as a user run the whole app under e.g. kdesu and thus "escalate your
privileges" using the root password, so it doesn't make sense to police apps
providing such a mechanism. What really matters for security is what you can
do WITHOUT the root password. This is not really clear from the policy as
written now, adding the suggested sentence would clarify it.

(That said, I don't see even the clarified policy as being necessary. We
have a set of guidelines, maintainers should follow them, why do we have to
police them? As I explained before, there is no evidence that this is
necessary or useful. The PackageKit issue was caused by lack of a policy,
not lack of enforcement.)

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Draft privilege escalation policy for comments
 

Kevin Kofler pÃ*Å¡e v Ne 31. 01. 2010 v 08:55 +0100:
> Adam Williamson wrote:
> > I think it's sensible, yeah. It's not really much bureaucracy; I don't
> > think it would ever be a good idea to introduce a new privilege
> > escalation mechanism without FESco knowing about it...
>
> Right now we're in a phase where a lot of stuff (system-config-*, several
> parts of KDE and some other stuff) is getting ported from running the whole
> app under consolehelper or kdesu to PolicyKit mechanisms. This is generally
> seen as a *good* thing. It'd be really annoying to have to go through a
> FESCo vote for every single one of those.
That's not the intent: "mechanism" is "the code that causes running
something as root", in this case DBus activation, not "the code running
as root" (a DBus server).

You are not required to announce / ask for approval of every new DBus
server - but if you want to introduce another program that allows
running something as root (new DBus, new sudo, ...), _that_ requires
approval / announcement of changes.

The purpose of these announcements is to allow the QA team and people
working on Fedora security to maintain a list of such mechanisms. If
the QA team or someone working on security knows there is userhelper or
DBus, they can search for packages that use it, and check the
configuration of the packages, do code reviews etc. If they don't know
about the mechanism, they can't check the users of the mechanism are
secure.
Mirek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel