Reference Monitor
A secure, always-used and fully testable module that controls all access to data objects and devices
- It verifies the nature of the request against a table of allowable access types for each process in the system
- If it's possible to bypass the Reference Monitor, then there exists an avenue for attackers to attempt to bypass all access control

- you have some security policy that you specify
- you have subjects that make requests that relate to objects (data files, devices, etc.)
- you have a system called a Reference Monitor, which will make decisions, based on the specified policies, to either grant requests or deny them
Custom Reference Monitor
A reference monitor is used to make decisions that's adapted to our system's policies and adopted access control model
Reminders
Reference monitors always sit between the subject and the object they want to access (So if the subject has a way around the reference monitor, then the reference monitor becomes pointless)
We always want our reference monitor to be able to make as fine-grained decisions as possible when it comes to access (Since course-grained rights can lead to granting too many permissions, which is a violation of the principle of least privilege, etc.)
Custom reference monitor in capability-based models vs ACLs
Custom Reference Monitor for Capability-Based Models
- Easier to build since all you need to do is get ownership of some object you want to build a reference monitor for and then give everyone you want to access to that object a capability that gives them access instead of giving it directly to the object
Custom Reference Monitor for ACLs
- ACLs don't work well with reference monitors since most subjects in the same system will run under the same user ID
- (Since it's more about who you are rather than the fine-grain permissions that you've been granted, which makes it very difficult and very complicated to restrict access because you'd have to go and find a way to restrict all paths that might refer to something like an object)