mac_veriexec ensure label fields are initialized

Obtained from: bkumara@juniper.net

veriexec: Do not save error from file info in fingerprint status

We do not want or need to propagate the error from fetching file info
when determining the file status. It could cause open(2) and similar
calls to fail when trying to access devices.

Obtained from: Juniper Networks, Inc.

veriexec: Add function to get label associated with a file

Add mac_veriexec_metadata_get_file_label to avoid the need to
expose internals to other MAC modules.

Obtained from: Juniper Networks, Inc.

veriexec: Add option MAC_VERIEXEC_DEBUG

Obtained from: Juniper Networks, Inc.

veriexec: Additional functionality for MAC/veriexec

Ensure veriexec opens the file before doing any read operations.

When the MAC_VERIEXEC_CHECK_PATH_SYSCALL syscall is requested, veriexec
needs to open the file before calling mac_veriexec_check_vp. This is to
ensure any set up is done by the file system. Most file systems do not
explicitly need an open, but some (e.g. virtfs) require initialization
of access tokens (file identifiers, etc.) before doing any read or write
operations.

The evaluate_fingerprint() function needs to ensure it has an open file
for reading in order to evaluate the fingerprint. The ideal solution is
to have a hook after the VOP_OPEN call in vn_open. For now, we open the
file for reading, envaluate the fingerprint, and close the file. While
this leaves a potential hole that could possibly be taken advantage of
by a dedicated aversary, this code path is not typically visited often
in our use cases, as we primarily encounter verified mounts and not
individual files. This should be considered a temporary workaround until
discussions about the post-open hook have concluded and the hook becomes
available.

Add MAC_VERIEXEC_GET_PARAMS_PATH_SYSCALL and
MAC_VERIEXEC_GET_PARAMS_PID_SYSCALL to mac_veriexec_syscall so we can
fetch and check label contents in an unconstrained manner.

Add a check for PRIV_VERIEXEC_CONTROL to do ioctl on /dev/veriexec

Make it clear that trusted process cannot be debugged. Attempts to debug
a trusted process already fail, but the failure path is very obscure.
Add an explicit check for VERIEXEC_TRUSTED in
mac_veriexec_proc_check_debug.

We need mac_veriexec_priv_check to not block PRIV_KMEM_WRITE if
mac_priv_gant() says it is ok.

Reviewed by: sjg
Obtained from: Juniper Networks, Inc.

veriexec: Add SPDX-License-Identifier

mac_veriexec: Fix a typo in a source code comment

- s/seach/search/

MFC after: 3 days

security: clean up empty lines in .c and .h files

Add a new ioctl for the larger params struct that includes the label.

We need to make the find_veriexec_file() function available publicly, so
rename it to mac_veriexec_metadata_find_file_info() and make it non-static.

Bump the version of the veriexec device interface so user space will know
the labelized version of fingerprint loading is available.

Approved by: sjg
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D20295

Fix build breakage in veriexec for 32-bit architectures.

fsid_t and ino_t are 64-bit entities, use uintmax_t typecast to ensure we
can print it on 32-bit or 64-bit architectures by using the %ju format for
prints.

Obtained from: Juniper Networks, Inc.

MAC/veriexec implements a verified execution environment using the MAC
framework.

The code is organized into a few distinct pieces:

* The meta-data store (in veriexec_metadata.c) which maps a file system
identifier, file identifier, and generation key tuple to veriexec
meta-data record.

* Fingerprint management (in veriexec_fingerprint.c) which deals with
calculating the cryptographic hash for a file and verifying it. It also
manages the loadable fingerprint modules.

* MAC policy implementation (in mac_veriexec.c) which implements the
following MAC methods:

mpo_init
Initializes the veriexec state, meta-data store, fingerprint modules,
and registers mount and unmount EVENTHANDLERs

mpo_syscall
Implements the following per-policy system calls:
MAC_VERIEXEC_CHECK_FD_SYSCALL
Check a file descriptor to see if the referenced file has a valid
fingerprint.
MAC_VERIEXEC_CHECK_PATH_SYSCALL
Check a path to see if the referenced file has a valid fingerprint.

mpo_kld_check_load
Check if loading a kld is allowed. This checks if the referenced vnode
has a valid fingerprint.

mpo_mount_destroy_label
Clears the veriexec slot data in a mount point label.

mpo_mount_init_label
Initializes the veriexec slot data in a mount point label.
The file system identifier is saved in the veriexec slot data.

mpo_priv_check
Check if a process is allowed to write to /dev/kmem and /dev/mem
devices.
If a process is flagged as trusted, it is allowed to write.

mpo_proc_check_debug
Check if a process is allowed to be debugged. If a process is not
flagged with VERIEXEC_NOTRACE, then debugging is allowed.

mpo_vnode_check_exec
Check is an exectuable is allowed to run. If veriexec is not enforcing
or the executable has a valid fingerprint, then it is allowed to run.
NOTE: veriexec will complain about mismatched fingerprints if it is
active, regardless of the state of the enforcement.

mpo_vnode_check_open
Check is a file is allowed to be opened. If verification was not
requested, veriexec is not enforcing, or the file has a valid
fingerprint, then veriexec will allow the file to be opened.

mpo_vnode_copy_label
Copies the veriexec slot data from one label to another.

mpo_vnode_destroy_label
Clears the veriexec slot data in a vnode label.

mpo_vnode_init_label
Initializes the veriexec slot data in a vnode label.
The fingerprint status for the file is stored in the veriexec slot data.

* Some sysctls, under security.mac.veriexec, for setting debug level,
fetching the current state in a human-readable form, and dumping the
fingerprint database are implemented.

* The MAC policy implementation source file also contains some utility
functions.

* A set of fingerprint modules for the following cryptographic hash
algorithms:
RIPEMD-160, SHA1, SHA2-256, SHA2-384, SHA2-512

* Loadable module builds for MAC/veriexec and fingerprint modules.

WARNING: Using veriexec with NFS (or other network-based) file systems is
not recommended as one cannot guarantee the integrity of the files
served, nor the uniqueness of file system identifiers which are
used as key in the meta-data store.

Reviewed by: ian, jtl
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D8554