SystemsSec 2016W Lecture 6

Topics & Readings

• Ethical Hacking
• Security mechanisms in operating systems
• Danger of root

Ethical Hacking

Red team: when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers. Blue team: defence team.

The naming convention comes from US politics where the red team gets it's name from the 'evil' communists and blue represents the 'good' Americans. Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.

A separate question: How much does this actually improve security? The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur. But do actual people doing ethical hacking on software actually improve software then?

Security mechanisms in operating systems

MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks. The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions) Diagram detailing the separation of root into three roots.

Diagram detailing the separation of root into three roots

The Danger of Root

Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration. We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.

We need even finer grain control though, however most software developers don't want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it. To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?

Conclusions

Almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don't know how to do it, but it's because we don't want to commit to the correct way of doing things which is why it's all ugly, it's like Xwindow which draws windows and elements but delegates the elements to the operating system.