TÍTULO: PROPUESTA «AUSTRIA PRIMERO»

MAC Framework policies may be compiled into the kernel or encapsulated in loadable kernel modules, which themselves may be loaded during boot or at run-time. Whether a policy can be loaded or unloaded dynamically depends on its semantics, which are exposed as properties during policy registration. The MAC Framework imposes a common structure on policies: a declaration, an optional “slot” reservation for labelling if required, and a set of functions implementing declared entry points.

All but the most trivial of policies will separate entry point functions, which are aware of kernel data types and interpretations, from access control logic, which will compute decisions relative to type-independent labels or a classification of entry points by information flow directions. For example, in SEBSD, a port of FLASK and Type En- forcement to the MAC Framework, entry point functions locate the Security Identifiers (SIDs) on kernel processes and objects and pass them into FLASK’s decision functions, providing a static mapping from kernel events to FLASK events, and isolating FLASK from label storage and kernel data structures

FreeBSD 5.0 shipped with several kernel modules providing a diverse set of kernel access control extensions, which have been added to both by the project and in third- party products since that release. Table 3.3 lists the sample policies included with the most recent FreeBSD 8.1 release, illustrating the diversity of supported models as well as the practicality of the approach. For the purposes of exploring the structure and implementation of policy modules, we will consider the fixed-label Biba integrity policy in further detail.

3.6.1 The Biba integrity policy

The Biba integrity policy implements a strict information flow policy limiting the im- pact of lower integrity subjects and objects on higher integrity subjects and objects [18]. In general, high integrity subjects are allowed to write but not read lower integrity ob- jects, and low integrity subjects are allowed to read but not write high integrity objects.

Policy Description

mac biba Hierarchal fixed-label integrity

ugidfw “File system firewall” employing UNIX credentials

and file ownership rather than labels – while the kernel module is named mac bsdextended, we will

refer to this policy by its command line tool name,

ugidfw.

mac ifoff Interface silencing to prevent leakage in packet

capture environments

mac lomac Hierarchal floating-label integrity

mac mls Multi-Level Security (BLP) with compartments

mac none Stub policy: all entry points are implemented as

no-ops; a template for new policies

mac partition Inter-process visibility policy based on process

partition labels assigned by the administrator

mac portacl TCP/IP port access control list policy, allowing

the administrator to control application uses of the TCP and UDP port namespaces

mac seeotheruids Inter-process visibility policy based on UNIX UIDs

mac test MAC Framework invariant validation suite: tests

locking protocols and object life cycles

Table 3.3: Table of policy modules

Biba relies on ubiquitous labelling of all system objects, and determines access control results with a dominance operator over label pairs. The policy has been frequently deployed in trusted systems to protect the Trusted Computing Base (TCB).

The TrustedBSD Biba policy module implements a hierarchal and compartmental, fixed-label mandatory integrity policy. Subject labels contain an effective label ele- ment, as well as a range of available elements; the range, set by the administrator, supports a scoped notion of privilege for users and processes by allowing selected pro- cesses to“float” up between levels or compartments for the purposes of I/O, and may also relabel objects subject to those constraints. A range with a lower value of the special constant LOW and a higher value of special constant HIGH has complete priv- ilege within the Biba model, and is therefore also used to authorise privileged system operations that might violate the integrity properties of the process model – the role of privilege in the MAC Framework is discussed in detail in Section 4.2. Objects in the system are labeled with a single element reflecting the integrity grade and compartment of data in the object.

static int biba_slot;

#define SLOT(l) ((struct mac_biba *)mac_label_get((l), biba_slot))

#define SLOT_SET(l, val) mac_label_set((l), biba_slot, (uintptr_t)(val)) ...

static struct mac_policy_ops mac_biba_ops = { .mpo_init = biba_init, .mpo_bpfdesc_check_receive = biba_bpfdesc_check_receive, .mpo_bpfdesc_create = biba_bpfdesc_create, .mpo_bpfdesc_create_mbuf = biba_bpfdesc_create_mbuf, .mpo_bpfdesc_destroy_label = biba_destroy_label, .mpo_bpfdesc_init_label = biba_init_label, .mpo_cred_associate_nfsd = biba_cred_associate_nfsd, .mpo_cred_check_relabel = biba_cred_check_relabel, .mpo_cred_check_visible = biba_cred_check_visible, .mpo_cred_copy_label = biba_copy_label, ... };

MAC_POLICY_SET(&mac_biba_ops, /* Policy entry point vector. */

mac_biba, /* Policy short name. */

"TrustedBSD MAC/Biba", /* Policy long name. */ MPC_LOADTIME_FLAG_NOTLATE, /* Policy flags. */

&biba_slot); /* Label slot pointer, if required. */

Figure 3.7: Annotated excerpt of the Biba policy declaration.

policy properties, such as name and behavioural flags, and makes use of the FreeBSD kernel linker set facility (described in Section 3.5.2). This causes policy registration and deregistration functions to be invoked automatically whenever the containing module is loaded and unloaded, as well as to initiate allocation of labels on desired objects. Figure 3.7 illustrates an annotated version of the declaration of the FreeBSD Biba policy.

The Biba policy is a ubiquitously labeled policy that cannot be loaded after boot or unloaded, indicated by the presence of the MPC LOADTIME FLAG NOTLATEflag and ab-

sence of the MPC LOADTIME FLAG UNLOADOK flag. The Biba policy module generally uses

entry point-specific functions for object life cycle events and access control checks, with the exception of label initialization and destruction, which are implemented using type-independent functions biba init label and biba destroy label. This is possible

static int

biba_vnode_check_write(struct ucred *active_cred,

struct ucred *file_cred, struct vnode *vp, struct label *vplabel) {

struct mac_biba *subj, *obj;

if (!biba_enabled || !revocation_enabled) return (0); subj = SLOT(active_cred->cr_label); obj = SLOT(vplabel); if (!biba_dominate_effective(subj, obj)) return (EACCES); return (0); }

Figure 3.8: Example Biba access control check for vnode write: after checking whether the policy is enabled for revocation, mac biba extracts subject and object labels; if the subject label dominates the object label, information flow is permitted.

because the Biba policy imposes a uniform internal data structure for labels across all kernel data types; however, this model is not obligatory, and policies might wish, for example, to use different data structures for subjects than for objects, as done in LOMAC.

When the MAC Framework allocates label storage, the Biba policy will allocate and attach Biba-specific label storage to the framework-provided label. When objects or subjects are created, label values are inherited from the parent subject. When objects are loaded from persistent or external store, labels are assigned based on the of the storage medium, or on multilabel file systems, from system extended attributes utilised by the Biba policy. Labels on system abstractions such as special devices and network interfaces are configured using module defaults that may be tuned at boot-time or via administrative actions.

The Biba policy centralises its access control logic in functions implementing a “dom- inance” operator that compares two Biba elements with respect to their types, grades, and compartments to determine in what directions information may be permitted to flow between the two. Access control entry points extract subject and object labels, and then test for dominance based on categorising information flow as subject to object, object to subject, or a bidirectional flow, as illustrated in Figure 3.8. The SLOT macro

is defined in terms of the MAC Framework’s label accessor function, mac label get,

which returns the value stored in the label; in the case of Biba, this is a pointer to the Biba label structure, struct mac biba.

The MAC Framework successfully isolates the details of the policy implementation from the kernel services, but also isolates the details of the kernel services from the

policy implementation, reducing the risks of minor changes in one subsystem requiring gratuitous changes in the other. The MAC Framework supports the Biba policy through a generalised label management service, permitting the policy implementor to focus on the details of the policy application rather than the mechanism of instrumenting the kernel to support the policy’s instrumentation requirements.