Initial draft of privilege escalation policy

[Stephen John Smoogen]

On Wed, Jan 20, 2010 at 7:09 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> 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.
>>
>> I have come up with a very initial draft of one now, with considerable
>> debt to Spot's blog post - http://spot.livejournal.com/312216.html . It
>> basically *is* the list from spot's post, slightly rewritten and with a
>> bit of preamble.
>>
>> Things to consider: overall, does this layout seem sane? We want to keep
>> it reasonably simple and manageable for now. I realize that we really
>> ought to cover lots of over things. I also realize that this policy is
>> really the wrong way around; it should say what is allowed, not what's
>> not allowed. But that's way way harder and would be extremely difficult
>> to do in a reasonable timeframe. A policy that defines some of the
>> clearly known no-nos for us to check on is a significant but manageable
>> step.
>>
>> Are there any other things that should be added to the list?
>>
>> Other sections: I considered having a 'suggested compliance' section,
>> which would explain the preferred way of implementing authorization
>> (PolicyKit), and an 'enforcement' section, which would outline that QA
>> will test for compliance with the policy. But I'm not sure if they'd be
>> appropriate. What does everyone think?
>>
>> 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.
>>
>> == 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 authentication as
>> the root user prior to the action being carried out. The actions are:
>
> This does not seem right. While we want a standard, unprivileged user to
> not be able to do these things, we very much want to define an
> 'Administrator' role that can be assigned to users other than root and
> that will enable them to do many of these things by just authenticating
> as themselves, not as root.
>
> The policy should be worded in a way that makes it clear that this is
> allowed.
>

The first thing to do is realize that writing policy usually ends up
with lawerly tomes because people like us like to find every possible
problem which usually is due to the limitations of the English (or any
language) to adequately cover everything. I think we should look at
the list as a set of guidelines that cover the normal expectations of
the non-root Unix user and what they  can do.

There are many classes of users:
1) The root user
2) The user with physical access who in most cases might as well be root.
3) The remote user with priviledges
4) The remote user without priviledges
5) Start your long list of cases where people do not fit into the above 4...

In the end there are really 2 types of users: root and non-root. If
you have administrative access in any form you are root. This policy
is for the other case.

>> * Add, remove, upgrade or downgrade any system-wide application or
>> shared resource (packaged or otherwise)
>
> I don't see how a Fedora policy can apply to non-packaged resources;
> other than the fact that those resources will be subject to normal
> access control (e.g. file permissions).

This is to cover the case of the user clicking on packagekit and being
able to update or install stuff without administrative priviledges.

>> * Read or write directly to or from system memory (with the exception
>> that the 'cause to be performed' provision is waived in this case)
>
> This seems entirely too vague to make sense. What does 'system memory'
> mean here ?

For the case of most Unix documents this means /proc/kmem, /dev/mem
etc. The ability to look at any point of memory no matter where it is.

>> * 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
>
> With the exception of daemons that are autostarted D-Bus system bus
> services...

Are those system daemons or user daemons? They would be system daemons
if they are started with a different UID of the user. In this case,
their starting and stopping would need to be detailed as either using
setuid process or an over daemon (or kernel mode) that is listening to
such requests and starting them for the user (eg xinetd).

>> * Edit system-wide configuration files
>
> Seems clear enough on the face of it, but is /etc/passwd a system-wide
> configuration file ? Users do edit that by changing e.g. their password.

That is done through an indirect and controlled method. The user does
not have the ability to change any other users password etc.

>> * 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)
>
> Again, I'd like this to be worded in a way that does not interfere with
> us introducing e.g. parental controls for supervised accounts.

The person doing something like that is an administrative user and not
a normal user. They are root and thus can do anything they damn well
please.

>> * 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)
>
> Huh ? The mere fact of me logging in will cause system logs to be
> written...

You are not writing directly to /var/log/messages. You log in and
login sends a message to syslogd which writes to the log. This is
following a controlled path.. A user could use a program to spam
syslogd but the user is not directly writing to files outside of its
DAC.

>> * 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)
>
> Another explicit mention of root that would better be replaced by 'a
> privileged user'.

See above.

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




-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning