Slashdot Mirror

That's a silly reason for plugging DRM. Simply mount all user-writable space with option "noexec" and you have the same level of security.

Life is more complicated than that. Regular binaries can be run as: /lib/ld-linux.so /noexeced_path/myprog

Even locking this out, any available program that is itself an interpreter (e.g. Perl, etc.) can be used to run code. Assume that any attacker (or their scripts) know this and will leverage it.

I'm seriously beginning to think that we won't be able to achieve secure systems that reliably push the security problem to the social boundary until ground-up designs such as the Extremely Reliable Operating System mature.

(Warning, ignorance ahead.)

I think a capability system (ex. EROS) is theoretically invulnerable because a virus would never have the rights it needs to infect. I barely understand how a capability system works, but I think it goes like this:

Your e-mail client (for example) can't see anything but itself and e-mail (not even the file system), and it doesn't have authority to write onto itself.

This is possible because every process or program has it's own set of "keys" that grant it rights to see/read/write/modify/execute a file, resource, or process. This is in comparison to giving universal rights/limits to users which apply equally to every process and program run under that username.

I've been looking at FAQs and asking questions here and there, but never got a grasp at how it secures without disabling the ability to administer a computer or what it means for viruses.

Anyone?

You are claiming that it's impossible to write a secure OS, such that a naive user cannot (or at least is very unlikely to) have his system compromised?

Or is it just that it hasn't been done, yet?

Certainly there have been some promising attempts towards this goal -- but the market apparently isn't ready yet to take such things seriously.

His second part is way off the mark. Firewalls and timely patching are not what result in security. What does lead to security? Security by design.

What is security by design? Isolation and containment. The best way to achieve isolation and containment is with a capabilities-based system (Eros for example). This way, when one piece of the system has an error, it is contained and cannot cause harm outside of itself. Another system that has many levels of containment is a virtual machine system like Java. Java does not allow access to memory or manipulation of pointers, and bytecode correctness is checked by a theorm prover before it is run (among many other security features).

These approaches lead to security. They accept that code will not be perfect. Timeliness of patching has nothing to do with this.

ACLs are probably not even a part of any secure solution, and are not very useful for secure computing. That when comparing them to capabilities.

POSIX has done a very bad service to the computing world by defining the term POSIX capability contraductory to the original term.

POSIX capabilities are more like ACLs than real capabilities.

The biggest problem right now is the root user, IMHO. You just need root privileges too often, and in classical Unix, you either are root, or you are not. There is, however, no reason why my MTA has to be able to change everybodys passwords, write to raw disks, load kernel modules or modify packet filter rules just because it has to listen on port 25. Capabilities fix just that: You can grant a process the capability to listen on a port < 1024 without neccessarily granting it anything else.

File system permissions are less critical, but cumbersome. Imagine a file that should be readable by the members of two groups, for example. No easy way in classical Unix except creating a new group with the members of them both, and you have to keep them in synch manually. It gets worse if you want to make sure that people don't accidentally (or with malicious intent, but that is a lost battle in most cases) don't leak things they may legitimatly work with to others who don't. Mandatory Access Controls (MAC) make this possible, but it is a lot of work to set up - basically, you define a context of users, objects (like files) and processes to work on them that is hopefully safe, and the system forbids anything else - you might be allowed to view a file in a browser, but not to copy it to another file with different permissions, for example.

As I said, things like Capabilities or MAC are becoming more common. There are, as usual, kernel patches for Linux, FreeBSD 5 has this kind of things, proprietary Unixes sometimes have special "Trusted" versions with these features.

For more insight about the Unix models, I suggest reading some of the papers written by the Eros project, or the Unix Haters Handbook, where some Multics people talk about that. Asking VMS veterans can also be enlightening.

You just can't go over millions of lines of code and spot every bug that can result in a security breach

That's why really secure OSes don't have millions of lines of security-critical code.

Yes, it's called EROS.

we have to convey the message that we find it acceptable to pay for some software that will run in Linux.

What you meant to say was:

We need to communicate that we are willing to give up our freedom and put up with binary crapware, just as long as we can use our leet new toys.


Some of us care more about freedom than HDTV. We need to encourage hardware companies to open their specs. Linux is not alone in the world as an alternative OS, and I sure as fuck hope that something better does come along some day. I don't think we want to be stuck emulating shifting Linux kernel interfaces to use some hardware on our shiny new EROS boxes ( yeah, right) in 2010.

I agree though, that going with a microkernels are better way to construct stuff that even might work..

As far as I know, most viruses in their execution work using common OS scripts and commands.

As far as I know, most Windows viruses can't spread without either 1. opening an outgoing connection on SMTP's port, 2. telling Outlook to open an outgoing connection on SMTP's port, or 3. opening executables installed by the administrator for writing. Not giving unknown programs the capability to do this would stop viruses from spreading. This is possible even in a Windows environment: don't allow unknown programs to open connections to ports they have no business with (e.g. only Postfix should open an SMTP session), don't give users the right to overwrite files outside of the temp directory and the user's home directory, and run executable e-mail attachments as the Guest user.

Well, you're both talking nonsense. EROS does have orthogonal persistence, which does away with *much of* the need to deal with files in typical applications, but EROS does deal with files and file systems - they haven't been thrown away. So yes you can share files over the network (for example).

"Orthogonal Persistence = leave machine on indefinitely." Eh? The data has been persisted (ie 'written to secondary storage'), you turn off whenever you like, the machine will come back up in a consistent state. That's the whole *point* of EROS. What about backups? You just back up the memory checkpoints. The memory is written to a filesystem you can back up like any other.

I'm sure the AC above knows something about BSD and may have simply been mislead by the hopelessly inaccurate picture of EROS given in the first post. I think this paragraph from one of the EROS introductory essays gives a more balanced, less gushing, view of its abilities:

"The moral of the story is that mechanisms for explicit persistence are necessary to support databases applications. My view, however, is that these applications are the exceptional case. Most applications should not have to deal with files or persistence at all. EROS shows that transparent persistence is feasible and efficient."

Relational databases are better than conventional file systems in both performance and transaction management/journalling.

However, the best solution is that used by EROS, which is for the kernel not to provide a file system at all, but instead provide Orthogonal Persistence.

This is a much simpler layer for applications, since it doesn't require them to explicitly access the memory and disk separately. It is also much simpler to recover from because the entire state of the whole disk is always known to be coherent with itself at all given points in time, without an expensive journal.

In terms of performance - it beats the hell out of explicit disk access systems (Both conventional and database systems) because it performs big continuous reads and writes (that don't move the head much) rather than small writes on metadata and file data that forcibly jump the disk head around.

In EROS then, on top of the Orthogonal Persistence, you can create any arbitrary Objects you want easily - because they're just normal processes with normal memory. Conventional File Systems become useless and objects implemented by processes become a much better and more powerful alternative to files.

A relational database of the user objects is then much more powerful than a string hierarchy, but this is all the user's choice - and not hardcoded into a kernel.

This game is actually very sophisticated with a natural way of expressing concurrency. www.toontalk.com The author is active in the capability based security world. By "capability" I mean the definition used in the security literature, not the linux bastardization of the term.

1) anything that is capable of running a browser that weighs in like mozilla (or IE, opera, etc) already can run mozilla natively.

There are allready steps in place towards recoverability in currently running system. That's what filesystem journaling is all about. Journaling doesn't do anything that fsck can't do EXCEPT that replaying the journal is much faster. Vi recovery files are another example. As the article pointed out, 'undo' in any app is an example.

Life critical systems are often actually two seperate programs, 'old reliable' which is primarily designed not to allow a dangerous ondition, and the 'latest and greatest' which has optimal performance as it's primary goal. Should 'old reliable' detect that 'latest and greatest' is about to do something dangerous, it will take over and possibly reboot 'latest and greatest'.

Transaction based systems feature rollback, volume managers support snapshot, and libraries exist to support application checkpointing. EROS is an operating system based on transactions and persistant state. It's designed to support this sort of reliability.

HA clustering and server farms are another similar approach. In that case, they allow individual transactions to fail and individual machines to crash, but overall remain available.

Apache has used a simple form of this for years. Each server process has a maximum service count associated with it. It will serve that many requests, then be killed and a new process spawned. The purpose is to minimize the consequences of unfixed memory leaks.

Many server daemons support a reload method where they re-read their config files without doing a complete restart. Smart admins make a backup copy of the config files to roll back to should their changes cause a system failure.

Also as the article points out, design for testing (DFT) has been around in hardware for a while as well. That's what JTAG is for. JTAG itself will be more useful once reasonably priced tools become available. Newer motherboards have JTAG ports built in. They are intended for monitor boards, but can be used for debugging as well (IMHO, they would be MORE useful for debugging than for monitoring, but that's another post!). Built in watchdog timers are becoming more common as well. ECC RAM is now manditory on many server boards.

It WILL take a lot of work. It IS being done NOW in a stepwise manner. IF/when healthy competition in software is restored, we will see even more of this. When it comes down to it, nobody likes to lose work or time and software that prevents that will be preferred to that which doesn't.

I agree with your overall point, but not everything you said. If we are speaking purely about innovation, then I think that open-source can be quite innovative. EROS works towards an orthagonally-persistant server operating system. Squeak is doing a tremendous amount of multimedia work and research on how to make programming literally simple enough for kids. HURD actually does a very nice job improving on the whole idea of Unix, if you study how it would be used in an ideal world. ReiserFS 4 could be a true revolution in file-system design by assigning no penalty to having millions of extremely small files. Although all of these projects leverage existing technologies, all of them want to take those technologies to what, at least in my opinion, are clearly innovative directions. Perhaps they are not always revolutions, but they are certainly radical evolution.

The problem is that there is that the open-source community never quite manages to turn any of these ideas into actual, practical products. Most people haven't heard of EROS or Squeak. HURD sits perpetually half-finished on a horrible microkernel that it should have left years ago, and efforts to move it to L4 have stalled. When ReiserFS gets here, it will likely be years, if ever, before Linux actually takes advantage of its filesystem approach and obsoletes a million text files. Open-source frequently even has trouble matching truly innovative ideas that do make it main-stream elsewhere. There is, as far as I know, no real open-source equivalent to the QuickTime multimedia architecture (not talking about the movie format; I'm talking about the API) (Mac System 7), Quartz (OS X) or QuickDraw GX (Sytem 7.5), OpenDoc (OS/2 Warp), V-Twin content searching (Mac OS 8.1), live queries (BeOS), register-based virtual machines (Tao Group; in open-source defense, Parrot is indeed a register-based virtual machine, although still lightyears behind Tao's 1993 design)... I could go on, but you get the point.

There are, I think, two reasons for these shortcomings. First, open-source seems incredibly forcused on replacing existing solutions. If that's going to be your focus, then you don't have room to be innovative; compatibility is all that matters, and compatibility inherently means that your innovation options are limited. You can't throw out X11, Unix permissions and configuration files, and classic GUI programming if you want to replace a Sun box verbaitim. That requires gusto and the confidence to say, "I'm going to do that very differently, but this way is better." So why doesn't the open-source community do that? Because it's hard to get a large number of developers willing to spend time on something so radical when they don't have any marketing. Getting out a new paradigm is hard. People get set in their ways. Selling someone on the idea that applications are an obsolete metaphor, or that instead of using a database package, they should use the filesystem directly, can take years, and because open-source developers work as a hobby, they figure that if no one will use their idea anyway, there's never any incentive to polish off those innovative ideas to the point where they're usable. Hence a chicken-and-egg problem built into the system. The best you can hope for are minor improvements on existing ideas, ad nauseum.

Open-source can be innovative. It's just implementing those ideas that trips things up.

Alas, the long-view language designers are off in their own world away from the long-view OS designers. This, combined with the seemingly-insurmountable problem of propagating the new cultural elements of programming, makes me think that we're toast. In 100 years, the state of the art will be only slightly less miserable than it is now. There will be fascinating research projects off in a corner, but no one will use them because of retraining issues, or abysmally-inadequate libraries.

If we're smart and we follow the author's advice, however, maybe 100 years from now the libraries will be there, and the ideas will have propagated.

There are a few "real time" versions of Linux, but they're basically hacks. There's a variant of Linux called "RTLinux", but it's a kludge for running user applications as loadable kernel modules. "KURT" schedules user processes at the microsecond level using a weird device driver. There's a MonteVista variant of Linux with better documentation on latency. It's getting better, but it's not mature yet.

But that's just scheduling. None of these have the hard real time message passing mechanisms of a true real-time OS like QNX. Message passing under Linux tends either to be via FIFOs (i.e. pipes), which is clunky for two-way communication, or via shared memory, which means one program can usually crash the other.

One thing that's become clear from the Mach/Hurd debacle is that good message-passing operating systems are hard. There aren't many. The AmigaOS (Tripos), BeOS, and QNX have been the biggest successes.

Linus doesn't like message passing systems, preferring a subroutine-call interface, and he has a point. There's a tradeoff between security and reliability vs performance. There's a performance hit in message passing systems (minor if you do it right, huge if you get it wrong), but you can build systems such that when part A crashes, part B doesn't crash. Real-time systems need that.

I think you're talking about Capabilities - the OS Eros is a 'proof-of-concept'. Processes are handed capability objects - like a connection to the ICMP socket - and physically can't do anything else. These capability objects could be as simple as a file descriptor; they could also do what you want and have logic in them to limit data size etc. Quite an interesting idea.

Either they're elegant, or you're trapped in a misconception :)

Ofcourse you can view C and Unix as great tools that worked wonderfully over the years.. Or you can blame K and R for an insecure design (yielding problems such as The Confused Deputy) and the general insecurity problems that exist in Unix and C and not in many alternatives.

The concept of a process is also not very related to Unix specifically, but found everywhere where hardware-level separation between threads of execution is useful. I think in the future, such protection will be achieved at the language-level, rather than the hardware level, and that processes are actually ad-hoc and not in any way elegant.

As for files... I see those as the general concept of applications explcitly serializing and persisting their data into bit streams uniquely identified on the disk via string hierarchies. I don't find that elegant at all. In fact, I find Orthogonal persistence a lot more elegant.

I believe Unix encapsulates some nice creative ideas, even elegant. But I also think that the positive concensus about them is a simple reflection of the poor alternatives and of general ignorance of better and more elegant designs out there.

Either they're elegant, or you're trapped in a misconception :)

Ofcourse you can view C and Unix as great tools that worked wonderfully over the years.. Or you can blame K and R for an insecure design (yielding problems such as The Confused Deputy) and the general insecurity problems that exist in Unix and C and not in many alternatives.

The concept of a process is also not very related to Unix specifically, but found everywhere where hardware-level separation between threads of execution is useful. I think in the future, such protection will be achieved at the language-level, rather than the hardware level, and that processes are actually ad-hoc and not in any way elegant.

As for files... I see those as the general concept of applications explcitly serializing and persisting their data into bit streams uniquely identified on the disk via string hierarchies. I don't find that elegant at all. In fact, I find Orthogonal persistence a lot more elegant.

I believe Unix encapsulates some nice creative ideas, even elegant. But I also think that the positive concensus about them is a simple reflection of the poor alternatives and of general ignorance of better and more elegant designs out there.

You mean a capabilities system? Take a look at EROS: http://www.eros-os.org.

Theoretically, a capabilities-based OS like EROS would be even more secure than OpenBSD, if the implementation was as careful. Of course, the same tradeoffs that OpenBSD makes would be even more extreme (application support definitely, performance probably I would think)

How do we store the database? As a file. What is a file? An indexed, named set of blocks on a storage medium.

Why? Why not store it in the VM without any intrinsic on media structure? A file is a serialized object. While serialization is important, when we should actually do it is an open question. According to most OSes, the answer is allways, we de-serialize it when we want to use it. In other OSes, the answer is only if we must in order to interoperate with legacy systems (see eros).

Modern OSes have moved a bit in that direction. Linux maintains a cache of directory entries it has accessed before (the dentry cache). Inodes are cached as well through a different mechanism (even though directories are themselves kept in inodes). It is an improvement, but it's interesting that there are several single object type cache mechanisms in the kernel rather than a single generalized mechanism.

Thought along these lines may or may not lead anywhere, but if the questions aren't asked, we will not only fail to improve our technology, we won't fully grasp what our technology does now. Even if the file is the best way to manage data, we are still limited if we never ask what, exactly, is a file anyway and why do we need them.

I'm not a fan of Palladium and I think think it will be a disaster for human freedom. That being the case I don't think you are fairly addressing the technology. What Palladium does is removes the notion that the owner of a machine is the owner of the digital data on the machine. It seperates the two.

The classic capability problem is something like this:

Person A has some data
Person B has a program that can perform an operation on person A's
A would like to use B's program
B does not trust A with his program
A does not trust B with his data

There is no party C which they both trust.

That is the classic capability problem; how to construct operating systems that can act as a person C between users. So far Unix with a strange setup could handle this. But now we go a little futher, one of the key differences between capability systems and Unix systems is that A and B need to trust the system but not necc all the system administrators. In other words access to administrate the system should not translate into access to the data and the program. That's where a meta administrator comes in verifying to A and B that the system can really act in role C.

That's what Unix and NT currently do not support. A can't grant permission for B to use A's data on a particular program. A can either grant you or not grant you read access. B can't grant A permission to run his program on a particular data set he can either grant or not grant run permission.

Typically in Unix the proxy for the "owner" is the system administrator. But that's just another employee. As a result of the Unix security model computer knowledgeable employees have tremendous power within corporations. The idea of capability systems was that technical employees would not have the kinds of power and access they have today. In the end ease of development won out over security (like always) and Unix (non capability) triumphed over Multics (the king of capability computing). What is happening now is that a generation has passed and the arguments for Multics are being rehashed. These aren't bad arguments and history could have easily gone the other way in the 1970s.

I would suggest you look at the EROS website in general and non-equivelence in particular.

I'm not a fan of Palladium and I think think it will be a disaster for human freedom. That being the case I don't think you are fairly addressing the technology. What Palladium does is removes the notion that the owner of a machine is the owner of the digital data on the machine. It seperates the two.

The classic capability problem is something like this:

Person A has some data
Person B has a program that can perform an operation on person A's
A would like to use B's program
B does not trust A with his program
A does not trust B with his data

There is no party C which they both trust.

That is the classic capability problem; how to construct operating systems that can act as a person C between users. So far Unix with a strange setup could handle this. But now we go a little futher, one of the key differences between capability systems and Unix systems is that A and B need to trust the system but not necc all the system administrators. In other words access to administrate the system should not translate into access to the data and the program. That's where a meta administrator comes in verifying to A and B that the system can really act in role C.

That's what Unix and NT currently do not support. A can't grant permission for B to use A's data on a particular program. A can either grant you or not grant you read access. B can't grant A permission to run his program on a particular data set he can either grant or not grant run permission.

Typically in Unix the proxy for the "owner" is the system administrator. But that's just another employee. As a result of the Unix security model computer knowledgeable employees have tremendous power within corporations. The idea of capability systems was that technical employees would not have the kinds of power and access they have today. In the end ease of development won out over security (like always) and Unix (non capability) triumphed over Multics (the king of capability computing). What is happening now is that a generation has passed and the arguments for Multics are being rehashed. These aren't bad arguments and history could have easily gone the other way in the 1970s.

I would suggest you look at the EROS website in general and non-equivelence in particular.

Sounds like you need... you want... EROS!. No, I'm not trying to make snide jokes about Slashdotters sexuality. Seriously, it's a system built on 'permissions' which means each piece of code is allowed only what it needs to run... it's apparently a totally different type of architechture that is effectively unhackable.

But once your obfuscated URL is discovered - and discovering it is trivial - then the secret is out, and what little protection it did provide is lost until you can change the obfuscation.

So in other words, locking down the system is a URL change away, which exactly parallels the password situation. In fact, if you do it right (cryptographically secure random hash strings), a URL is more secure than a password. A secure scheme: an encryption layer so it's impossible to snoop the URLs, (at least) 128-bit crypto-secure URLs and you have yourself a capability-secure system.

See these for more info on capability-based security:
E rights
EROS

Discovering the URL is not trivial if you do it right. It becomes a problem of guessing a 128-bit string, or cracking the connection encryption keys. MUCH more secure than passwords which are typically no longer than 64-bits and alpha-numeric limited (effectively limiting them to around 32-bits - much less if you factor in how much people use english words).

Plus, it will be hard to get that browser working in EROS when "There is currently no graphics support." Straight out of the FAQ.

I don't think this is the particular solution most people have in mind. Yeah, there may be a couple fanatic lynx users out there: not me.

I'll grant you that from a theoretical perspective, your argument might be sound. But no way in the near term.

Yeah, slick, but the Current Project Status lists "Recent" results from 1998 benchmarked against Linux kernel 2.0.34! The latest pre-release on the status page is EROS v0.8.3, but the link to release notes is for EROS v1.1!

How is a newcomer to the project supposed to find out what it's all about? That's like a sign that says "If you like your shit together, go away."

No, the solution is to give up on ACL-based security, and integrate proper capabilities-based security right into the operating system. Of course, the programming language must be safe as well, and preferably friendly to capabilities.

No, the solution is to give up on ACL-based security, and integrate proper capabilities-based security right into the operating system. Of course, the programming language must be safe as well, and preferably friendly to capabilities.

No, the solution is to give up on ACL-based security, and integrate proper capabilities-based security right into the operating system. Of course, the programming language must be safe as well, and preferably friendly to capabilities.

Jonathan S. Shapiro, Ph.D.
Johns Hopkins University Information Security Institute

By now, you may have heard that Microsoft has received a Common Criteria certification for Windows 2000 (with service pack 3) at Evaluation Assurance Level (EAL) 4. Since a bunch of people know that I work on operating system security and on security assurance, I've received lots of notes asking "What does this mean?" On this page I will try to answer the question. For the impatient the answer is:

• Security experts have been saying for years that the the security of the Windows family of products is hopelessly inadequate. Now there is a rigorous government certification confirming this.

Since that's a pretty strong statement, bear with me while I try to explain it in plain English.

At the risk of telling you something you already know, here is how a purchaser ought to proceed when buying a security product:

1. Assess your needs. Determine what your requirements are.

2. Decide which product you are most confident will meet those needs.

3. Buy and deploy it.

Each of these is potentially an involved process, and most customers don't have the expertise to do them effectively. Even if you did, Microsoft (or any other vendor) isn't likely to let you examine their code and design documents in order to evaluate their product.

The purpose of the Common Criteria process is to develop standard packages of commonly found requirements (called Protection Profiles) and have a standard process of independent evaluation by which an expert evaluation team arrives at a level of confidence for some particular software product.

As a customer, this makes your life simpler, because you can compare your needs against existing requirements constructed by experts and then see how well the software you are buying meets those requirements. Security requirements are fairly hard to write down correctly, but if the resulting document is annotated properly they aren't all that hard to understand.

Obviously, if you don't know your needs (requirements) you don't stand much of a chance of getting them met. Likewise, if you don't know what requirements a software product was evaluated against, the evaluation result isn't terribly useful to you in practical terms.

From the customer perspective, a Common Criteria evaluation has two parts:

1. A standardized requirements specification called a Protection Profile that says what the system is supposed to do. Sometimes there will be more than one of these -- usually a general baseline protection profile and then some others describing additional, specialized requirements.

2. An evaluation rating. This is basically an investigation by well-trained experts to determine whether the system actually meets the requirements specified in the protection profile(s). The result of the evaluation is an "Evaluation Assurance Level" which can be between 1 and 7. This number expresses the degree of confidence that you can place in the system.

In order to understand the result of an evaluation, you need to know both the evaluation result, which will be a level between EAL1 and EAL7, and the protection profile (the requirements that were tested). Given two systems evaluated against the same protection profile, a higher EAL rating is a better rating provided the requirements meet your needs.

Knowing that a product has met an EAL4 evaluation -- or even an EAL7 evaluation -- tells you absolutely nothing useful. It means that you can have some amount of confidence that the product meets an unknown set of requirements. To give a contrived example, you might need a piece of software that always paints the screen black. I might build a piece of software that paints the screen red with very high reliability, and get it evaluated at EAL4. Obviously my software isn't going to solve your problem.

Microsoft sponsored an evaluation of Windows 2000 (with Service Pack 3 and one patch) against the Controlled Access Protection Profile (plus some enhancements) and obtained an EAL4 evaluation rating. This is most accurately written as "CAPP/EAL4".

The Controlled Access Protection Profile (CAPP) standard document can be found at the Common Criteria website.Here is a description of the CAPP requirements taken from the document itself (from page 9):

• The CAPP provides for a level of protection which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well funded attackers to breach system security. The CAPP does not fully address the threats posed by malicious system development or administrative personnel.

Translating that into colloquial English:

• Don't hook this to the internet, don't run email, don't install software unless you can 100% trust the developer, and if anybody who works for you turns out to be out to get you you are toast.

In fairness to Microsoft, CAPP is the most complete operating system protection profile that is presently standardized. This may be the best that Microsoft can do, but it is very important for you as a user to understand that These requirements are not good enough to make the system secure. It also needs to be acknowledged that commercial UNIX-based systems like Linux aren't any better (though they are more resistant to penetration).

Note that the "Don't install software" part means that you probably shouldn't install a word processor. On several occasions Microsoft has unintentionally shipped CD's with viruses on them. A CD with a virus qualified as "malicious system development."

Having described the requirements problem, I now need to describe the problem of the EAL4 evaluation assurance level that Windows 2000 received.

As I mentioned before, EAL levels run from 1 to 7. EAL1 basically means that the vendor showed up for the meeting. EAL7 means that key parts of the system have been rigorously verified in a mathematical way. EAL4 means that the design documents were reviewed using non-challenging criteria. This is sort of like having an accounting audit where the auditor checks that all of your paperwork is there and your business practice standards are appropriate, but never actually checks that any of your numbers are correct. An EAL4 evaluation is not required to examine the software at all.

An EAL4 rating means that you did a lot of paperwork related to the software process, but says absolutely nothing about the quality of the software itself. There are no quantifiable measurements made of the software, and essentially none of the code is inspected. Buying software with an EAL4 rating is kind of like buying a home without a home inspection, only more risky.

In the case of the CAPP protection profile, there actually isn't much point to doing anything better than a low-confidence evaluation, because the requirements set itself is very weak. In effect, you would be saying "My results are inadequate, but the good news is that I've done a lot of work so that I can be really sure that the results are inadequate.

In the case of CAPP, an EAL4 evaluation tells you everything you need to know. It tells you that Microsoft spent millions of dollars producing documentation that shows that Windows 2000 meets an inadequate set of requirements, and that you can have reasonably strong confidence that this is the case.

Security isn't something that a large group can do well. It is something achieved by small groups of experts. Adding more programmers and more features makes things worse rather than better. Microsoft has been adding features demanded by their customers for a very long time.

It is possible to do much better. EROS, a research operating system that we are working on here in the Systems Research Laboratory at Johns Hopkins University, should eventually achieve an EAL7 evaluation rating, and is expected to provide total defense against viruses and malicious code. It won't be compatible, because the most important security problems in Windows and UNIX are design problems rather than implementation problems. In fact, none of the viable research efforts toward secure operating systems are compatible with existing systems.

It remains to be seen whether EROS or one of the other attempts to build secure operating systems will prevail, but better solutions are coming.

Jonathan Shapiro is an Assistant Professor in the Department of Computer Science of Johns Hopkins University. He has been working on operating system security and assurance since 1991. His past research has yielded both formally verified security properties and dramatically improved performance results in secure operating systems. His current research focuses on tying these results together into a complete, usable system, and on evaluating and testing the correctness and reliability of the resulting system.

Dr. Shapiro is also member of JHUISI, the Hopkins Information Security Institute.

I don't know about Z-OS, but I've read a little about EROS. EROS doesn't need a filesystem. That's because everything in EROS is persistent. The system saves a complete snapshot of its virtual memory to disk every couple of minutes. There is no "rebooting" of the OS. If you pull the plug, it comes back up exactly in the state of the last snapshot.

For me, it took a little while for that concept to sink in. They're saying that there's no need to redundantly keep information in permanent storage and volatile storage. Just make it all permanent, and you don't need the filesystem concept at all. In one step, you eliminate whole classes of bugs (parsing, file permissions, sharing files, filesystem namespace problems, etc.)

Their authority model also makes sense. Think of your system as a large building. Normal OSes treat security like doors with electronic badge readers; you're allowed to do things based on who you are. Naturally, a lot of doors must be programmed to let you through if you're going to get around the building to do your work. It's hard to ensure that each person is never able to get into a room that they shouldn't be in.

EROS is more like a building full of unique old-fashioned key locks. You have no automatic authority to go through any door. You must obtain the individual key for each door. You get these keys on an as-needed by the people in various rooms you interact with as you do your work. Each person with keys to hand out individually determines if you are worthy to go through the next door.

Reading up on EROS really expanded my view of how an OS could work. You can check it out at www.eros-os.org.

A virus/trojan that trades stock thereby disrupting the market
A trojan that activates and places an order on Amazon.com
A virus that publishes sensitive information such as private tax records

All of these problems can be better solved using a secure OS that implements confinement, such as EROS. Confinement, secure boot, and attestation are orthogonal features, but MS is presenting an all-or-nothing choice in Palladium. Any system that truly has users' best interests in mind will offer only features that benefit users (confinement, maybe smart cards) and not features that are primarily useful for oppressing users (attestation).

A small, finite, debugged code base that deals with security - and no extra security code.

Simple security paradigm with a single simple-logic security test per request.

Identity between what a process can request, and what the process is authorized to do.

Fine-grained access control, with each process having capabilities to the exact objects it needs to access.

Mathematically-found model, that has mathematically provable properties.

The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).

Flexible security: The complicated authorization graph is between processes, and not between users and objects. The concept of "user" is not part of the operating system. This is also achievable because capability systems often have orthogonal persistence, that is transparent persistence (sort of like Hibernation Mode, in its functionality), which tends to be of much better disk performance.

No global namespace: There is no global namespace file system that all applications have access to. Perhaps a database of objects for the user's convinence that points via capabilities to the user's objects which are then passed on selectively. But there is no global file namespace that processes can access. All requests by processes must be carried out by activating a capability, whose mere existence authorizes the request. This instead of activating a system call from a global namespace of system calls, allowing any process to request almost anything, hoping that the security code regarding that request will properly deny that request. The global namespace allows extra communication and exploitation between processes that needn't be possible.

A small, finite, debugged code base that deals with security - and no extra security code.

Simple security paradigm with a single simple-logic security test per request.

Identity between what a process can request, and what the process is authorized to do.

Fine-grained access control, with each process having capabilities to the exact objects it needs to access.

Mathematically-found model, that has mathematically provable properties.

The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).

Flexible security: The complicated authorization graph is between processes, and not between users and objects. The concept of "user" is not part of the operating system. This is also achievable because capability systems often have orthogonal persistence, that is transparent persistence (sort of like Hibernation Mode, in its functionality), which tends to be of much better disk performance.

No global namespace: There is no global namespace file system that all applications have access to. Perhaps a database of objects for the user's convinence that points via capabilities to the user's objects which are then passed on selectively. But there is no global file namespace that processes can access. All requests by processes must be carried out by activating a capability, whose mere existence authorizes the request. This instead of activating a system call from a global namespace of system calls, allowing any process to request almost anything, hoping that the security code regarding that request will properly deny that request. The global namespace allows extra communication and exploitation between processes that needn't be possible.

A small, finite, debugged code base that deals with security - and no extra security code.

Simple security paradigm with a single simple-logic security test per request.

Identity between what a process can request, and what the process is authorized to do.

Fine-grained access control, with each process having capabilities to the exact objects it needs to access.

Mathematically-found model, that has mathematically provable properties.

The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).

Flexible security: The complicated authorization graph is between processes, and not between users and objects. The concept of "user" is not part of the operating system. This is also achievable because capability systems often have orthogonal persistence, that is transparent persistence (sort of like Hibernation Mode, in its functionality), which tends to be of much better disk performance.

No global namespace: There is no global namespace file system that all applications have access to. Perhaps a database of objects for the user's convinence that points via capabilities to the user's objects which are then passed on selectively. But there is no global file namespace that processes can access. All requests by processes must be carried out by activating a capability, whose mere existence authorizes the request. This instead of activating a system call from a global namespace of system calls, allowing any process to request almost anything, hoping that the security code regarding that request will properly deny that request. The global namespace allows extra communication and exploitation between processes that needn't be possible.

EROS, KeyKOS, and pretty much any properly designed capability operating system

EROS, the Extremely Reliable Operating System, by Jonathan Shapiro et al., is a capability-based operating system, inspired by KeyKOS and other academic systems from a decade or so ago. A capability is similar to an object handle - you can only access an object (file, process, etc.) if you have a capa that gives you the kinds of permissions you need for the action you want to take. Lots more information at www.eros-os.org.

(Note: that's eros-os.org, not eros.org, which is something entirely different :-)

It's getting very close to the time when I want to refuse all calls and email unless the other party has a token indicating that I have given permission.

What you describe is very similar to the capability security model. Check out EROS and E programming language for more info.

KeyKOS solved a lot of the problems this paper describes in the 80s, and its descendent EROS is solving them today (and open source, too!).

Unfortunately, in the 80s people were so infatuated with micros that secure timesharing wasn't a big market, and today people have been living with insecure systems so long they have stopped caring.

Capability systems have many provable mathematical properties that are very important to real security. For example, one can prove privelege escalation is impossible in a capability system.

Sure, a real life implementation will differ from the design until all bugs are resolved, but its still better than *nix security, where even the design itself has no secure properties that are mathematically provable. Also, since the security code in EROS and such systems is very limited to the implementation of the low-level capability mechanism, the amount of security-testing code is very finite in size, and thus will at some point in time be clear of bugs, and identical to the architecture's design.

One of the main differences between capability systems and systrace for all apps, is that in a capability system, _only_ authorized requests can even be expressed by an application, while with systrace, all requests can be expressed, and if a bug exists in one of the millions of requests' implementations, you get a security hole.

Also, capability systems grant you far more fine-grained security control, and they define processes as entities, rather than users.

Capability systems are also much simpler in concept, and do not have a global namespace such as a filesystem that makes for richer communication between distant entities of the system, even those who are not supposed to communicate.

Capability systems are not volunerable to the Confused Deputy problem that exists with ACL-type systems where you must have applications that 'Change hats' (All apps with 'suid bits').

Probably a troll but:

Linux and BSD are both just *nix.
*nix is *nix is *nix. Crappy ACL-type security (as opposed to Capability Systems security [EROS, for example]).

Performance differences are negligable. The areas where BSD and Linux do differ, usually the Linux way is better known around. The Stack is ripped off in closed source OS's because Linux doesn't use a license that supports Closed Source distributers.

In hardware support, Linux probably beats BSD, but I haven't followed it much.

Also, Linux has a native Debian distribution, and many others, while BSD has second-hand ports of such and its native distributions are in many oppinions far worse.

1. Massively expanding address space and hence (for the first time - IMHO) making the holy grail of direct manipulation of persistent data structures a realistic proposition.

Well, EROS does just this on 32 bit systems. (Thankfully), I haven't had to touch EROS much yet, so I don't really know how it handles it, though.

Of course, given there is no driver for hard drives, etc (and last I heard booting the kernel didn't work on systems with more than 256 megs of memory), the fact that it supports persistent state is not particularly useful. But someday...

2. Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!

That's just a bad data structure. What you want is to have each node of the linked list have a fixed size array (say 1-16K, depending on local circumstances), and a couple of extra integers telling you where the start and stop of the arrays are. This is much, must faster, and the memory overhead for the extra pointers (be they 32 or 64 bits) is quite small. It's also quite trivial to program.

Excuse me, the data structure I just described is for queues, not general lists (queues tend to come up more often than list for me so that's what my mind jumped to, I guess). But you see my point, I hope.

I can't really think of a case where a 400% overhead is too much, but 200% is OK.

The short version of the story is that it is an object oriented paradigm in which every class is a process and every instance is a thread. It needs hyper fast messaging and process/thread swapping. No other OS will do that.

Someone obviously hasn't done their research:
L4
EROS

Both of these kernels are vastly superior to anything they will be able to build for message passing and context switching speed.

It seems to me that more and more languages nowadays are designed for a VM, thus adding a level in between the OS and the application. Of course, this leads to a slowdown because the JIT has to do its thing AND the compiled code that runs has to use system calls to do what it wants to. But has anybody given any thought to making a VM that runs almost on top of the hardware with almost no system calls? Perhaps the only interference the OS would make is scheduling and possibly memory management. This kind of approach (like the exokernel approach in the EROS project) would allow a VM to greatly speed up its resultant code because it would have almost direct control of the hardware, and the VM would be optimized for that hardware. I am working on an OS (Middle Earth OS) that is looking into this kind of design, and would appreciate your input either here or in the project's forums as to whether you think this would work (well) or not.

We've pretty much scaled all the smaller and more well-known mountains like "portability" and "security" and are now left with some of the taller and more foreboding peaks, like "clustering", "distributed filesystems" and "ubiquitous computing".

Good thing security is in quotes. Not a small mountain, nor has it been scaled. See the Saving the UNIX API thread from a few months ago on the cap-talk mailing list.