Proposed changes to suser()

[Robert Watson]

The purpose of this message is to identify some proposed changes from the
TrustedBSD implementation that I'd like to commit to the FreeBSD source
tree.  As such, I'm sending this email to freebsd-arch, but CC'ing to
trustedbsd-discuss.

Currently, the FreeBSD process accounting mechanism provides a number of
process flags, including the flag ASU.  ASU is set when a process
performs a ``super-user activity'' -- i.e., invokes privilege to access a
file not normally permitted by permission checks, modifies privileged
kernel objects (network configuration, ...), signals processes, et al.

As part of the least-privilege POSIX.1e Capabilities support, there are
now new ways to invoke privilege: calls not unlike suser() and suser_xxx()
exist to check for specific capabilities -- cap_check() and
cap_check_xxx().  This introduces a problem, as currently the ASU bit is
set in suser_xxx() as the result of a successful call.  The nature of the
problem is actually fairly serious: ASU is currently set as the result of
an access control check, and not as a result of the actual use of
privilege.  The current source base goes to enourmous trouble to avoid
invoking suser() if the result could be an incorrectly set ASU bit.  For
example, in file system code where multiple access checks must occur
(i.e., super-user privilege might be checked more than once), some of the
checks are done by a direct uid==0 check.  For example, this occurs in
ufs_access() during file flag modification.

As such, the problem is relevant even in the base source tree without new
authorization mechanisms, but becomes particular relevant with such
changes.  The problem also becomes relevant once you throw fine-grained
auditing into the picture: it's useful to be able to tell when any
individual call succeeds as a result of privilege being invoked.

To solve these problems, I'm currently working with a somewhat modified
framework: the simple aspect is that suser_xxx() no longer sets the ASU
bit, as with the cap_check_xxx() call.  There's a new suser_used() call
whose only action is to set the ASU bit for the process passed.  These
changes mean that all locations in the code where suser() is currently
called need to be restructured to monitor the use of privilege, and then
audit it at the end of their activity.  Not surprisingly, this actually
cleans up a number of pieces of code that currently are fairly unreadable
as a result of the attempts not to use suser().  It also means that a
number of suser() wrapper calls have to be updated to indicate whether
privilege was used: for example, the checks used to determine if p1 can
signal p2 all perform uid checks, and then suser checks.  They must now be
modified to return a privilege invoked variable to the caller for the
purposes of the caller auditing use of privilege.

In the future, we have plans to introduce a more general authorization
framework, but this is still in the design stages.  In the mean time,
these suser() changes have the benefits of: cleaning up invocation of
suser() code, allowing removal of many of the remaining uid==0 checks in
the kernel, seperating authorization checks and monitoring of least
privilege, and directly facilitating importing of capabilities support.

I'd like to commit these patches in several phases.  First, I'll commit
the suser_used() code.  Then I will restructure several access checks to
make use of suser_used() resulting in redundant setting of the ASU bit (as
well as temporarily gratuitously setting ASU in some situations).
Finally, I will disable the ASU behavior in suser().

I'd like to integrate these changes slowly and with maximal inspection, as
they will change security-sensitive access-control checks in a variety of
kernel components: it is important that while introducing infrastructure
for security improvements that we don't open up security holes.

Patches for these changes will be available shortly.  I am still catching
the last few suser() calls.  Third party modules making use of the suser()
call will need to be changed to set ASU properly.

Any comments?

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message