Mac Rules
You set up mac rules by defining central security labels for users and system resources. The operating system kernel checks these labels before it allows any read or write action. Many teams start with standard owner permissions on files and folders. Still, broad user roles let one bad app read sensitive files across the whole host. When an account has too much power, one mistake exposes critical company data. How mac rules work in system security Mandatory access control puts the central sys
AWS Config Rules: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up mac rules by defining central security labels for users and system resources. The operating system kernel checks these labels before it allows any read or write action. Many teams start with standard owner permissions on files and folders. Still, broad user roles let one bad app read sensitive files across the whole host. When an account has too much power, one mistake exposes critical company data.
How mac rules work in system security
Mandatory access control puts the central system in charge of all file checks. In standard setups, file owners decide who can read or change their files. With mac rules, the system admin writes a central policy that nobody can bypass. Even a root user must follow the rules set in the central policy.
The kernel attaches a security label to every active process and every stored object. Users, apps, and network sockets get subject labels when they start a session. Files, directories, database tables, and memory blocks get object labels on the disk. When an app asks to open a file, the kernel compares both labels.
These labels often combine a sensitivity level with a specific group category. A sensitivity level marks data as public, internal, or secret. A category ties that data to a specific team like billing or engineering. A user session must match both the level and the category to read data. The system also stops high-level processes from writing secret data down to public folders.
What native mac rules solve and what they miss
Host-level mac rules do a great job of locking down local processes. If a web server process gets compromised, its label blocks it from reading other folders. The attacker stays trapped inside the narrow label assigned to that single app. This stops lateral movement across the local machine and protects system files.
Still, host labels only check which process opens a file or socket. They do not inspect the actual commands or queries sent inside an approved session. Once an engineer or app passes the label check, the database trusts that session. A developer with a valid production label can still run a bad drop command. That same developer can also query tables full of customer emails and card numbers.
AWS Config Rules: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Host policies also create heavy work for operations teams over time. Every new app update can break a strict policy and stop a deploy. Teams often turn off strict enforcement just to get their apps running again. And because host rules live on single servers, they cannot unify identity across clouds.
Managing mac rules across modern databases and hosts
Modern teams run workloads across many cloud databases, containers, and remote servers. Writing kernel labels for every container and database node takes too much time. Admins must track thousands of file paths and process states across changing hosts. When a rule fails, logs show cryptic kernel denials that take hours to fix.
Teams need a clear way to control actions inside the session itself. Security must look past the local process label and check the human user identity. Controls should evaluate the exact query or command before the target system runs it. Data masking can also rewrite emails, phone numbers, and national IDs in query results. This approach keeps data safe while engineers do their daily work.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between MAC and DAC?
Discretionary control lets file owners decide who can read or edit their files. Mandatory control uses a central policy that even file owners cannot change.
Do mac rules stop bad database queries?
No, host labels only decide if a user or app can reach the database. They do not read or block specific SQL statements sent inside an active session.
Why do teams turn off strict host policies?
Strict kernel policies often block normal app updates and break daily deployments. Teams often switch policies to log-only mode so they can ship code on time.