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.
On Tue, 2010-01-26 at 10:07 +0000, Tim Waugh wrote:
On Mon, 2010-01-25 at 22:00 -0800, Adam Williamson wrote:
The fundamental principles this policy tries to enforce can be outlined as follows:
Thank you -- for me, this was the missing piece.
That was one of the bits that came from Miloslav, so thank him, not me :)
On Mon, 2010-01-25 at 22:00 -0800, Adam Williamson wrote:
== 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.
Not to sound disrespectful, but why should the packaging committee have and special say in privilege escalation mechanisms ? How does a special interest in spec file syntax qualify for security audits ?
I propose to s/packaging committee/FESCo/ there.
"MC" == Matthias Clasen mclasen@redhat.com 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.
- J<
On Tue, 2010-01-26 at 11:50 -0600, Jason L Tibbitts III wrote:
"MC" == Matthias Clasen mclasen@redhat.com 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.
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@redhat.com 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.
On Thu, 2010-01-28 at 16:32 -0800, Adam Williamson wrote:
Do yell if you think something urgently needs to be changed before then. Thanks!
Here is something that just came up internally, and that would probably be a worthwhile addition to your list of 'things to watch out for':
Access control to devices is nowadays largely controlled by udev rules, and a package installing a bad set of rules can easily make a large chunk of your devices world-readable. 'udev rules' should be on the list of things to review.
On Fri, 2010-01-29 at 13:41 -0500, Matthias Clasen wrote:
On Thu, 2010-01-28 at 16:32 -0800, Adam Williamson wrote:
Do yell if you think something urgently needs to be changed before then. Thanks!
Here is something that just came up internally, and that would probably be a worthwhile addition to your list of 'things to watch out for':
Access control to devices is nowadays largely controlled by udev rules, and a package installing a bad set of rules can easily make a large chunk of your devices world-readable. 'udev rules' should be on the list of things to review.
That seems like an implementation-of-policy-compliance-testing issue and not something that needs explicitly mentioning in the policy. But indeed it's a useful note: changes in udev rules should be something rpmguard looks for and something the security testing procedures cover. thanks!
On Fri, 2010-01-29 at 11:57 -0800, Adam Williamson wrote:
On Fri, 2010-01-29 at 13:41 -0500, Matthias Clasen wrote:
On Thu, 2010-01-28 at 16:32 -0800, Adam Williamson wrote:
Do yell if you think something urgently needs to be changed before then. Thanks!
Here is something that just came up internally, and that would probably be a worthwhile addition to your list of 'things to watch out for':
Access control to devices is nowadays largely controlled by udev rules, and a package installing a bad set of rules can easily make a large chunk of your devices world-readable. 'udev rules' should be on the list of things to review.
That seems like an implementation-of-policy-compliance-testing issue and not something that needs explicitly mentioning in the policy. But indeed it's a useful note: changes in udev rules should be something rpmguard looks for and something the security testing procedures cover. thanks!
I was thinking of this list:
In practice, packages which provide one or more of:
* setuid binaries * PolicyKit policies * consolehelper configurations
are likely to be affected by this policy [...]
I was suggesting to add udev rules to that list. Seems just as much an implementation detail as consolehelper configuration...
On Fri, 2010-01-29 at 17:22 -0500, Matthias Clasen wrote:
I was thinking of this list:
In practice, packages which provide one or more of:
- setuid binaries
- PolicyKit policies
- consolehelper configurations
are likely to be affected by this policy [...]
I was suggesting to add udev rules to that list. Seems just as much an implementation detail as consolehelper configuration...
Ah, you're quite right, I'm forgetting my own writing. :) Will add it. Thanks.
-
Adam Williamson -
Jason L Tibbitts III -
Matthias Clasen -
Tim Waugh