3

I have read about MAC vs. DAC in the Internet, but I still fail to understand, what kind of attack it is impossible to protect against if one only uses DAC+capabilities in comparison to MAC+DAC+capabilities. If a process does not run as root and lacks CAP_DAC_OVERRIDE, CAP_FOWNER and other dangerous capabilities, it cannot overcome the already assigned ownership and ACL's of the resources it uses. On the other hand, if a process runs as root and has CAP_MAC_ADMIN, it can overwrite the security context enforced by MAC.

So is MAC "just additional layer of protection" without any real advantage on modern Linux system?

Update1 I will add here my "answers" to particular arguments here. I assume none of the processes run as root and have unnecessary capabilities (except for the system startup processes/scripts).

An argument: you can protect a web-server from running arbitrary shell-commands.

Answer: (Putting containerized web-apps aside,) one could add an allowing ACL for all commands the server UID/GID can access, and a forbidding ACL to the rest of the commands on the host.

An argument: a user can have a file with permissions 0777 [and essentially leak it to everyone in the system].

Answer: The system startup script can set default ACL to the directory where this file is created, so that whatever the user process creates in that directory will always get those ACL's inherited. In general having 7 in "others" seems like a bad idea and if the file gets such permissions, the discretionary policy could be enforced here at system rollout (distribution installation), or even at startup every time the system boots.

Student4K
  • 131
  • 2

4 Answers4

0

The distinction is in who decides the permissions on files. A DAC gives the owner of the file the full control of the file permissions. MAC uses labels to enforce a centralized control, which means there is an additional layer of security that is not up to owner of the file to decide. As an example, a user might have a file with rwxrwxrwx (777) permissions, but MAC enforces its rwx only to a specific set of security labels, effectively overriding DAC.

Manuel Herrera
  • 21
  • 2
0

DAC does not cover all potential security permission situations that MAC would. ACLs are very flexible compared to DAC.

For simplicity's sake, DAC only allows you to control rwx, right? With DAC, you can be much more explicit and on the syscall level control what is allowed. For example, you could allow someone to append to a file, but not overwrite/delete it.

Saustin
  • 311
  • 1
  • 10
-1

So is MAC "just additional layer of protection" without any real advantage on modern Linux system?

Not at all. MAC allows for much finer grained control beyond the typical Unix DAC model of users, groups, and filesystem permissions.

Take for example, a web server that has a vulnerability that allows an attacker to run arbitrary shell commands. MAC could be used to prevent the webserver process from executing any files or commands, thus greatly limiting what the attacker can do.

Also consider an untrusted application you want to run. By default, the untrusted program can access all of the sensitive files and documents available under the same user account. MAC could be used here to restrict what files and directories the program can access, even though it technically has correct permissions already.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
-3

In the information security field, it should be reminded that the overall security level of your system is equivalent to the weakest element in your stack.

For what I know a mandatory access control system is much more restrictive, and it takes much more time to define and implement.

So in conclusion:

  1. MAC isn't "an additional layer of protection", it is a different system of managing rights on your files.
  2. installing MAC without a proper administration of it, definition of rights, etc, is useless. discretionary access control is much more simple to administrate.
user933
  • 1
  • 2