diff --git a/share/man/man9/mac.9 b/share/man/man9/mac.9 index 58c2f7a2484e..89238d28b61c 100644 --- a/share/man/man9/mac.9 +++ b/share/man/man9/mac.9 @@ -1,231 +1,232 @@ .\"- .\" Copyright (c) 1999-2002 Robert N. M. Watson .\" Copyright (c) 2002-2004 Networks Associates Technology, Inc. .\" All rights reserved. .\" .\" This software was developed by Robert Watson for the TrustedBSD Project. .\" .\" This software was developed for the FreeBSD Project in part by Network .\" Associates Laboratories, the Security Research Division of Network .\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 .\" ("CBOSS"), as part of the DARPA CHATS research program. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $FreeBSD$ .\" -.Dd July 25, 2015 +.Dd February 27, 2021 .Dt MAC 9 .Os .Sh NAME .Nm mac .Nd TrustedBSD Mandatory Access Control framework .Sh SYNOPSIS .In sys/types.h .In sys/mac.h .Pp In the kernel configuration file: .Cd "options MAC" .Cd "options MAC_DEBUG" .Sh DESCRIPTION .Ss Introduction The .Tn TrustedBSD mandatory access control framework permits dynamically introduced system security modules to modify system security functionality. This can be used to support a variety of new security services, including traditional labeled mandatory access control models. The framework provides a series of entry points which must be called by code supporting various kernel services, especially with respects to access control points and object creation. The framework then calls out to security modules to offer them the opportunity to modify security behavior at those MAC API entry points. Both consumers of the API (normal kernel services) and security modules must be aware of the semantics of the API calls, particularly with respect to synchronization primitives (such as locking). .Ss Kernel Objects Supported by the Framework The MAC framework manages labels on a variety of types of in-kernel objects, including process credentials, vnodes, devfs_dirents, mount points, sockets, mbufs, bpf descriptors, network interfaces, IP fragment queues, and pipes. Label data on kernel objects, represented by .Vt "struct label" , is policy-unaware, and may be used in the manner seen fit by policy modules. .Ss API for Consumers The MAC API provides a large set of entry points, too broad to specifically document here. In general, these entry points represent an access control check or other MAC-relevant operations, accept one or more subjects (credentials) authorizing the activity, a set of objects on which the operation is to be performed, and a set of operation arguments providing information about the type of operation being requested. .Ss Locking for Consumers Consumers of the MAC API must be aware of the locking requirements for each API entry point: generally, appropriate locks must be held over each subject or object being passed into the call, so that MAC modules may make use of various aspects of the object for access control purposes. For example, vnode locks are frequently required in order that the MAC framework and modules may retrieve security labels and attributes from the vnodes for the purposes of access control. Similarly, the caller must be aware of the reference counting semantics of any subject or object passed into the MAC API: all calls require that a valid reference to the object be held for the duration of the (potentially lengthy) MAC API call. Under some circumstances, objects must be held in either a shared or exclusive manner. .Ss API for Module Writers Each module exports a structure describing the MAC API operations that the module chooses to implement, including initialization and destruction API entry points, a variety of object creation and destruction calls, and a large set of access control check points. In the future, additional audit entry points will also be present. Module authors may choose to only implement a subset of the entry points, setting API function pointers in the description structure to .Dv NULL , permitting the framework to avoid calling into the module. .Ss 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). .Pp 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. .Pp 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. .Ss 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. .Sh ENTRY POINTS System service and module authors should reference the .%T "FreeBSD Architecture Handbook" for information on the MAC Framework APIs. .Sh SEE ALSO .Xr acl 3 , .Xr mac 3 , .Xr posix1e 3 , .Xr mac_biba 4 , .Xr mac_bsdextended 4 , .Xr mac_ifoff 4 , .Xr mac_lomac 4 , .Xr mac_mls 4 , .Xr mac_none 4 , .Xr mac_partition 4 , .Xr mac_seeotheruids 4 , .Xr mac_test 4 , .Xr ucred 9 , .Xr vaccess 9 , .Xr vaccess_acl_posix1e 9 , -.Xr VFS 9 +.Xr VFS 9 , +.Xr VOP_SETLABEL 9 . .Rs .%T "The FreeBSD Architecture Handbook" .%U "https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/arch-handbook/" .Re .Sh HISTORY The .Tn TrustedBSD MAC Framework first appeared in .Fx 5.0 . .Sh AUTHORS This manual page was written by .An Robert Watson . This software was contributed to the .Fx Project by Network Associates Laboratories, the Security Research Division of Network Associates Inc.\& under DARPA/SPAWAR contract N66001-01-C-8035 .Pq Dq CBOSS , as part of the DARPA CHATS research program. .Pp .An -nosplit The .Tn TrustedBSD MAC Framework was designed by .An Robert Watson , and implemented by the Network Associates Laboratories Network Security (NETSEC), Secure Execution Environment (SEE), and Adaptive Network Defense research groups. Network Associates Laboratory staff contributing to the CBOSS Project include (in alphabetical order): .An Lee Badger , .An Brian Feldman , .An Hrishikesh Dandekar , .An Tim Fraser , .An Doug Kilpatrick , .An Suresh Krishnaswamy , .An Adam Migus , .An Wayne Morrison , .An Andrew Reisse , .An Chris Vance , and .An Robert Watson . .Pp Sub-contracted staff include: .An Chris Costello , .An Poul-Henning Kamp , .An Jonathan Lemon , .An Kirk McKusick , .An Dag-Erling Sm\(/orgrav . .Pp Additional contributors include: .An Pawel Dawidek , .An Chris Faulhaber , .An Ilmar Habibulin , .An Mike Halderman , .An Bosko Milekic , .An Thomas Moestl , .An Andrew Reiter , and .An Tim Robbins . .Sh BUGS While the MAC Framework design is intended to support the containment of the root user, not all attack channels are currently protected by entry point checks. As such, MAC Framework policies should not be relied on, in isolation, to protect against a malicious privileged user. diff --git a/share/man/man9/vnode.9 b/share/man/man9/vnode.9 index 91360a755fbc..5ff45d7a1364 100644 --- a/share/man/man9/vnode.9 +++ b/share/man/man9/vnode.9 @@ -1,197 +1,198 @@ .\" Copyright (c) 1996 Doug Rabson .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" $FreeBSD$ .\" .Dd February 12, 2014 .Dt VNODE 9 .Os .Sh NAME .Nm vnode .Nd internal representation of a file or directory .Sh SYNOPSIS .In sys/param.h .In sys/vnode.h .Sh DESCRIPTION The vnode is the focus of all file activity in .Ux . A vnode is described by .Vt "struct vnode" . There is a unique vnode allocated for each active file, each current directory, each mounted-on file, text file, and the root. .Pp Each vnode has three reference counts, .Va v_usecount , .Va v_holdcnt and .Va v_writecount . The first is the number of clients within the kernel which are using this vnode. This count is maintained by .Xr vref 9 , .Xr vrele 9 and .Xr vput 9 . The second is the number of clients within the kernel who veto the recycling of this vnode. This count is maintained by .Xr vhold 9 and .Xr vdrop 9 . When both the .Va v_usecount and the .Va v_holdcnt of a vnode reaches zero then the vnode will be put on the freelist and may be reused for another file, possibly in another file system. The transition from the freelist is handled by .Xr getnewvnode 9 . The third is a count of the number of clients which are writing into the file. It is maintained by the .Xr open 2 and .Xr close 2 system calls. .Pp Any call which returns a vnode (e.g.,\& .Xr vget 9 , .Xr VOP_LOOKUP 9 , etc.\&) will increase the .Va v_usecount of the vnode by one. When the caller is finished with the vnode, it should release this reference by calling .Xr vrele 9 (or .Xr vput 9 if the vnode is locked). .Pp Other commonly used members of the vnode structure are .Va v_id which is used to maintain consistency in the name cache, .Va v_mount which points at the file system which owns the vnode, .Va v_type which contains the type of object the vnode represents and .Va v_data which is used by file systems to store file system specific data with the vnode. The .Va v_op field is used by the .Dv VOP_* macros to call functions in the file system which implement the vnode's functionality. .Sh VNODE TYPES .Bl -tag -width VSOCK .It Dv VNON No type. .It Dv VREG A regular file; may be with or without VM object backing. If you want to make sure this get a backing object, call .Fn vnode_create_vobject . .It Dv VDIR A directory. .It Dv VBLK A block device; may be with or without VM object backing. If you want to make sure this get a backing object, call .Fn vnode_create_vobject . .It Dv VCHR A character device. .It Dv VLNK A symbolic link. .It Dv VSOCK A socket. Advisory locking will not work on this. .It Dv VFIFO A FIFO (named pipe). Advisory locking will not work on this. .It Dv VBAD Indicates that the vnode has been reclaimed. .El .Sh IMPLEMENTATION NOTES VFIFO uses the "struct fileops" from .Pa /sys/kern/sys_pipe.c . VSOCK uses the "struct fileops" from .Pa /sys/kern/sys_socket.c . Everything else uses the one from .Pa /sys/kern/vfs_vnops.c . .Pp The VFIFO/VSOCK code, which is why "struct fileops" is used at all, is an artifact of an incomplete integration of the VFS code into the kernel. .Pp Calls to .Xr malloc 9 or .Xr free 9 when holding a .Nm interlock, will cause a LOR (Lock Order Reversal) due to the intertwining of VM Objects and Vnodes. .Sh SEE ALSO .Xr malloc 9 , .Xr VFS 9 , .Xr VOP_ACCESS 9 , .Xr VOP_ACLCHECK 9 , .Xr VOP_ADVISE 9 , .Xr VOP_ADVLOCK 9 , .Xr VOP_ALLOCATE 9 , .Xr VOP_ATTRIB 9 , .Xr VOP_BWRITE 9 , .Xr VOP_CREATE 9 , .Xr VOP_FSYNC 9 , .Xr VOP_GETACL 9 , .Xr VOP_GETEXTATTR 9 , .Xr VOP_GETPAGES 9 , .Xr VOP_INACTIVE 9 , .Xr VOP_IOCTL 9 , .Xr VOP_LINK 9 , .Xr VOP_LISTEXTATTR 9 , .Xr VOP_LOCK 9 , .Xr VOP_LOOKUP 9 , .Xr VOP_OPENCLOSE 9 , .Xr VOP_PATHCONF 9 , .Xr VOP_PRINT 9 , .Xr VOP_RDWR 9 , .Xr VOP_READDIR 9 , .Xr VOP_READLINK 9 , .Xr VOP_REALLOCBLKS 9 , .Xr VOP_REMOVE 9 , .Xr VOP_RENAME 9 , .Xr VOP_REVOKE 9 , .Xr VOP_SETACL 9 , .Xr VOP_SETEXTATTR 9 , +.Xr VOP_SETLABEL 9 , .Xr VOP_STRATEGY 9 , .Xr VOP_VPTOCNP 9 , .Xr VOP_VPTOFH 9 .Sh AUTHORS This manual page was written by .An Doug Rabson .