On Tue, 2010-01-19 at 19:15 -0800, Adam Williamson wrote: > 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. Here's a second draft, addressing several (not yet all) of the concerns raised about the first. 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 an unprivileged user account to perform, or cause to be performed, certain actions must require authentication as the root user prior to the action being carried out. The policy does not apply in the case of user accounts which have been explicitly granted privileges by the system administrator, but no code should allow such a user to exceed the specific privileges granted. 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 * 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 (excluding services intended to start and stop on demand) * Edit system-wide configuration files * Access other users home directories (unless explicitly granted permission by another 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 * 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. == 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
