---
-edit_link: ''
title: Mandatory Access Control
-origin_url: >-
- https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-5/1-MAC.md
---
-<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml -->
-
# Mandatory Access Control
<!-- section-note -->
labels as part of the extended attributes **SMACK** labels to the file extended
attributes. And a policy is also created to define the behaviour of each label.
-The kernel access controls is based on these labels and this policy. If there
-is no rule, no access will be granted and as a consequence, what is not
-explicitly authorized is forbidden.
+The kernel access controls is based on these labels and this policy. If there is
+no rule, no access will be granted and as a consequence, what is not explicitly
+authorized is forbidden.
There are two types of **SMACK** labels:
- System.
- Applications, Services and User.
-See [AGL security framework review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) and [Smack White Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
+See [AGL security framework
+review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf)
+and [Smack White
+Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
for more information.
--------------------------------------------------------------------------------
- Basic utilities for policy management and checking.
- The policy/configuration data.
-As with any mandatory access system, the policy management needs to be carefully separated
-from the checking, as the management utilities can become a convenient point of attack.
-Dynamic additions to the policy system need to be carefully verified, as the ability to
-update the policies is often needed, but introduces a possible threat. Finally,
-even if the policy management is well secured, the policy checking and failure response
-to that checking is also of vital importance to the smooth operation of the system.
+As with any mandatory access system, the policy management needs to be carefully
+separated from the checking, as the management utilities can become a convenient
+point of attack. Dynamic additions to the policy system need to be carefully
+verified, as the ability to update the policies is often needed, but introduces
+a possible threat. Finally, even if the policy management is well secured, the
+policy checking and failure response to that checking is also of vital
+importance to the smooth operation of the system.
-While **MAC** is a certainly a step up in security when compared to DAC, there are still
-many ways to compromise a SMACK-enabled Linux system. Some of these ways are as follows:
+While **MAC** is a certainly a step up in security when compared to DAC, there
+are still many ways to compromise a SMACK-enabled Linux system. Some of these
+ways are as follows:
-- Disabling SMACK at invocation of the kernel (with command-line: security=none).
+- Disabling SMACK at invocation of the kernel (with command-line:
+ security=none).
- Disabling SMACK in the kernel build and redeploying the kernel.
- Changing a SMACK attribute of a file or directory at install time.
- Tampering with a process with the CAP_MAC_ADMIN privilege.
- Setting/Re-setting the SMACK label of a file.
-- Tampering with the default domains (i.e. /etc/smack/accesses.d/default-access-domains).
+- Tampering with the default domains (i.e.
+ /etc/smack/accesses.d/default-access-domains).
- Disabling or tampering with the SMACK filesystem (i.e. /smackfs).
- Adding policies with `smackload` (adding the utility if not present).
- Changing labels with `chsmack` (adding the utility if not present).
Code Review / AGL / documentation.git / blobdiff