Howto: Understand Secure Systems
This document is intended to introduce users to important trusted operating system (TOS) themes and exploring their practicality within commercial environments.
You all know about hardening your web server, RDBMS, web applications, and even your operating system to protect e-commerce servers, but is this enough?
Do you know how to protect against zero day exploits? Do your admins need to watch bugtraq 24/7? What about flawed services, misconfigurations, and insider attacks?
Many admins and open source developers in particular seem to feel that trusted operating systems have nothing to offer modern day commercial computing, and this is both unfortunate and entirely untrue. Although a full blown ultra high assurance TOS is likely not right for you, many single common TOS mechanisms will greatly enhance the security of a given system. For example:
Hierarchical mandatory access controls (MAC : both confidentiality and integrity)
Compartments
Least privilege
System operator accounts (i.e. lack of a root/super user account)
Network/interface flags
Finely grained access control lists
To name just a few. For the scope of this document I'd like to touch on Hierarchical MAC regarding confidentiality and why, although it is a huge security advantage, it is ill suited for typical commercial applications. Additionally I will also touch on least privilege, operator accounts, and network flags. (ACL's are a whole different animal which would many of you are already familiar with from NT and a few UN*X flavors.) The primary focus of this will be the simple power of compartments or as some systems call them, domains.
Hierarchical MAC:
This model was formalized in its most common/popular form be the Bell-LaPadula paper back in 1976. I am not going to delve too deeply into the specifics of this model (which can be found here: http://www.antionline.com/showthread...023#post672023 ) beyond its two primary points and one secondary point. This model uses a collection of level, typically from UNCLASSIFIED to TOP SECRET with stops and CONFIDENTIAL and SECRET on the way. Some systems have considerably more levels (the most I've heard of is 64) but this is enough to convey the concept. With these levels the two primary rules are:
Subjects (such as users and processes) cannot write to objects (files and subjects) of a lower security level than itself.
Subjects may not read from objects of a higher security level than itself.
The aggregate of these two rules in their absolute is that classified material can never be disclosed to anyone that lacks the proper clearance. For military uses this is VERY important, but in commercial uses it merely gives the data owner one more thing to worry about, classification of material security levels. Additionally it is typical for a user to not just exist in one security level. My account might read like this:
username: catch
password: *
min_level: CONFIDENTIAL
max_level: SECRET
And when I logon to the system I will be prompted for my username, password, and level (it is possible for each level to have a different password in the event a password is compromised the damage is limited) this is useful if I wish to write to the level CONFIDENTIAL, which I could not do after login on at SECRET. On the other hand I may desire to read documents from the SECRET level, which I cannot do from CONFIDENTIAL, even if they are my own documents! Can you imagine what would happen to your tech support team if you suddenly implemented this mechanism in your workplace? It wouldn't be pretty, CONFIDENTIAL users couldn't print or email documents as the printers and email clients would be UNCLASSIFIED.
Now you are thinking, "that is pretty complicated for a normal work place, but a few training sessions might cover it nicely. Hahaha consider this, do you want UNCLASSIFIED subjects writing to TOP SECRET objects? Maybe, maybe not... this policy doesn't protect that though... so now integrity is a concern. Here we have the Biba model from 1978 that is just like the Bell-LaPadula model... only upside-down! So now subjects can write to objects of lower integrity levels but can only read to objects of higher integrity levels! Now the user needs to keep track of both confidentiality and integrity labels which work inversely to each other, rest assured you will need to hire new, MUCH more expensive admins to manage this and prolly increase your internal support staff by 10x. All of this is in addition to the normal permission bits you are used to. (UN*X's rwx and NT's ACLs for example)
You may remember that I said this model had a secondary requirement. That secondary element is for use in administrating these systems. If this system is left unattended it will naturally make itself more and more secure until it is no longer useful, which is quite the opposite of most systems you are used to. Consider this:
UNCLASSIFIED phone book + TOP SECRET phone number = TOP SECRET phone book
HIGH INTEGRITY source code + LOW INTEGRITY function = LOW INTEGRITY source code
As you can see, the system will naturally migrate to the highest confidentiality level and the lowest integrity level. The only way to deal with this is by violating the security policies. For this task trusted subjects are required. Trusted subjects are processes that have been formally verified for correctness. Formal verification is a long and expensive process, beyond the reach of all but a few software developers and custom in-house solutions are completely infeasible.
All of this adds up to the simple fact that hierarchical MAC is typically a bad commercial solution, and consequently is not seen in many commercial off the shelf (COTS) systems. This also explains the stigma that TOSes suffer regarding their viability in the commercial marketplace. However, let us have a look at a few other TOS mechanisms and see how useful they are.
Compartments/Domains:
These are similar to the hierarchical MAC in that security is removed from the UID and placed on unchangeable aspects however here it works slightly differently. Rather than using predefined labels, the system can be divided up as seen fit by the administration, a system that operates as a static page web server would most likely only have one compartment:
COMPARTMENT:WEB_SERVER
To start with now all WEB_SERVER subjects can only access WEB_SERVER objects even if that subject is root/super user. Most importantly these compartment labels cannot be changed from within the compartment. This is a good start but still leaves many concerns, but luckily for us most compartment implementations deal with these as well. In addition to the compartment itself, you can add access controls to the compartment so now we can have our web server set to WEB_SERVER(rwx), all of our static web data set to WEB_SERVER(r), Our web logs at WEB_SERVER(w) and our active content at WEB_SERVER(rx).
The benefits of this should be clearer now. You web server is now 0-day secure as it is no longer possible to exploit the web server to leverage system level access. Even though the attacker switches to root, they are still bound by the rules of the compartment. This system however is still a bit clumsy for more sophisticated/complicated servers, luckily it is possible for subjects and objects to exist in multiple compartments:
file_that _writes_to_a_db COMPARTMENT:WEB_SERVER(x), DATABASE(w)
database COMPARTMENT:DATABASE(rw),WEB_SERVER()
It should be noted that some domain based access control (DBAC) systems require full dominance to write, so in this example the file would need to completely dominate the database in order to write to it, that is to have the same if not more rights. DATABASE(w) becomes DATABASE(rw). The reason for this is to assure that less privileged subjects cannot write to more privileged objects.
The end result of this system is that any individual compromise is not enough to break the system. An attacker now needs to compromise the compartment as well, and unlike switching UID where you can leverage weak services, there is no such leverage point to switch one's compartment.
This model is an excellent match for nearly all commercial level servers as a result of the low administration requirements, local admins will likely logon to no compartment (though some systems use a DBAC_AWARE flag) and thus can administer the system as normal. And it dramatically enhances system security by enhancing the system's ability to withstand remote compromise.
Least Privilege/System Operators:
These are very simple, you want to reduce any single subject's power, including root. You want your web server to bind itself to a privileged port? Well I guess it needs to run as a privileged account, but what if you could just grant the server the bind_to_priv_port privilege? Now if the service is flawed and subsequently compromised, the only privilege granted to the attack is the ability to bind stuff to ports. Which although this is a nice to have it pales in comparison to super user privileges.
The next step is adding system operators. A common approach is to break root into three parts:
SA (System Administrator) this role handles things like creating accounts, managing software/hardware, and little things like system time.
SO (System Operator) this role handles the system logs and backups
SSO (System Security Operator) this account handles all security aspects. Assigning rights to new accounts, altering security settings and the take ownership permission.
As you can see, now to have complete control over the system requires the compromise of at least three accounts! (Perhaps even more, as they can be broken down even further) So even with only the addition of system operators, you will still retain the logs even if you are compromised. (Those of you with NT backgrounds should already be familiar with the power of system operators)
Both least privilege and system operators greatly enhance the security of a system without a large increase in complexity. Least privilege in particular merely seeks to remove privileges that should never be used so the system should function exactly the same before and after their introduction to a system. System operators are an admin level change only and will not effect users so their impact is also minimal in terms of cost and disruption.
Network/Interface Flags:
This very simple system is much like DBAC, only more straightforward. When a user connects to the system they are assigned a flag based on the interface/port number they've connected from. This flag propagates to all children of the subject and all objects created by the subject. For example an attacker connects via http/port 80 and compromises the web server. Next they attempt to delete the logs and even though they may be running as root and have full permissions on the logs, the logs only allow access from local sources. The system denies access based on the subject's PORT:80 status. The same is true for any other system level access the attacker attempts.
What if the attacker tries to deface the site altering files that are intended to be accessed via PORT:80? Here again this may be coupled with DBAC or permissions may be assigned as well, so PORT:80(r) for example but in this case dominance is not an issue, merely that the user has the right flag.
What about situations where objects are accessible by multiple services (a user's home dir is ssh/ftp/http accessible)? It would be possible to allow multiple flags to objects, but a far simpler approach is to merely assign the object the flag of the adapter eth1, this is used for simplicity of administration, but can also be used to separate permissions on a system that can be reached via the LAN or the Internet. Assigning private_sales_numbers eth0 flag will assure that it can never be accessed by the outside world (assuming eth0 is your internal adapter of course. heh) Local terminal adapters may be used as well to ensure that something is never accessed remotely. this also works in reverse, if a remote attacker loads a trojan horse onto the system, local users will not be allowed to run it as it will have the external network flag, unless the SSO comes along and changes it.
This system too is minimal effort on the admin and in the server environment typically no user effect whatsoever. This coupled with its ability to protect the system from many attacks makes it a highly desirable commercial solution.
I hope this has broken some of the stigma surrounding trusted operating systems and for others of you, perhaps opened your eyes to the kinds and level of security solutions that exist above and beyond the NT/UN*X realm.
catch
EDITED: smilies disabled
