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
5:52 a.m.
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 :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:09 a.m.
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.
11:50 a.m.
>>>> "MC" == Matthias Clasen
<mclasen(a)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<
1:59 p.m.
On Tue, 2010-01-26 at 11:50 -0600, Jason L Tibbitts III wrote:
>>>>> "MC" == Matthias Clasen
<mclasen(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:32 p.m.
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(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:41 p.m.
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.
1:57 p.m.
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!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:22 p.m.
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...
4:37 p.m.
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
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5211
days inactive
5214
days old
10 comments
4 participants
participants (4)
-
Adam Williamson -
Jason L Tibbitts III -
Matthias Clasen -
Tim Waugh