Commit Graph

21 Commits

Author SHA1 Message Date
Robert Watson
6356dba0b4 Introduce two related changes to the TrustedBSD MAC Framework:
(1) Abstract interpreter vnode labeling in execve(2) and mac_execve(2)
    so that the general exec code isn't aware of the details of
    allocating, copying, and freeing labels, rather, simply passes in
    a void pointer to start and stop functions that will be used by
    the framework.  This change will be MFC'd.

(2) Introduce a new flags field to the MAC_POLICY_SET(9) interface
    allowing policies to declare which types of objects require label
    allocation, initialization, and destruction, and define a set of
    flags covering various supported object types (MPC_OBJECT_PROC,
    MPC_OBJECT_VNODE, MPC_OBJECT_INPCB, ...).  This change reduces the
    overhead of compiling the MAC Framework into the kernel if policies
    aren't loaded, or if policies require labels on only a small number
    or even no object types.  Each time a policy is loaded or unloaded,
    we recalculate a mask of labeled object types across all policies
    present in the system.  Eliminate MAC_ALWAYS_LABEL_MBUF option as it
    is no longer required.

MFC after:	1 week ((1) only)
Reviewed by:	csjp
Obtained from:	TrustedBSD Project
Sponsored by:	Apple, Inc.
2008-08-23 15:26:36 +00:00
Robert Watson
37f44cb428 The TrustedBSD MAC Framework named struct ipq instances 'ipq', which is the
same as the global variable defined in ip_input.c.  Instead, adopt the name
'q' as found in about 1/2 of uses in ip_input.c, preventing a collision on
the name.  This is non-harmful, but means that search and replace on the
global works less well (as in the virtualization work), as well as indexing
tools.

MFC after:	1 week
Reported by:	julian
2008-06-13 22:14:15 +00:00
Christian S.J. Peron
1f84ab0f2a Plug a memory leak which can occur when multiple MAC policies are loaded
which label mbufs.  This leak can occur if one policy successfully allocates
label storage and subsequent allocations from other policies fail.

Spotted by:	rwatson
MFC after:	1 week
2008-05-27 14:18:02 +00:00
Robert Watson
211b72ad2f When propagating a MAC label from an inpcb to an mbuf, allow read and
write locks on the inpcb, not just write locks.

MFC after:	3 months
2008-04-19 18:35:27 +00:00
Robert Watson
8501a69cc9 Convert pcbinfo and inpcb mutexes to rwlocks, and modify macros to
explicitly select write locking for all use of the inpcb mutex.
Update some pcbinfo lock assertions to assert locked rather than
write-locked, although in practice almost all uses of the pcbinfo
rwlock main exclusive, and all instances of inpcb lock acquisition
are exclusive.

This change should introduce (ideally) little functional change.
However, it lays the groundwork for significantly increased
parallelism in the TCP/IP code.

MFC after:	3 months
Tested by:	kris (superset of committered patch)
2008-04-17 21:38:18 +00:00
Robert Watson
a13e21f7bc Continue to move from generic network entry points in the TrustedBSD MAC
Framework by moving from mac_mbuf_create_netlayer() to more specific
entry points for specific network services:

- mac_netinet_firewall_reply() to be used when replying to in-bound TCP
  segments in pf and ipfw (etc).

- Rename mac_netinet_icmp_reply() to mac_netinet_icmp_replyinplace() and
  add mac_netinet_icmp_reply(), reflecting that in some cases we overwrite
  a label in place, but in others we apply the label to a new mbuf.

Obtained from:	TrustedBSD Project
2007-10-28 17:12:48 +00:00
Robert Watson
b9b0dac33b Move towards more explicit support for various network protocol stacks
in the TrustedBSD MAC Framework:

- Add mac_atalk.c and add explicit entry point mac_netatalk_aarp_send()
  for AARP packet labeling, rather than using a generic link layer
  entry point.

- Add mac_inet6.c and add explicit entry point mac_netinet6_nd6_send()
  for ND6 packet labeling, rather than using a generic link layer entry
  point.

- Add expliict entry point mac_netinet_arp_send() for ARP packet
  labeling, and mac_netinet_igmp_send() for IGMP packet labeling,
  rather than using a generic link layer entry point.

- Remove previous genering link layer entry point,
  mac_mbuf_create_linklayer() as it is no longer used.

- Add implementations of new entry points to various policies, largely
  by replicating the existing link layer entry point for them; remove
  old link layer entry point implementation.

- Make MAC_IFNET_LOCK(), MAC_IFNET_UNLOCK(), and mac_ifnet_mtx global
  to the MAC Framework rather than static to mac_net.c as it is now
  needed outside of mac_net.c.

Obtained from:	TrustedBSD Project
2007-10-28 15:55:23 +00:00
Robert Watson
8640764682 Rename 'mac_mbuf_create_from_firewall' to 'mac_netinet_firewall_send' as
we move towards netinet as a pseudo-object for the MAC Framework.

Rename 'mac_create_mbuf_linklayer' to 'mac_mbuf_create_linklayer' to
reflect general object-first ordering preference.

Sponsored by:	SPARTA (original patches against Mac OS X)
Obtained from:	TrustedBSD Project, Apple Computer
2007-10-26 13:18:38 +00:00
Robert Watson
02be6269c3 Normalize TCP syncache-related MAC Framework entry points to match most
other entry points in the form mac_<object>_method().

Discussed with:	csjp
Obtained from:	TrustedBSD Project
2007-10-25 14:37:37 +00:00
Robert Watson
30d239bc4c Merge first in a series of TrustedBSD MAC Framework KPI changes
from Mac OS X Leopard--rationalize naming for entry points to
the following general forms:

  mac_<object>_<method/action>
  mac_<object>_check_<method/action>

The previous naming scheme was inconsistent and mostly
reversed from the new scheme.  Also, make object types more
consistent and remove spaces from object types that contain
multiple parts ("posix_sem" -> "posixsem") to make mechanical
parsing easier.  Introduce a new "netinet" object type for
certain IPv4/IPv6-related methods.  Also simplify, slightly,
some entry point names.

All MAC policy modules will need to be recompiled, and modules
not updates as part of this commit will need to be modified to
conform to the new KPI.

Sponsored by:	SPARTA (original patches against Mac OS X)
Obtained from:	TrustedBSD Project, Apple Computer
2007-10-24 19:04:04 +00:00
Robert Watson
26ae2b86b6 Normalize variable naming in the MAC Framework by adopting the normal
variable name conventions for arguments passed into the framework --
for example, name network interfaces 'ifp', sockets 'so', mounts 'mp',
mbufs 'm', processes 'p', etc, wherever possible.  Previously there
was significant variation in this regard.

Normalize copyright lists to ranges where sensible.
2007-04-22 19:55:56 +00:00
Robert Watson
c96ae1968a Continue 7-CURRENT MAC Framework rearrangement and cleanup:
Don't perform a nested include of _label.h in mac.h, as mac.h now
describes only  the user API to MAC, and _label.h defines the in-kernel
representation of MAC labels.

Remove mac.h includes from policies and MAC framework components that do
not use userspace MAC API definitions.

Add _KERNEL inclusion checks to mac_internal.h and mac_policy.h, as these
are kernel-only include files

Obtained from:	TrustedBSD Project
2007-02-06 10:59:23 +00:00
Robert Watson
c982ffa42a In mac_inpcb_sosetlabel(), assert the socket lock rather than commenting
that we should assert the socket lock.

Obtained from:	TrustedBSD Project
2006-12-28 21:56:39 +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
e66fe0e1db Remove mac_enforce_subsystem debugging sysctls. Enforcement on
subsystems will be a property of policy modules, which may require
access control check entry points to be invoked even when not actively
enforcing (i.e., to track information flow without providing
protection).

Obtained from:	TrustedBSD Project
Suggested by:	Christopher dot Vance at sparta dot com
2006-12-21 09:51:34 +00:00
Robert Watson
95c8c170f3 Re-wrap comment at 77 character columns. 2006-12-20 23:11:01 +00:00
Christian S.J. Peron
826cef3d75 Fix LOR between the syncache and inpcb locks when MAC is present in the
kernel.  This LOR snuck in with some of the recent syncache changes.  To
fix this, the inpcb handling was changed:

- Hang a MAC label off the syncache object
- When the syncache entry is initially created, we pickup the PCB lock
  is held because we extract information from it while initializing the
  syncache entry.  While we do this, copy the MAC label associated with
  the PCB and use it for the syncache entry.
- When the packet is transmitted, copy the label from the syncache entry
  to the mbuf so it can be processed by security policies which analyze
  mbuf labels.

This change required that the MAC framework be extended to support the
label copy operations from the PCB to the syncache entry, and then from
the syncache entry to the mbuf.

These functions really should be referencing the syncache structure instead
of the label.  However, due to some of the complexities associated with
exposing this syncache structure we operate directly on it's label pointer.
This should be OK since we aren't making any access control decisions within
this code directly, we are merely allocating and copying label storage so
we can properly initialize mbuf labels for any packets the syncache code
might create.

This also has a nice side effect of caching.  Prior to this change, the
PCB would be looked up/locked for each packet transmitted.  Now the label
is cached at the time the syncache entry is initialized.

Submitted by:	andre [1]
Discussed with:	rwatson

[1] andre submitted the tcp_syncache.c changes
2006-12-13 06:00:57 +00:00
Robert Watson
aed5570872 Complete break-out of sys/sys/mac.h into sys/security/mac/mac_framework.h
begun with a repo-copy of mac.h to mac_framework.h.  sys/mac.h now
contains the userspace and user<->kernel API and definitions, with all
in-kernel interfaces moved to mac_framework.h, which is now included
across most of the kernel instead.

This change is the first step in a larger cleanup and sweep of MAC
Framework interfaces in the kernel, and will not be MFC'd.

Obtained from:	TrustedBSD Project
Sponsored by:	SPARTA
2006-10-22 11:52:19 +00:00
Robert Watson
738f14d4b1 Remove MAC_DEBUG label counters, which were used to debug leaks and
other problems while labels were first being added to various kernel
objects.  They have outlived their usefulness.

MFC after:	1 month
Suggested by:	Christopher dot Vance at SPARTA dot com
Obtained from:	TrustedBSD Project
2006-09-20 13:33:41 +00:00
Christian S.J. Peron
d94f2a68f8 Introduce a new entry point, mac_create_mbuf_from_firewall. This entry point
exists to allow the mandatory access control policy to properly initialize
mbufs generated by the firewall. An example where this might happen is keep
alive packets, or ICMP error packets in response to other packets.

This takes care of kernel panics associated with un-initialize mbuf labels
when the firewall generates packets.

[1] I modified this patch from it's original version, the initial patch
    introduced a number of entry points which were programmatically
    equivalent. So I introduced only one. Instead, we should leverage
    mac_create_mbuf_netlayer() which is used for similar situations,
    an example being icmp_error()

    This will minimize the impact associated with the MFC

Submitted by:	mlaier [1]
MFC after:	1 week

This is a RELENG_6 candidate
2006-09-12 04:25:13 +00:00
Robert Watson
c66b4d8d26 Move inet and inet6 related MAC Framework entry points from mac_net.c
to a new mac_inet.c.  This code is now conditionally compiled based
on inet support being compiled into the kernel.

Move socket related MAC Framework entry points from mac_net.c to a new
mac_socket.c.

To do this, some additional _enforce MIB variables are now non-static.
In addition, mbuf_to_label() is now mac_mbuf_to_label() and non-static.

Obtained from:	TrustedBSD Project
Sponsored by:	DARPA, McAfee Research
2004-02-26 03:51:04 +00:00