Privilege escalation policy

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 administrative 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
• udev rules
• D-Bus services on the system bus

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 an unprivileged user account to perform, or cause to be performed, certain actions must require administrative authentication prior to the action being carried out. For some actions, the 'cause to be performed' provision is waived: this means that code causing this action to be performed is acceptable, only allowing the user to perform the action directly is unacceptable.

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 same applies to any user account subsequently granted those privileges by the system administrator.

The actions are:

• Add, remove, or downgrade any system-wide application or shared resource (packaged or otherwise)
• Perform an upgrade to a newer Fedora release
• Directly read or write to or from system memory ('cause to be performed' provision waived)
• Load or unload kernel modules (with the exceptions of automatic loading of appropriate modules for hotplugged hardware managed via the module-init-tools system, and automatic loading of appropriate modules on mounting of a filesystem)
• Start or stop system daemons (excluding services intended to start and stop on demand)
• Edit system-wide configuration files
• Access any other user's home directories (unless explicitly granted permission by the user)
• Allow a user to directly access or modify a file they would usually be denied rights to access or modify via standard system permissions (e.g. file access permissions or SELinux restrictions)
• 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 (with the exception of /var/run/utmp and /var/log/wtmp)
• Remove, rename, or overwrite the contents of system log files
• Directly write a file anywhere other than their home directory, /dev/shm, /tmp, /usr/tmp or /var/tmp, or a removable storage device (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 ('cause to be performed' provision waived)
• Make any change to the system's network configuration

The term 'system-wide' means that the resource in question would be used by any other user or system process.

Enforcement

The QA team will check packages known to be capable of privilege escalation for their compliance with this policy, both through manual examination and automated testing via the AutoQA project.

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 steering committee. New or changed configuration for the use of an existing privilege escalation mechanism does not require this special review. 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.