[PATCH v4 04/14] Add primary TSEM implementation file.

[Casey Schaufler]

On 8/26/2024 3:37 AM, Greg Wettstein wrote:
> The tsem.c file is the 'master' file in the TSEM implementation. It is
> responsible for initializing the LSM and providing the implementation of the
> security event handlers.
> ---
>  security/tsem/tsem.c | 2446 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 2446 insertions(+)
>  create mode 100644 security/tsem/tsem.c
>
> diff --git a/security/tsem/tsem.c b/security/tsem/tsem.c
> new file mode 100644
> index 000000000000..76d65b3e62b3
> --- /dev/null
> +++ b/security/tsem/tsem.c
> @@ -0,0 +1,2446 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +/*
> + * Copyright (C) 2024 Enjellic Systems Development, LLC
> + * Author: Dr. Greg Wettstein <greg at enjellic.com>
> + *
> + * This file is the primary implementation file for the tsem LSM.
> + *
> + * It implements initialization and setup functions that interpret
> + * kernel command-line arguments and prepares TSEM for operation.
> + *
> + * In addition it contains all of the TSEM specific security event
> + * handlers that are responsible for handling the LSM events that TSEM
> + * models.
> + *
> + * Each TSEM event handler calls the tsem_allocate_event() function to
> + * allocate a structure that will be used to describe the event.  The
> + * CELL union of this structure contains various structures that are
> + * used to hold these parameters.
> + *
> + * Since the event characterization parameters need to be retained for
> + * the lifetime of the tsem_event structure that is allocated.  In the
> + * case of internally modeled namespaces this lifespan is the lifetime
> + * of the security modeling namespace.  In the case of externally
> + * modeled namespaces, the lifespan is until the security event
> + * description is exported to an external trust orchestrator.
> + *
> + * In order to support this model, the event description structures
> + * are typically composed of a union over 'in' and 'out' structures.
> + * The 'in' structures are used to hold arguments to the event handler
> + * that may only be relevant for the duration of the call.  These
> + * values are translated into members of the 'out' structure that
> + * retain the values until the end of the lifetime of the tsem_event
> + * structure.
> + *
> + * Each TSEM event handler is responsible for allocating a tsem_event
> + * structure and populating the appropriate CELL structure with the
> + * input characteristics of the event.  The dispatch_event() function
> + * is called to handle the modeling of the event.  This function
> + * returns the permission value that is returned as the result of the
> + * LSM event handler.
> + *
> + * The dispatch_event() calls the tsem_event_init() function that is
> + * responsible for translating the input parameters into values that
> + * will be retained for the lifetime of the security event
> + * description.  The populated event description is then dispatched to
> + * either the tsem_model_event() or the tsem_export_event() for
> + * modeling by either the internal TMA or by a TMA associated with an
> + * external trust orchestrator.
> + */
> +
> + ...
> +
> +static int tsem_file_open(struct file *file)
> +{
> +	struct inode *inode = file_inode(file);
> +	struct tsem_event *ep;
> +
> +	if (static_branch_unlikely(&tsem_not_ready))
> +		return 0;
> +	if (bypass_event(TSEM_FILE_OPEN))
> +		return 0;
> +	if (unlikely(tsem_inode(inode)->status == TSEM_INODE_CONTROL_PLANE)) {
> +		if (capable(CAP_MAC_ADMIN))

Don't you mean CAP_MAC_OVERRIDE? CAP_MAC_ADMIN is for changes to the security
state of the system, where CAP_MAC_OVERRIDE is for access control decision
exceptions. Here (and elsewhere) you use the former in access checks.