Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Trusted Operating System Intro

By Miniluv in Technology
Fri Feb 23, 2001 at 10:43:56 AM EST
Tags: Security (all tags)
Security

This article is intended to serve as an introduction to the concepts of a trusted operating system. The term has been gaining popularity in the security community for the last 5 or 8 years, but only recently with the release of NSA Secure Linux, the sucess of Argus Pitbull in the eWeek Open Hack competition, and the launch of TrustedBSD as an extension to the FreeBSD system. Many people are still baffled by the concepts of trusted operating systems. People hear terms like C3, B1 and Common Criteria tossed around without really understanding what it means.


This article is not intended to be a thorough briefing on Information Security (InfoSec) but instead a guided tour of the basics, with plenty of resources for the interested user to pursue this further. Trusted is a somewhat misleading term when applied to an operating system, because you're not trying to restore trust in an OS. The US Government coined the term to apply to systems capable of securely handling classified materials, usually in a networked environment. Several of the major components of a trusted operating system are granularity, access control, and the lack of a single point of failure user account. This article will attempt to address each of those points to flesh out the general idea, without delving into the specific methods in w hich an operating system can approach the goal of qualifying as trusted.

Granularity
Granularity, simply stated, means the level of detail visible. The term is usually applied to computer security in several contexts, each of them with a slightly different spin. The first is in terms of access control. The granularity is the level of detail to which you can specify who gets access, from where, and when. Traditional Unix systems use permission "modes", generally read, write and execute. These modes are assignable to the owner, the group, and the world on any given file. Owner and group are specific as one of each and maintained as part of the file system, along with the file modes. Windows NT uses a different model, that of Access Control Lists (ACLs), which allows greater granularity. An access control list allows users to be specified as having any or all permissions, and usually also allows groups to be assigned permissions. Granularity also applies to the logging facilities provided for by an operating system. The two major granularity considerations in logging are when to log, and what to log. When to log implies decisions such as logging access attempts on restricted files, attempts to open privileged network sockets, etc. What to log is deciding which information is relevant, such as username, violation time, login method, and so on.

Access Control
Access control is simply the method by which the operating system determines what it will allow a user to do. Virtually ever major access control system operates on the concept of least privileged access. This means that if you are not explicitly allowed access, you are denied. If you are not listed as authorized to write to file X then the system will not allow you to. Access control is normally only a factor in terms of file system permissions, and on Unix systems which ports may be opened on the network. Trusted operating systems add another set of places in which access control gets monitored.

Access control differs in trusted environments from non-trusted most noticeably in the use of access control lists. ACLs, as stated earlier, are simply lists of users and groups authorized to access a file or directory in a specific way. Many trusted operating systems use ACLs as the starting point for concepts such as Mandatory Access Control, which is a fancy way to say that the system administrator can define what the minimum level of access is, and create a multi-tiered set of minimums. For example, you can create a MAC policy which says that any logged in user can create files in the folder called Public. It can define what the file permissions automatically are for those files, and it can further define other access levels for specific users. One of the best uses for this is in shutting down the usually Godlike power of the administrator, or root, account. With a MAC specifying that the administrator has no access to any file or directory unless certain conditions are met, breaches of security often provide no where near the access they would on a traditional system.

Another crucial aspect of access control is in regards to privileged system calls. Every modern operating system provides a myriad of system calls designed to make the life of programmers easier. Some of these calls provide access to highly privileged functions of the kernel and loaded kernel modules. Trusted systems do not take for granted that the other access control functions have actually done their job when a call to a privileged system function is made, instead reverifying their authentication tokens and comparing them against special ACLs that can be maintained on each and every function call. This sounds like an extreme bit of anal retentiveness, but is in fact one of the single most beneficial aspects of trusted security. Consider the following scenario:
Zero Cool, cracker extraordinaire, is attempting to penetrate the webserver at www.gibson.com. Gibson, Inc. is running a trusted operating system with well defined kernel level access controls. He manages to guess a user password, and circumvents file system permissions to get a specially written cgi script into the cgi-bin of their webserver. On most systems this would mean the game is over, and he has whatever access his cgi script is written to give him, which might include the ability to read/write any file via a browser interface, perhaps to change kernel configurations, put himself into the password file, whatever he wants. On a trusted system however many of these calls would be privileged, and thus he still is out of luck, as his stolen user id most likely doesn't have access to any of them. Even if he cracked the root account he still may not have enough access to gain the kind of control necessary to deface the website, or steal credit card information, or whatever else he is after.

Single point of access failure
In a traditional OS there is one all powerful account. On Unix systems it's called "root"; Windows calls it "Administrator"; others have called it "System", "Manager", etc. As long as you knew which account it was, you had your target to gaining complete control of a machine. Trusted Systems allow this access to be fragmented in such a way that in order to gain complete control over every aspect of the machines operation an attacker may need to penetrate a dozen or more accounts. With proper detection mechanisms this is often more work than can be accomplished in secret, despite the first account or two going unnoticed. This is further enhanced by the ability to define specific privilege levels to accounts based on where they are logged in from, be it the console, a specific IP, or with a specific IPSec public key.

Generally speaking, trusted operating systems are not the right choice for deployment in most scenarios. They are not well suited to being departmental file servers, internal web servers, or desktops. Instead they are intended to be used in conjunction with network based intrusion detection, firewalls, and other devices serving to force traffic through controlled choke points before being given access to sensitive data. While they do add a burden of work for the system administrator, they can be the difference between data pilferage and security. For anybody interested in the future of computer security, I highly recommend downloading one of the many free trial, or freely distributed, sets of extensions available to many popular operating systems and seeing what sort of configuration options they offer.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Favorite Trusted OS
o Trusted Solaris 5%
o Trusted AIX 1%
o HP Virtual Vault 1%
o SE Linux 4%
o TrustedBSD 18%
o Windows 95a 68%

Votes: 74
Results | Other Polls

Related Links
o NSA Secure Linux
o Argus Pitbull
o Open Hack
o TrustedBSD
o Common Criteria
o Information Security (InfoSec)
o Also by Miniluv


Display: Sort:
Trusted Operating System Intro | 31 comments (23 topical, 8 editorial, 0 hidden)
Domain and Type Enforcement (4.60 / 5) (#6)
by khym on Fri Feb 23, 2001 at 06:25:16 AM EST

I don't know if this fits into what you're discussing, but...

Another way of securing a system is known as Domain and Type Enforcement, or DTE. Processes (running applications and tools) each have a domain, while files have types. Each domain has permissions for executing (running), reading, and writing the various types; also, each domain has a list of domains that it can (or can't) communicate with.

So, for the web server example, the web server would have its own domain, and all of the cgi processes it ran would have that same domain. The password file would have it's own type, and the web server domain would have no permission to read (or even write) to that type; various other sensitives files would have other types, and the web server domain would have no write access to those types.



--
Give a man a match, and he'll be warm for a minute, but set him on fire, and he'll be warm for the rest of his life.
ACLs (4.50 / 2) (#8)
by Simon Kinahan on Fri Feb 23, 2001 at 09:21:48 AM EST

I am not sure the account of ACLs in the article really captures the difference between an ACL and the Unix user/group/all read/write/execute system. ACLs not only allow for more permissions to be defined (including granting the right to change permissions distinct from write access and so on), but also allows more than one group to be given rights to the file.

In the conventional Unix model, one chosen group can be given some level of access to a file. In an ACL model, more than one group can be chosen, and each group can have different levels of access.

Simon

If you disagree, post, don't moderate
Strictly speaking, (none / 0) (#26)
by jovlinger on Fri Feb 23, 2001 at 05:15:04 PM EST

couldn't we model ACLs by having one group per file (ignoring that this would probably exceed the maximum number of groups most Unices support)? Then everyone who should have access could be part of the group for that file.

Oh, I guess that would only allow you to emulate one access control list, where most ACL implementation have several.

But it's friday, I'm not at my best

[ Parent ]
I've wanted these things... (none / 0) (#11)
by tnt on Fri Feb 23, 2001 at 10:45:04 AM EST

I've wanted many of these things for a long time (on Unix-like systems).

I definitely want the ability to give specific people and groups certain permissions. Does anyone know if this, the ACL stuff, is being added to the main Linux code?

Also, it would be nice if people could join multiple groups. And even create their own groups. In my (very ignorant) understanding of how groups work (on Unix-like systems) this is not possible. Is this possible with these Secure-OSs?



--
     Charles Iliya Krempeaux, B.Sc.
__________________________________________________
  Kuro5hin user #279

Groups (none / 0) (#12)
by Devil Ducky on Fri Feb 23, 2001 at 11:01:23 AM EST

People can be in many groups. I don't remember how off the top of my head how, but it is possible.

My user is in the groups: "users", "greg", "admin", and another one I dont remember right now. Where has my memory gone today?

I agree though, people being able to create their own (permission-locked) groups may be a good idea in certain situations, but certainly not on a trusted OS.

Devil Ducky

Immune to the Forces of Duct Tape
Day trading at it's Funnest
[ Parent ]
From a `users point of view' (4.00 / 1) (#13)
by tnt on Fri Feb 23, 2001 at 11:36:52 AM EST

I agree though, people being able to create their own (permission-locked) groups may be a good idea in certain situations, but certainly not on a trusted OS.

My `wanting' for users being able to create their own groups is from a `users' point of view (... not an `administrators' point of view).

BTW, why won't you want to have this on a Trusted-OS?



--
     Charles Iliya Krempeaux, B.Sc.
__________________________________________________
  Kuro5hin user #279

[ Parent ]
Not Trusted (none / 0) (#21)
by Devil Ducky on Fri Feb 23, 2001 at 01:49:08 PM EST

The biggest security problem on most UNIX systems is (IMHO) lazy admistrators.

I, too, am at fault at this, for example: for several years my gateway server had the telnet port opened, I knew it was opened, I knew how to fix it, I just didn't. (Don't traceroute me now, it's closed; all that's open is ssh on a different port number)

On a trusted system, we would had gone through all of this trouble to split up root's power, thus stopping one user account from being able to ruin an entire system; now a system admistrator can combine all of the seperate power users into one group ths allowing themselves to be lazy again (not all, just some of them). But, with user controlled groups, I could addmyself to a group with the roots, I wouldn't know what to do with this but some 37337 h4x0r might.

Devil Ducky

Immune to the Forces of Duct Tape
Day trading at it's Funnest
[ Parent ]
I know how now (3.00 / 1) (#16)
by tnt on Fri Feb 23, 2001 at 12:36:36 PM EST

Thanks! for letting me know that users (on Unix-like) systems can be in multiple groups. (After looking around for a bit for information) I think I understand how this group thing work now.

Basically, the way I understand it now is, just like a file or directory has a `user owner' (with various permissions), it also has a `group' owner (with various permissions). [Although, I'm still not sure how the system decides what `group' gets ownership when a `user' creates a new file or directory. Maybe it decides based on the owner of the current directory? But I'm not sure.]

To create a group, use the groupadd command. For example, you could use it as:

groupadd name_of_group

To see what groups you are in, use the id command.

To add a user to a new group (you created), edit the /etc/group file. A typical entry (line) in it might look like:

adm:x:1:root,bin,daemon
[The adm part is the group name. I don't know what the x represents. The number 1 is the group number I think. And the list at the end -- root,bin,daemon -- is the list of users in the group.] If you want to add a user to the group, just add their name to the list.

Why is this useful? Well, say a group of users want to share files. Well then, the administration can

  1. create a new group (like described above).
  2. Add the users to that group (like described above).
  3. Create a new directory for them (to share files from).
The last one (number 3) could be accomplished with:
mkdir /whatever/dir/you/want
chgrp name_of_group /whatever/dir/you/want
chmod 770 /whatever/dir/you/want
Of course if you wanted to share files in your home directory, or whatever, you could. Just use chgrp to change the group of that file or directory (where ever that may be) to the group you want to share with (and make sure the group permissions are properly set!).



--
     Charles Iliya Krempeaux, B.Sc.
__________________________________________________
  Kuro5hin user #279

[ Parent ]
Must Be Administrator (root) to do most of it (none / 0) (#17)
by tnt on Fri Feb 23, 2001 at 12:40:34 PM EST

I forgot to mention that you need to be the administrator (root) to create new groups, and add users to that group.

But the rest of the stuff can be done by normal users.



--
     Charles Iliya Krempeaux, B.Sc.
__________________________________________________
  Kuro5hin user #279

[ Parent ]
/etc/group (none / 0) (#19)
by Devil Ducky on Fri Feb 23, 2001 at 01:42:19 PM EST

the first one is the name of the group, you can also refer to a group by it's number ex: chgrp 1004 foo/bar.tmp

The x is a shadow password (IIRC).

A file is designated a group based on the owner's primary group. On most sytems this is your own private group. So uid "vegata" touchs a file "foo.bar", the ls -l would be:
-rw-r--r-- 1 vegeta vegata 0 Feb 23 13:44 foo.bar
The group does not depend on who owns the directory, all that matters is if the user can make a file in the directory.

Devil Ducky

Immune to the Forces of Duct Tape
Day trading at it's Funnest
[ Parent ]
the "x" field in /etc/group (none / 0) (#20)
by hag on Fri Feb 23, 2001 at 01:48:56 PM EST

The adm part is the group name. I don't know what the x represents.

The "x" is a holdover from older systemV group handling, where users could belong to only one group at a time (no supplemental group list). Users used the newgrp utility to change group membership. newgrp could optionally require a password for non-group members to join the group. The x field held the password hash.



[ Parent ]
Links (none / 0) (#18)
by lunarn on Fri Feb 23, 2001 at 12:43:37 PM EST

You might want to check out this web-site: http://www.braysystems.com/linux/trustees.html

And here is a short article about capabilities and ACL in Linux


Arnar
Document code? Why do you think they call it "code?"
[ Parent ]
What else this article needs (4.00 / 2) (#14)
by Skippy on Fri Feb 23, 2001 at 11:54:06 AM EST

I think that coverage of current research would be interesting. I was kind of surprised not to see EROS mentioned. I don't understand the concept very well, but it is interesting. Go check it out.

# I am now finished talking out my ass about things that I am not qualified to discuss. #
EROS, etc. (4.50 / 2) (#22)
by jason on Fri Feb 23, 2001 at 02:37:45 PM EST

The basic concept behind the security / reliability of KeyKOS, EROS, Nemesis, Mungi, et al. is that you cannot influence what you do not know.

Knowledge within the system is essentially controlled by capabilities. A capability is just a name. Think about it. You cannot influence what you cannot name. Two modules of a program that do not know of each other cannot cause errors in the other. (Pointers are universal names for every piece of the program.) It's a simple concept, but applying it uniformly while still allowing work to get done is difficult. Read the capability μ-essays at Norman Hardy's site. While there, read the rest of it, too.

It's also notable that none of the systems separate secutity from reliabilty. They are one and the same. Don't expect to see your favorite Unix running something as secure and reliable as these systems, but seeing these run your favorite Unix in a controlled environment (like, oh, an S390) is perfectly feasible.

Jason

[ Parent ]

Trusted systems are anything but... (3.33 / 6) (#15)
by trhurler on Fri Feb 23, 2001 at 12:31:03 PM EST

Almost every "trusted system" I've ever seen was an insecure codebase full of basic programming mistakes(buffer overruns, etc) to which someone added a very complicated set of auditing, authentication, and access control mechanisms, which ALSO are full of basic programming mistakes. The result is a system on which you have very fine grained control, provided everyone who ever accesses the system is technically inept, and no control whatsoever if any of them knows how to write or can find on the web any exploit code.

The amusing part is, the systems with all this extra complicated code are rarely used for what they were intended for, and they are actually less secure, owing to added complexity and lots more buggy security-vital code. Trusted systems are a sad joke.

By the way, I considered applying to work for Argus. Their pitbull product is probably as close to a trustworthy trusted system as anything that exists. They've got some downright godlike people working on that product, from what I can tell. However, I still would prefer not to use a "secure" product whose source is only available to a handful of people, because even if they're good, the odds that they've actually removed even just all the easy flaws from something the size of, say, Solaris, are not very high. As for "Trusted BSD" I'll bet money FreeBSD is more secure without that code than with it, but it doesn't much matter since it is a guarantee that there are exploitable errors in it either way.

--
'God dammit, your posts make me hard.' --LilDebbie

Exactly! (2.50 / 2) (#25)
by YellowBook on Fri Feb 23, 2001 at 05:14:04 PM EST

This is what I'm always telling people (ACL fans, generally). Unix security is lousy, but it's lousy in simple, well-understood ways. Any security model fundamentally more complex than Unix's lets you very easily produce security setups that you don't understand and can't control.



[ Parent ]
I don't quite agree (4.66 / 3) (#27)
by trhurler on Fri Feb 23, 2001 at 06:27:43 PM EST

My problem with trusted systems is that their complexity makes them buggy. If you had one properly implemented and run by someone intelligent and properly trained, there's no reason their complexity would necessarily lead to poor security configurations. The military, in fact, has operated such machines for quite a long time and found them useful in limited roles.

I've worked on systems with ACLs, too. They can be nasty if users don't understand them, but so can the Unix security model, and really, acls aren't harder to understand - they're conceptually much simpler. I don't care for them in general, but they work well.

All that aside, though, they're usually not necessary, and I've never seen a Unix-based implementation of acls or priveleges or anything like them that I had any reason to presume actually increased the security of the system it was a part of. Complexity makes bugs. Bugs make security holes. Therefore, complex security mechanisms make security holes. Life's a bitch.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Why Unix and ACLs tend not to mix (4.66 / 3) (#28)
by Miniluv on Fri Feb 23, 2001 at 09:35:41 PM EST

I suspect one of the basic reasons that your experiences are what they have been is that the Unix world refuses to throw away code. Code reuse is great, when it makes sense, but when you're attempting to change the security paradigm in such a major way you shouldn't be grafting extensions onto things.

I suspect the TrustedBSD project will learn this before long when they find that attempting to graft ACLs onto FFS without a complete rewrite just doesn't work.

Conceptually speaking, ACLs could be a lot more useful than people tend to make them, and this is usually because administration tools are always the final consideration, rather than an integral part of OS design. There is no reason anymore that every tool for administrating an OS must be CLI, instead of at least a curses based gui, if not a real GUI if that's what makes effective administration easiest.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

ACL implementation (4.00 / 2) (#29)
by trhurler on Fri Feb 23, 2001 at 09:52:16 PM EST

My problem with them wasn't any functional difficulty. They worked. If you knew how they worked, they worked really well. However, I still don't like them as a concept.

As for acls on Unix, people ought to just buck up and extend the vfs to have persistent storage and then implement common fs needs like acl support there. If they did, they could have acls with little or no change to any existing filesystem, and a new filesystem would have acls with almost no extra effort needed. However, I don't really want acls on Unix. POSIXish capability lists are nice, if you can do them right, but nobody appears to be capable of that. They add something of real value: a way to reduce the impact of holes in setuid and setgid programs. ACLs add a lot of management overhead, the possibility of some really bad social engineering and/or semantic attacks, and a great deal of code complexity which reduces overall security, and they don't add enough extra flexibility to your security system to make them worth all that, IMHO.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Multics, IIRC (4.00 / 2) (#23)
by Captain_Tenille on Fri Feb 23, 2001 at 03:51:31 PM EST

Was the first (and so far, only) operating system to be certified B1 out of the box. It implemented a lot of the functionality discussed here, such as limiting system calls, protected memory, etc. Of course, some of these ideas were brought into UNIX, but many of them were either too cumbersome or just not practical.

IMHO, trusted OS designers could learn a lot from looking at the ideas Multics tried to implement, but failed for what ever reason.
----
/* You are not expected to understand this. */

Man Vs. Nature: The Road to Victory!

DAC vs MAC (4.33 / 3) (#24)
by zephiros on Fri Feb 23, 2001 at 03:58:08 PM EST

One of the key selling points of Mandatory Access Control (vs. Discretionary Access Control) is that it's highly resistant to user-based subversion. Really, this feature is a lot more useful in a military environment than, say, an e-commerce server. For example:

User Adam can read Seekrits.txt, which contains a huge list of undercover agent names and addresses. Unfortunately, Adam is not allowed to print to the public laser printer in the administrative office. User Betty can print to the public laser printer, but she's not allowed to read Seekrits.txt.

Under a DAC system, Adam can make his own, private copy of Seekits.txt, and then (since he owns the file) change the permissions such that Betty can read it. Betty can now print the secret file to an insecure printer. Under a MAC system, even if Adam makes his own copy, he can't change the permissions such that Betty can read it (because Betty wasn't able to read the original).

Likewise, under a DAC system, an evil Betty could send Adam a trojan that copies Seekrits.txt and changes permissions on the new file. Under a MAC system, no program run by Adam (ever, ever) would be able to make data from Seekrits.txt available to Betty.

Of course, all of this only works within the confines of the system. Adam could write out all the names. If Adam was accessing the trusted system through a GUI terminal app, he could cut and paste the data. Adam could videotape a listing of the file. As usual, security is a holistic process, not a set of policies or applications.

Folks who are interested in this sort of thing should probably take a peek at the NCSC rainbow books. While aging, they still represent (IMO) the best single repository of security theory.
 
Kuro5hin is full of mostly freaks and hostile lunatics - KTB

computing. (none / 0) (#30)
by Bridge Troll on Mon Feb 26, 2001 at 09:51:39 PM EST

Is the concept of a secure OS even viable? Why would storing information on a computer be the best decision for storing text based data? Wouldn't it be better to have it in a safe with armed guards if it is so important? They would know if someone was trying to subvert a large notebook/binder/folder etc. better than a computer, because it would require constant looking over of shoulders as to what commands were being entered or what widgets clicked and the paper would involve checking for cameras before they enter the safe.


And besides, pounding your meat with a club is a very satisfying thing to do :) -- Sleepy
LIDS (none / 0) (#31)
by adric on Fri Mar 09, 2001 at 05:01:01 AM EST

Does anybody know any data about the security of the LIDS code that would care to contribute to this discussion?

The LIDS Project, at http://www.lids.org distributes kernel patches which add a few interesting capabilities to the Linux kernel, including a kernel security level much like the one in (Open)BSD (AFAI can tell) which along with their MAC (see article) and capabilities code would seem to help immensely in locking down a Linux box.

So, have any of y'all put it through it's paces or played with it at all?

Quite curious,

adric@ccactus.com



Trusted Operating System Intro | 31 comments (23 topical, 8 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!