Locking for Module Writers
Module writers must be aware of the locking semantics of entry points that they implement: MAC API entry points will have specific locking or reference counting semantics for each argument, and modules must follow the locking and reference counting protocol or risk a variety of failure modes (including race conditions, inappropriate pointer dereferences, etc).
MAC module writers must also be aware that MAC API entry points will frequently be invoked from deep in a kernel stack, and as such must be careful to avoid violating more global locking requirements, such as global lock order requirements. For example, it may be inappropriate to lock additional objects not specifically maintained and ordered by the policy module, or the policy module might violate a global ordering requirement relating to those additional objects.
Finally, MAC API module implementors must be careful to avoid inappropriately calling back into the MAC framework: the framework makes use of locking to prevent inconsistencies during policy module attachment and detachment. MAC API modules should avoid producing scenarios in which deadlocks or inconsistencies might occur.
Adding New MAC Entry Points
The MAC API is intended to be easily expandable as new services are added to the kernel. In order that policies may be guaranteed the opportunity to ubiquitously protect system subjects and objects, it is important that kernel developers maintain awareness of when security checks or relevant subject or object operations occur in newly written or modified kernel code. New entry points must be carefully documented so as to prevent any confusion regarding lock orders and semantics. Introducing new entry points requires four distinct pieces of work: introducing new MAC API entries reflecting the operation arguments, scattering these MAC API entry points throughout the new or modified kernel service, extending the front-end implementation of the MAC API framework, and modifying appropriate modules to take advantage of the new entry points so that they may consistently enforce their policies.
System service and module authors should reference the "FreeBSD Developers Handbook" for information on the MAC Framework APIs.
acl(3), mac(3), posix1e(3), mac_biba(4), mac_bsdextended(4), mac_ifoff(4), mac_lomac(4), mac_mls(4), mac_none(4), mac_partition(4), mac_seeotheruids(4), mac_test(4), ucred(9), vaccess(9), vaccess_acl_posix1e(9), VFS(9)
.Rs "The FreeBSD Developers Handbook"