src/sys/security/mac/mac_framework.c, branch releng/8.1

Mark MAC Framework sx and rm locks as NOWITNESS to suppress warnings that

2009-06-02T22:22:09Z

might arise from WITNESS not understanding its locking protocol, which should be deadlock-free. Currently these warnings generally don't occur, but as object locking is pushed into policies for some object types, they would otherwise occur more often. Obtained from: TrustedBSD Project

Add internal 'mac_policy_count' counter to the MAC Framework, which is a

2009-06-02T18:26:17Z

count of the number of registered policies. Rather than unconditionally locking sockets before passing them into MAC, lock them in the MAC entry points only if mac_policy_count is non-zero. This avoids locking overhead for a number of socket system calls when no policies are registered, eliminating measurable overhead for the MAC Framework for the socket subsystem when there are no active policies. Possibly socket locks should be acquired by policies if they are required for socket labels, which would further avoid locking overhead when there are policies but they don't require labeling of sockets, or possibly don't even implement socket controls. Obtained from: TrustedBSD Project

Make the rmlock(9) interface a bit more like the rwlock(9) interface:

2009-05-29T10:52:37Z

- Add rm_init_flags() and accept extended options only for that variation. - Add a flags space specifically for rm_init_flags(), rather than borrowing the lock_init() flag space. - Define flag RM_RECURSE to use instead of LO_RECURSABLE. - Define flag RM_NOWITNESS to allow an rmlock to be exempt from WITNESS checking; this wasn't possible previously as rm_init() always passed LO_WITNESS when initializing an rmlock's struct lock. - Add RM_SYSINIT_FLAGS(). - Rename embedded mutex in rmlocks to make it more obvious what it is. - Update consumers. - Update man page.

Convert the MAC Framework from using rwlocks to rmlocks to stabilize

2009-05-27T09:41:58Z

framework registration for non-sleepable entry points. Obtained from: TrustedBSD Project

Rework MAC Framework synchronization in a number of ways in order to

2009-03-14T16:06:06Z

improve performance: - Eliminate custom reference count and condition variable to monitor threads entering the framework, as this had both significant overhead and behaved badly in the face of contention. - Replace reference count with two locks: an rwlock and an sx lock, which will be read-acquired by threads entering the framework depending on whether a give policy entry point is permitted to sleep or not. - Replace previous mutex locking of the reference count for exclusive access with write acquiring of both the policy list sx and rw locks, which occurs only when policies are attached or detached. - Do a lockless read of the dynamic policy list head before acquiring any locks in order to reduce overhead when no dynamic policies are loaded; this a race we can afford to lose. - For every policy entry point invocation, decide whether sleeping is permitted, and if not, use a _NOSLEEP() variant of the composition macros, which will use the rwlock instead of the sxlock. In some cases, we decide which to use based on allocation flags passed to the MAC Framework entry point. As with the move to rwlocks/rmlocks in pfil, this may trigger witness warnings, but these should (generally) be false positives as all acquisition of the locks is for read with two very narrow exceptions for policy load/unload, and those code blocks should never acquire other locks. Sponsored by: Google, Inc. Obtained from: TrustedBSD Project Discussed with: csjp (idea, not specific patch)

Improve the consistency of MAC Framework and MAC policy entry point

2009-03-08T10:58:37Z

naming by renaming certain "proc" entry points to "cred" entry points, reflecting their manipulation of credentials. For some entry points, the process was passed into the framework but not into policies; in these cases, stop passing in the process since we don't need it. mac_proc_check_setaudit -> mac_cred_check_setaudit mac_proc_check_setaudit_addr -> mac_cred_check_setaudit_addr mac_proc_check_setauid -> mac_cred_check_setauid mac_proc_check_setegid -> mac_cred_check_setegid mac_proc_check_seteuid -> mac_cred_check_seteuid mac_proc_check_setgid -> mac_cred_check_setgid mac_proc_check_setgroups -> mac_cred_ceck_setgroups mac_proc_check_setregid -> mac_cred_check_setregid mac_proc_check_setresgid -> mac_cred_check_setresgid mac_proc_check_setresuid -> mac_cred_check_setresuid mac_proc_check_setreuid -> mac_cred_check_setreuid mac_proc_check_setuid -> mac_cred_check_setuid Obtained from: TrustedBSD Project Sponsored by: Google, Inc.

Add static DTrace probes for MAC Framework access control checks and

2009-03-08T00:50:37Z

privilege grants so that dtrace can be more easily used to monitor the security decisions being generated by the MAC Framework following policy invocation. Successful access control checks will be reported by: mac_framework:kernel::mac_check_ok Failed access control checks will be reported by: mac_framework:kernel::mac_check_err Successful privilege grants will be reported by: mac_framework:kernel:priv_grant:mac_grant_ok Failed privilege grants will be reported by: mac_framework:kernel:priv_grant:mac_grant_err In all cases, the return value (always 0 for _ok, otherwise an errno for _err) will be reported via arg0 on the probe, and subsequent arguments will hold entrypoint-specific data, in a style similar to privilege tracing. Obtained from: TrustedBSD Project Sponsored by: Google, Inc.

Reduce the verbosity of SDT trace points for DTrace by defining several

2009-03-03T17:15:05Z

wrapper macros that allow trace points and arguments to be declared using a single macro rather than several. This means a lot less repetition and vertical space for each trace point. Use these macros when defining privilege and MAC Framework trace points. Reviewed by: jb MFC after: 1 week

Begin to add SDT tracing of the MAC Framework: add policy modevent,

2009-01-24T10:57:32Z

register, and unregister hooks that give access to the mac_policy_conf for the policy. Obtained from: TrustedBSD Project MFC after: 3 days

Rather than having MAC policies explicitly declare what object types

2009-01-10T10:58:41Z

they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine Obtained from: TrustedBSD Project Sponsored by: Apple, Inc.