Initial draft of privilege escalation policy

[Adam Williamson]

Hi, everyone. As you may know if you've followed the meetings, FESCo has
cheerfully punted the privilege escalation policy issue back to us; they
want us to come up with a draft policy to take back to a FESCo meeting.

I have come up with a very initial draft of one now, with considerable
debt to Spot's blog post - http://spot.livejournal.com/312216.html . It
basically *is* the list from spot's post, slightly rewritten and with a
bit of preamble.

Things to consider: overall, does this layout seem sane? We want to keep
it reasonably simple and manageable for now. I realize that we really
ought to cover lots of over things. I also realize that this policy is
really the wrong way around; it should say what is allowed, not what's
not allowed. But that's way way harder and would be extremely difficult
to do in a reasonable timeframe. A policy that defines some of the
clearly known no-nos for us to check on is a significant but manageable
step.

Are there any other things that should be added to the list?

Other sections: I considered having a 'suggested compliance' section,
which would explain the preferred way of implementing authorization
(PolicyKit), and an 'enforcement' section, which would outline that QA
will test for compliance with the policy. But I'm not sure if they'd be
appropriate. What does everyone think?

Thanks!

--------------

Privilege Escalation Policy (draft)

== Scope ==

This policy aims to provide a consistent policy for how Fedora packages
should handle privilege escalation. At present it defines certain
privileged operations which must require root authentication to be
performed, or caused to be performed, interactively.

== Impact ==

This policy applies to any code which can allow a user to perform
privileged operations interactively. If the code in a package runs
entirely with privileges equal to or lower than a standard user account,
or has no facility for user interaction, this policy is unlikely to
apply to it. In practice, packages which provide one or more of:

* setuid binaries
* PolicyKit policies
* consolehelper configurations

are likely to be affected by this policy, and their maintainers should
ensure that they comply with it.

== Requirements ==

The policy requires that any code which allows a user to perform, or
cause to be performed, certain actions must require authentication as
the root user prior to the action being carried out. The actions are:

* Add, remove, upgrade or downgrade any system-wide application or
shared resource (packaged or otherwise)
* Read or write directly to or from system memory (with the exception
that the 'cause to be performed' provision is waived in this case)
* Load or unload kernel modules (with the exception of automatic loading
of appropriate modules for hotplugged hardware, managed via the
module-init-tools system)
* Start or stop system daemons
* Edit system-wide configuration files
* Access other users home directories (unless explicitly granted
permission by another user)
* Change any configuration of any other user's account, or view any
other user's password (with the provision that authentication as the
user in question, rather than root, would suffice in this case)
* Add or remove user accounts
* Change the system clock
* Shutdown or reboot the system (unless they are the only user logged
in, and they are logged in locally)
* Read from system logs containing any information about user activities
* Write to system logs (with the exception that the 'cause to be
performed' provision is waived in this case)
* Write a file anywhere other than their home directory, /tmp, /var/tmp
or /usr/tmp (with the exceptions that the 'cause to be performed'
provision is waived in this case, and authentication as another user is
sufficient for writing to that user's home directory)
* Load or modify PolicyKit or SELinux policies
* Change SELinux enforcement levels
* Change or disable firewall settings
* Run an application that listens on a network port lower than 1024
* Mount or unmount anything (excluding automounted hotplugged storage
devices, and devices explicitly configured by the root user for
unprivileged use)

The term 'system-wide' means that the resource in question would be used
by any other user or system process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net