On Tue, 2010-01-26 at 11:59 -0800, Adam Williamson wrote: > On Tue, 2010-01-26 at 11:50 -0600, Jason L Tibbitts III wrote: > > >>>>> "MC" == Matthias Clasen <mclasen@xxxxxxxxxx> writes: > > > > MC> Not to sound disrespectful, but why should the packaging committee > > MC> have and special say in privilege escalation mechanisms ? > > > > I have to agree; FPC members are not generally security experts. > > There > > used to be some sort of security team, but I'm not sure what happened > > to > > it. It's probably best to send to FESCo and let them delegate if they > > wish. > > Whoops - that was just a typo. Will adjust. Thanks. Okay, here's the fourth draft. It's literally a one-word change from third draft to fix this think-o. As people are no longer saying this is completely insane, I'll take this to a wider audience - devel-list - tomorrow, and hopefully to FESco next week. Do yell if you think something urgently needs to be changed before then. 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. 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 steering 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
