midnight
So here's the third draft of the privesc policy. I've tried to address
all previous comments that could be worked in, including some from the
Red Hat security list for which I'm indebted to Miloslav Trmac.
Specifically, I tried to make it clearer that we're not _only_ talking
about passing the root password here, and mechanisms like sudo and the
proposed PolicyKit system with the first user being granted admin
privileges are OK. I added two sections from Miloslav - an overall
definition of what the policy is trying to implement, and a procedure
for handling new privilege escalation mechanisms - virtually unaltered.
---
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. The fundamental
principles this policy tries to enforce can be outlined as follows:
An unprivileged user without administrative authentication must not be
able to change the behavior of the system "as a whole" (as viewed by
other users or by network clients), unless the system behavior is
intended to be dependent on the actions of the unprivileged user.
An unprivileged user without administrative authentication must not be
able to bypass or override other users' reasonable expectation of
privacy of their data, where "reasonable" is limited by what computers
can do, what Linux can express, AND explicit actions by the "other user"
to configure access permissions.
== 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 administrative
authentication prior to the action being carried out. Authentication via
provision of the root password always counts as administrative
authentication. In the case of mechanisms such as sudo which allow
authentication with a user's own password to grant root privileges, this
form of authentication can be considered administrative authentication
when so configured by the system administrator. In the case of an
approved Fedora spin which automatically grants administrative
privileges to the first created user account, authentication as that
user can be considered administrative authentication. 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
* Remove, rename, or overwrite the contents of system log files
* 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 any local internal storage device
* Directly interact with an X server instance or sound server instance
owned by any other user (with the provision that authentication as the
user in question, rather than root, would suffice in this case)
* Directly monitor or manipulate traffic on a network interface
The term 'system-wide' means that the resource in question would be used
by any other user or system process.
== New and changed privilege escalation mechanisms ==
Any new privilege escalation mechanisms (where mechanism is defined as
"the code that directly causes privilege escalation") must be submitted
to, and approved by, the Fedora packaging committee. The development and
QA mailing lists must be notified of the approval of new privilege
escalation mechanisms. Any significant changes to the semantics of
existing privilege escalation mechanisms (except for changes that are
obviously not security-relevant) must be announced to the development
and QA mailing lists.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net