4

Many operating systems implement system capabilities, Posix access controls (DAC/ACLs) and mandatory access controls (SELinux), each using different underlying security controls to provide individual layers of security, thereby implementing the principle of defense-in-depth.

What if system capabilities, DAC and MAC were implemented using a common underlying security mechanism, would defense-in-depth still be achieved even though all three security controls have at least one common attack surface?

Whome
  • 1,231
  • 11
  • 21

3 Answers3

2

would defense-in-depth still be achieved even though all three security controls have at least one common attack surface?

No, you can see it very well with anti-virus software for instance: they look like defense in depth as they put protection systems at several layers (network firewall, browser plugin, process monitoring, file analyzing, etc.), however an attacker just has to defeat a single thing, the anti-virus software itself, to make the whole protection system to collapse.

As you correctly notice, the Linux kernel does not implement its authorization checks in a monolithic way, instead it uses a modular way where security modules (called LSM, see here and there for more information) can come from different providers and complete each other (hence the in-kernel DAC system can be completed with capabilities and a MAC system both coming as modules).

This offer several advantages, both in terms of freedom which is at the core of the GNU/Linux philosophy and security:

  • More freedom because a security module being not tightly integrated to the kernel, this allows a user (or more likely a distribution maintainer) to select the LSM better matching their needs (which, at the end, brings more security to the end-user). For instance some prefer AppArmor's security model, some prefer SELinux's one, etc.: the choice is not enforced by the Linux kernel development team. This is explicitly stated in the Wikipedia page previously linked:

    Linus Torvalds rejected SELinux at that time, because he observed that there are many different security projects in development, and since they all differ, the security community has not yet formed consensus on the ultimate security model. Instead, Linus charged the security community to "make it a module".

  • Security because of two reasons, which both end-up as being benefits from code isolation:

    • A correction made on one security feature should not cause any issue on another one. An update on SELinux for instance should not affect DAC or capabilities authorization systems as each one uses distinct code and data structures. This would not be the case if all this would be implemented as a single, monolithic piece of software.

    • A vulnerability affecting one security feature should not endanger the other ones. In case of vulnerability affecting SELinux for instance, such vulnerability will not void DAC and capabilities security systems as in the anti-virus example shown above where a vulnerability in the anti-virus software will most likely cancel all its security benefits.

Defense in depth should not be conceived as having simply several layers of security controls, instead it should merely be seen as having several layers of security systems. It is in fact the isolation between each systems which will bring you a good guaranty that it will take time for an attacker to defeat your security infrastructure.

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
0

I suspect that dac and mac are distinct enough that if you tried to minimize the code using common infrastructure, the amount of shared code would be small. Personally I'd do them separately, and then review and flag anything taht looked too similar...

davecb
  • 313
  • 1
  • 6
0

They do have a common attack surface: the kernel. DAC, MAC and capabilities all rely on the kernel for their implementation. So, faults in the kernel that allow remote execution of code will fail all such mechanisms, obviously. This also applies to Linux namespaces.

Fortunately, these security mechanisms reduce exposure to kernel APIs for unprivileged processes, and thus, risks associated with kernel vulnerabilities. Defense in depth should be that multiple boundaries need to be broken / systems need to be compromised, one after the other, for an adversary to benefit from an attacker. In the case of OSs and unprivileged processes, it's best to reason about the extent to which each layer protects APIs, rather than in a binary format.

For instance, if your namespace sandbox and SELinux policies allow direct memory access on GPUs, vulnerabilities related to GPU drivers may be easier to access so as to take the whole system down as if they didn't. So ultimately, there is a Single Point of Failure (the kernel here), there are many ways to interact with it (some dangerous, some not), there are vulnerabilities, and it's policy and configuration which will set the ease of attacking rather than the mere presence of security mechanisms.

Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45