Commit Graph

10 Commits

Author SHA1 Message Date
Attilio Rao
54366c0bd7 - For kernel compiled only with KDTRACE_HOOKS and not any lock debugging
option, unbreak the lock tracing release semantic by embedding
  calls to LOCKSTAT_PROFILE_RELEASE_LOCK() direclty in the inlined
  version of the releasing functions for mutex, rwlock and sxlock.
  Failing to do so skips the lockstat_probe_func invokation for
  unlocking.
- As part of the LOCKSTAT support is inlined in mutex operation, for
  kernel compiled without lock debugging options, potentially every
  consumer must be compiled including opt_kdtrace.h.
  Fix this by moving KDTRACE_HOOKS into opt_global.h and remove the
  dependency by opt_kdtrace.h for all files, as now only KDTRACE_FRAMES
  is linked there and it is only used as a compile-time stub [0].

[0] immediately shows some new bug as DTRACE-derived support for debug
in sfxge is broken and it was never really tested.  As it was not
including correctly opt_kdtrace.h before it was never enabled so it
was kept broken for a while.  Fix this by using a protection stub,
leaving sfxge driver authors the responsibility for fixing it
appropriately [1].

Sponsored by:	EMC / Isilon storage division
Discussed with:	rstone
[0] Reported by:	rstone
[1] Discussed with:	philip
2013-11-25 07:38:45 +00:00
Attilio Rao
77befd1d23 Revert the approach for skipping lockstat_probe_func call when doing
lock_success/lock_failure, introduced in r228424, by directly skipping
in dtrace_probe.

This mainly helps in avoiding namespace pollution and thus lockstat.h
dependency by systm.h.

As an added bonus, this also helps in MFC case.
Reviewed by:	avg
MFC after:	3 months (or never)
X-MFC:		r228424
2011-12-12 23:29:32 +00:00
Andriy Gapon
7a7ce668ef put sys/systm.h at its proper place or add it if missing
Reported by:	lstewart, tinderbox
Pointyhat to:	avg, attilio
MFC after:	1 week
MFC with:	r228430
2011-12-12 10:05:13 +00:00
Robert Watson
fa76567150 Rename MAC Framework-internal macros used to invoke policy entry points:
MAC_BOOLEAN           -> MAC_POLICY_BOOLEAN
  MAC_BOOLEAN_NOSLEEP   -> MAC_POLICY_BOOLEANN_NOSLEEP
  MAC_CHECK             -> MAC_POLICY_CHECK
  MAC_CHECK_NOSLEEP     -> MAC_POLICY_CHECK_NOSLEEP
  MAC_EXTERNALIZE       -> MAC_POLICY_EXTERNALIZE
  MAC_GRANT             -> MAC_POLICY_GRANT
  MAC_GRANT_NOSLEEP     -> MAC_POLICY_GRANT_NOSLEEP
  MAC_INTERNALIZE       -> MAC_POLICY_INTERNALIZE
  MAC_PERFORM           -> MAC_POLICY_PERFORM_CHECK
  MAC_PERFORM_NOSLEEP   -> MAC_POLICY_PERFORM_NOSLEEP

This frees up those macro names for use in wrapping calls into the MAC
Framework from the remainder of the kernel.

Obtained from:	TrustedBSD Project
2009-05-01 21:05:40 +00:00
Robert Watson
4020272933 Rework MAC Framework synchronization in a number of ways in order to
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)
2009-03-14 16:06:06 +00:00
Robert Watson
2087a58ca2 Add static DTrace probes for MAC Framework access control checks and
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:<entrypoint>:mac_check_ok

Failed access control checks will be reported by:

  mac_framework:kernel:<entrypoint>: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.
2009-03-08 00:50:37 +00:00
Robert Watson
c7ed8c0a85 Use __FBSDID() for $FreeBSD$ version strings in .c files.
Obtained from:	TrustedBSD Project
MFC after:	3 days
2009-01-24 13:15:45 +00:00
Robert Watson
0efd6615cd Move src/sys/sys/mac_policy.h, the kernel interface between the MAC
Framework and security modules, to src/sys/security/mac/mac_policy.h,
completing the removal of kernel-only MAC Framework include files from
src/sys/sys.  Update the MAC Framework and MAC policy modules.  Delete
the old mac_policy.h.

Third party policy modules will need similar updating.

Obtained from:	TrustedBSD Project
2006-12-22 23:34:47 +00:00
Robert Watson
23c3d46ae8 Additional comments regarding the interaction between the kernel privilege
model and the MAC Framework.

Obtained from:	TrustedBSD Project
2006-12-20 23:15:27 +00:00
Robert Watson
800c940832 Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials.  Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed.  Two interfaces are provided, replacing the
existing suser(9) interface:

suser(td)                 ->   priv_check(td, priv)
suser_cred(cred, flags)   ->   priv_check_cred(cred, priv, flags)

A comprehensive list of currently available kernel privileges may be
found in priv.h.  New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.

The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag.  For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail.  As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.

The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.

The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated.  The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.

This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.

Sponsored by:		nCircle Network Security, Inc.
Obtained from:		TrustedBSD Project
Discussed on:		arch@
Reviewed (at least in part) by:	mlaier, jmg, pjd, bde, ceri,
			Alex Lyashkov <umka at sevcity dot net>,
			Skip Ford <skip dot ford at verizon dot net>,
			Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00