Have you ever heard the term Orange Book? The Orange Book is one of the books in the so called Rainbow Series of the Department of Defense. In this series, each book has a differently colored cover. Actually it is titled Trusted Computer System Evaluation Criteria, but as it is the book with the orange cover, everybody simply calls it the Orange Book. It specifies requirements for computer systems in order to be certified for certain security labels. The most commonly known label probably is C2, which is what Windows NT is certified for. But in high security environments, such as financial institutions, C2 may not be secure enough for certain exposed servers. Here an operating system with a B1 or even B2 label can be a requirement.
``Is B1 security so much different?'', you might ask. The answer is yes. Basically, working with trusted systems such as HP's VirtualVault or Argus' PitBull, you are very much restricted in what you can do in a normal manner and thus have to retrain. The first exposure to such a system can be a quite a shock, depending on how familiar you already are with the unhardened target OS. The more proficient you are in day to day system administration and especially the more knowledgeable you are with the things under the hood, the easier it will be.
I had the opportunity to work briefly with VirtualVault a couple of years ago and have been working with PitBull until recently. Even though you are very unlikely to run these systems on your home machines, unless you have much pocket money to spare, the concepts may still be interesting, especially since such features start to show up in open source operating systems as well, such as TrustedBSD or Linux.
I'm not going to cover all the aspects of what is different in a trusted or a B1 level OS, such as integrity checking, auditing, print output labeling, documentation etc. Instead I will concentrate on the most interesting and useful features, which are also the ones I expect to appear in normal operating systems over short or long.
In every OS there is somebody who has the privilege to play god. In a single user OS, like DOS or Windows 95, this is the user itself. In multi user systems, like Windows NT or unix, this is a special account. This administrative account has the ability to bypass any restrictions. Under unix, where god is the user account named root and always has userID 0, this is usually done by checking what userID is running a command and bypass any restrictions if the userID is 0. If one person is responsible for all aspects of the machine, this is no problem. But what if you have a person responsible for the printing subsystem, another one for creating new user accounts and a third one for the mailing subsystem? Under normal unix they would all need access to the root account to do their job, even though they actually only need access to a subset of the functions which are available to root. With trusted operating systems, these administrative privileges are split up into numerous separate privileges which can be assigned to different users. So, for example, the guy responsible for the printing subsystem can be given the privileges necessary to manage everything to do with printing, but not anything else. Usually it is even possible to distribute privileges in such a way that one person can change configurations as necessary but not activate them and another account, which can not prepare changes, must then commit them.
And what about the original root or administrator account? The special privileges are taken away from these accounts, or at least can be disabled after installation.
Without even knowing the term, most people have an idea what DAC is and how it works. DAC stands for Discretionary Access Control and means as much as the access control flags for files and directories found on multi user operating systems. Under unix, each file and directory has a set of flags which determine read, write and execute access for the owner, the group and the rest of the world. These flags can be set by the owner of the file or directory, at the users discretion, thus the term discretionary access control.
MAC, which stands for Mandatory Access Control is a different pair of socks. The owner of the file has no influence over the MAC labeling of a file; it is system enforced or preset by the administrator. Basically it is a sensitivity label.
The difference between MAC and DAC is like geometry in two dimensions only with triangles, squares and circles (DAC) or geometry in a three dimensional room with cubes, cylinders, balls and pyramids (MAC).
In the DAC world, your file storage is a building with only one single floor. Your files are all the things in this room. There are chairs to use for anyone (anybody can execute the file), newspapers for anybody to read (anybody can read the file) and notepads for anybody to write on (anybody can write to the file). You also have your more valuable belongings in this room, like your bank booklet, which is locked away in a box to which only you have the key. In this example the box would be a directory to which you don't grant any other user access. Some things, however, are meant to be looked at by others, but they should not touch them, like the 10'000 piece jigsaw puzzle you did last year. Sure, you put it in a glass case, but if somebody stumbles and bumps against the glass case, intentionally or not, the contents can still end up in a mess.
With MAC, your file storage is a building with several floors. The bottom
one is called IMPLEMENTATION LOW, the top one TOP SECRET and
there are a couple of floors with different names in between, such as PUBLIC,
RESTRICTED etc. These floors are called sensitivity labels. There are,
however, no stairs between these floors! The ceilings of the rooms are special
mirrors; you can't see from a lower room to the upper ones, but you can see
all the rooms below you. What does this mean now? Well, in the room you are,
you can do exactly what you could do in the one room DAC environment; moving
the chair around, writing on the notepad and so on. You can even place new objects
into this room; take off you shoes and put them somewhere. Where in this MAC
world would you place aforementioned jigsaw puzzle? In the guest room on floor
three where all your guests can bump against it? No. If you put it above the
guest room, none of your guests can see it; above you would only put things
you don't want the guests to see. But what about leaving the jigsaw puzzle on
the ground floor? Everybody can see it as everybody can look down to it from
above, but there is no chance any guest will ever bump into it, as they are
not in the same room.
MAC is the concept of these various floors, or sensitivity labels. You can touch and see everything which is on your floor (provided DAC permissions allow it). If you create a new file, leave a new object, it will be placed in this room. You can also see everything in the rooms below you, but you can not touch or change it. Neither can you place new objects into the rooms below you. And for anything which is above you, there is no chance to even see it.
The different sensitivity labels, or floors, just discussed are not yet the full story. In addition to the vertical dimension of sensitivity labels, there is another horizontal dimension: compartments. These are like additional towers of rooms or additional buildings. A process or user can be a member of one or more such towers, just as you probably have access to your office building, your house and public buildings, but not to other people's home or other company buildings. A process or user can only act on resources, which are either not put in any compartment at all (as if in a publicly accessible building, such as the city office) or in one of the compartments the process or user has access to (your office building, your own house etc).
By using sensitivity labels and compartments you create an enormous grid of possible configurations. This allows the flexibility to really fine tune your security needs and protect applications and other resources from each other, but it also makes system administration much more difficult. And if at the same time you also have to think about MAC settings and the fact, that the root user can't do much and special privileges are required for most system administration tasks, then it can become really complicated.
Working with a trusted OS is a wonderful and extremely interesting experience, but can only be recommended to people who have a very good knowledge of the underlying non-trusted version of the OS and how various things work and interact. However, once you get the hang of it, a normal OS almost looks boring.
In the open source world such features are starting to appear and if you have time to play around with them, I'd recommend to do so, as these will be things to stay. In a couple of years MAC will be commonplace, I'm sure. With these features showing up in open source OS's over time, you luckily don't have to take the plunge into the cold water at once, as you do when changing to a fully B1 compliant OS, but you can take it in doses.
Kurt Keller 2003-02-14
© Algorithmica Japonica Copyright Notice: Copyright of material rests with the individual author. Articles may be reprinted by other user groups if the author and original publication are credited. Any other reproduction or use of material herein is prohibited without prior written permission from TPC. The mention of names of products without indication of Trademark or Registered Trademark status in no way implies that these products are not so protected by law.
January , 2003
The Newsletter of the Tokyo PC Users Group
Submissions : Editor
Tokyo PC Users Group, Post Office Box 103, Shibuya-Ku, Tokyo 150-8691, JAPAN