Date: Thu, 4 May 2000 10:32:06 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-arch@FreeBSD.org Cc: trustedbsd-discuss@TrustedBSD.org Subject: Proposed changes to suser() Message-ID: <Pine.NEB.3.96L.1000504101844.34694A-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
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@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@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000504101844.34694A-100000>