Security mechanisms dance behind the curtain when you access information. One of those mechanisms can be the reference monitor. Below is a chart breaking down the path of the access control process:
Graphic built from (Sherwood, et al., 2005)
We see the subject (e.g. user or application) making a request to access an object (e.g. database, file, device) but first gets checked by the reference monitor. The monitor makes a decision to allow or deny by referring to the profile rules of the subject, and two; the access list of the object it's trying to access. The items in the chart above are defined in the table below:
Understanding Reference Monitor through the MAC system on SELinux
The improved Linux kernel security module is called SELinux (Security-Enhanced Linux) that provides a mechanism for supporting access control security policies, including DoD–style mandatory access controls (MAC). A MAC policy does what it means "Mandatory Access Policy". Both subject permissions and object label must match to have security kernel allow access.
For SELinux there are three types:
A strong MAC policy implemented will not allow an attacker or exploit in one program interfere with another client or server on the network. The MAC rules on the security kernel of the machine confines the malicious code. The security kernel works independently from the traditional Linux access controls and has no concept of root user. It is often the root user account that is compromised that allows modification on the system in a DAC system (Nakamura, 2007). DAC policies comes standard on desktops, laptops, and mobile devices. This is presented when you get the pop-up to use an admin password to install a program.
A discretionary access control (DAC) policy, as shown above, is what it is: Access at the discretion of the user. In the realm of the attack, this means gaining root access to the servers and clients to access objects without restriction.
Reference Monitor in Virtual Environments
Physical Machine Environment with each client with a Security Kernel:
(Red Hat, 2016)
Virtual Environment has both guest kernel and host kernel as multiple machines run on one host (device):
(Red Hat, 2016)
Virtual environments without access policies pose different risks to the network. Red Hat Enterprise Linux 6 Virtualization Security Guide provides a summary of virtualization threats and how to mitigate with sVirt:
sVirt integrates virtualization into the existing security framework provided by SELinux (Security-Enhanced Linux), applying Mandatory Access Control(MAC) to virtual machines. The main objective of sVirt is to protect hosts and guests from attacks via security vulnerabilities in the hypervisor. SELinux secures a system by applying access policy across different processes. sVirt extends this capability to hosts and guests by treating each guest as a process, allowing administrators to apply similar policies designed to prevent malicious guests from accessing restricted resources.
Alternative to the MAC, the RBAC in VMware Vsphere Hypervisor
VMware's security kernel opposite may be the ESXi system kernel designed to run virtual machines. VMware described ESXi to be different from a UNIX or Linux OS approach. Typically, Linux uses concepts such as file systems and users and groups, but this are not the case for the ESXi system:
"The implications of this design are significant: Security hardening for a typical Linux system potentially requires
dozens of steps, such as changing file permissions, disabling services, and managing user privileges; ESXi requires none of these steps, most of which either are impossible to perform or have no effect. ...The files that one sees when logged in to the shell exist only in memory, and changes made to most files are not persistent across reboots" (VMware, 2014).
ESXi does not have a concept of “users” for file ownership. Therefore, the "objects" are accessible to all shell sessions. In ESXi, all logins to the shell have exactly the same privileges. User name becomes a factor to record commands used in its audit module (VMware, 2014). To better explain how ESXi retains accountability, ESXi records who created the file, but could careless of labeling the file with the owner.
The primary measures required for securing an ESXi host involve properly managing the interfaces with the system that are used for configuration, management, and troubleshooting (VMware, 2014). The virtual system achieves access control by connecting to Windows Active Directory, which set roles for users that provide access to the ESXi host volumes.
Active Directory & RBAC
Windows Active Directory (AD) allows role templates to be created for permissions for a workers role. For example, if you are hired on as an HR Manager, you will most likely have the privileges of a normal HR employee plus higher level access to administer those files. Therefore, two roles can be created, one for HR and another for HR Manager. This logic applies to the rest of the organization as each role only needs to access resources required to do their job. This allows organizations to use RBAC to follow the security principles of "least privilege" and "separation of duties". When ESXi connects to active directory, it will assume the privileges of user roles and groups.
A typical organization would have the privileges for part purchases, receiving and vendor payments:
From the above table, we can see the role of administrator, or root user, may have unlimited control over the flow of data in the information system. For part purchases, we see that the procurement manager needs access to resources that allow the read, creation, and action functions with all things procurement. The receiving manager may need to read what the procurement manager has purchased, to track the import of those items. Once the items are received, those items can be signed off by receiving and placed into inventory. The procurement manager and warehouse manager may want to read what the receiving manager has placed into inventory to reconcile any discrepancies and make returns and/or reorders. When it comes time for paying the vendor, Accounts payable was able to get ready for payment since it was able to read those orders, and can execute payment in the accounting information system.
We can see now how the reference monitor is important to understand in the cyber security world. The reference monitor acts as gatekeeper between the subject (e.g. user) and object (e.g. resource) based on policies available in the software. It compares access control list on both subject and object to allow or deny access. An organization's data classification system, access control requirements, and utilization of existing resources (e.g. Windows AD) play a crucial role in deciding the type of reference monitor for future information system decisions. The policies of MAC, DAC, and RBAC used in both physical and virtual systems have different degrees of administration and security that stakeholders should take account when considering security architecture.
Red Hat. (2016). SELinux User's and Administrator's Guide. Red Hat, Inc. Retrieved from: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/index.html
Red Hat. (2017, October 20). Red Hat Enterprise Linux 6: Virtualization Security Guide. Retrieved from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/pdf/virtualization_security_guide/Red_Hat_Enterprise_Linux-6-Virtualization_Security_Guide-en-US.pdf
Sherwood, J., Clark, A., Lynas, D. (2005). Enterprise Security Architecture, A Business-Driven Approach. Boca Raton, Florida: CRC Press.
Technopedia. (2017). Descritionary Access Control. Retrieved from https://www.techopedia.com/definition/229/discretionary-access-control-dac
Technopedia. (2017). Mandatory Access Control. Retrieved from https://www.techopedia.com/definition/4017/mandatory-access-control-mac
VMware. (2014, January). Security of the VMware vSphere® Hypervisor. Retrieved from https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/techpaper/vmw-white-paper-secrty-vsphr-hyprvsr-uslet-101.pdf
Wells, S.D. (2008, October 15). 2008-10-15 Red Hat Deep Dive Sessions: SELinux [Slideshare Slides]. Retrieved from https://www.slideshare.net/ShawnWells4/20081015-red-hat-deep-dive-sessions-selinux
Cyber security student and researcher.
Security Predictions for 2019
Hackin' with Metasploit
Understanding the Reference Monitor
Did the Security Predictions for 2017 Come True?
Cyber Security Executive Order & NIST