Coyotos, A New Security-focused OS & Language

wap writes "For those who haven't been following the EROS project, it has now migrated to the Coyotos project. EROS, the Extremely Reliable Operating System, was a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root. Capabilities allow a rigorous verification of the security of a system, something which is not possible in Unix-style and MS Windows systems. Coyotos is to be a real-world usable implementation of the ideas from EROS, complete with a Linux emulator layer. It also specifies a new language, called BitC which allows the programmer to prove that the code implements certain semantics, thus providing another layer of verifiable security. Could this be the most leet OS and language of 2005?" Another submittor asks how this stacks up against using Systems Management and "standard" OSes.

Comments

Need for a superuser?

[PornMaster]

One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

How is this resolved without a superuser?

Re:Need for a superuser?

[Andreas(R)]

One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

Exhaustive password search, of course.

Re:Need for a superuser?

[Sexy Commando]

Simple.

You rip the drive out and stick into another computer. If there is encryption, superuser won't solve it anyway.

Re:Need for a superuser?

[Coryoth]

One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

In SELinux, which I am more familiar with, and which also gets rid of the "superuser" account, everything is handled by context or role. That means you can isolate a process that wants "root" access to certain files by restricting its role to one that has access to only those files. Thus there is no "root" account that has access to everything. At the same time, it's possible to create a role that allows suitable access to make changes and/or recover lost data if necessary.

I presume Coyotos, with its "capabilities" will work similarly - ie. there is no "root" account that has access to everything, but instead various capabilities that bound access to various resources.

Jedidiah

Re:Need for a superuser?

[kaisyain]

There's nothing that says you can't have a user with that capability. But why should the user who can read the dead employee's information also be the only user who can run a web server on port 80?

Re:Need for a superuser?

[tepples]

But why should the user who can read the dead employee's information also be the only user who can run a web server on port 80?

Doesn't the port address translation of iptables and other popular firewalls give you a way to implement capabilities at least for TCP well-known ports? For example, one can specify to route 80/tcp in to 8086/tcp and that only Apache is permitted to listen on 8086/tcp.

Re:Need for a superuser?

[GeckoX]

And who has the rights to create that new user that has sufficient rights to get at all of that critical data that the guy who just died left behind?

I see a bit of a chicken or an egg thing here.

There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.

So, no superuser. This means there must be some way to create an account with sufficient rights to recover lost data, which kinda undermines the security in the first place.

Hope I'm missing something ;)

Re:Need for a superuser?

[Sheetrock]

I'd pull the stuff from backups. No critical business is without them, and if you're encrypting those I'd hope you're using DSA with multiple keying to a second administrator and an escrow key that sits in the CEO's safe for precisely this situation.

Re:Need for a superuser?

[Omniscientist]

Jack the Ripper password cracker I suppose.

Re:Need for a superuser?

[dfj225]

Believe it or not, I saw a Mac OS X box that didn't have an administrator (read: as close as you can get to superuser for OS X) account. No one knew how all of the users ended up being non-admins, but the only solution we could come up with was a reinstall of the operating system. I think having a superuser account is probably a good idea, however I think someone developing a new operating system would be wise to make a type of account that allows the user to maintenence without becoming a superuser. I really like how Mac OS X handles it. I can install software or add users without needing to become a real superuser. I know through the shell I can gain superuser rights, but there really shouldn't be any reason for me to do so. A superuser is necessary for some cases, like you mentioned, but I think it should be considered a last resort rather than something you need to make even common changes.

Re:Need for a superuser?

[Anonymous Coward]

Hey, that really is simple. Tell me, how do you do that when it's encrypted NTFS in Windows XP and you don't have key recovery?

Re:Need for a superuser?

[OwnedByTwoCats]

The point is that one can have "account creation" priviledges, or even "priviledge granting" privildedges, without having "ability to deliver signals to any process in the system" priviledges.

In unix, "root" has all the permissions. There is no way to grant someone permission to do one extraordinary thing without giving that user permission to do a whole host of extraordinary things.

Re:Need for a superuser?

[Qzukk]

I'm sure there is, but unlike on a Unix system where the "super-user" account would be used to run everything under the sun from the daily cron jobs to the mail server, this account would never be used except to replace the "user-control-account" account. Its password would probably be an md5 hash of some very long string that would be memorized by all the VPs of the company so that any one of them could use it. (Or however the company deals with the root passwords now... sealed in a vault?)

Re:Need for a superuser?

[dAzED1]

apparently you've never heard of groups, ACL's, or sudo.

Re:Need for a superuser?

[mr.newt]

If someone has privilege-granting privileges, they have the ability to grant themselves all the privileges available. Obviously, it is different from a superuser account if all you're concerned about is accidentally doing something you didn't want to do by limiting the power of the account you're currently using, but for security this does nothing.

Re:Need for a superuser?

[lems1]

... And this can already be done under Linux (+SELinux patches) without the need to go venturing in yet-another-os.
By the time this new OS matures and becomes "usable" (perhaps 10 or so years from now), Linux will probably have all these capabilities (either built-in or via patches) and it will be a heck of an OS -- a lot more mature than it is now. So, after reading about what a "capability" [1] is and "how it compares to ACL" [2], I believe this is a lost cause.

And yes, I do have a problem with people who write documents like the ones found in eros-os.org, who think that being so tecnical (perhaps to disguise how dumb their designs are?) makes them "smarter" than the rest of us.

[1] http://www.eros-os.org/essays/capintro.html
[2] http://www.eros-os.org/essays/ACLSvCaps.html

Re:Need for a superuser?

[zby]

They can keep backup passwords to important parts of the system in a safe.

Re:Need for a superuser?

[mistshadow]

Couldn't you just boot into single-user mode (command-s as it boots), start the netinto server (nibindd, I think, or just netinfod -s local), then assign root a password?

Re:Need for a superuser?

[Sexy Commando]

Read the second half of my comment.

Re:Need for a superuser?

[Anonymous Coward]

> There will always have to be either the concept of a superuser

No there will not. Many secure systems exist today that have no concept at all of a superuser. Some roles have extended rights in some areas, but their access to everything else is severely curtailed. The security administrator role in a MLS (multilevel security) system can tinker with the rights of any user, but can't touch files at all, such as the audit log of his own activities. The whole concept of MLS is such that the higher your clearance, the less access you actually have. So you may be able to read top secret docs, but your copy and paste keys no longer work.

Recovery of lost data is done through backups. Backup administrators can't actually read the data they're restoring, just the metadata. Only the backup facility itself accesses the data, and its interface is very well locked down so you can't do anything unauthorized with the data. Theoretically anyway. That's the whole notion of capabilities.

Re:Need for a superuser?

[Anonymous Coward]

> apparently you've never heard of groups, ACL's, or sudo.

Capabilities are like having a group for every operation. Not every problem is a nail, more tools exist than your hammer, and some of them are even useful.

Re:Need for a superuser?

[yulek]

In unix, "root" has all the permissions. There is no way to grant someone permission to do one extraordinary thing without giving that user permission to do a whole host of extraordinary things.

sudo and a well defined sudoer file.

Re:Need for a superuser?

[hal9000(jr)]

Key escrow.

It is OK for an organization to escrow encryption keys so that they can recover the data later. Of course, you need to protect the escrowed keys.

Key escrow of signing keys is a different matter altogether because signing keys are assigned to a specific user. If someone else has custody of the private signing key, you can never assert that the user had sole use--someone can always claim that he signatures were forged. Also, there is no need to escrow a signing key because if the private key was lost, you can still validate signatures on data signed with that provate key using the public key (at least upto the time when the key was lost, then don't trust any signatures)

Re:Need for a superuser?

[dAzED1]

user ownership: a tool
group ownership: a tool
"other" access: a tool

sudo: a tool
ACL's: a tool
AFS or related: a tool

Tell me where ya got lost.

Re:Need for a superuser?

[ThinkTiM]

Yes, you are, so relax. If you separate the roles of creating an account (and defining the priveledges that it has) and setting/resetting/enabling the password on an account, then it takes at least two people to gain access against the wishes of the owner of the system. Most large organizations have a standard that a single role cannot do this, and they usually have the roles working in different groups within the organization.

Re:Need for a superuser?

[naasking]

Just because there is no super-user, doesn't mean that there is no way to access a person's data. Anyone with a capability to a particular resource can access that resource regardless of who they are; there is no concept of "ownership" except in that the creator of an object is the only entity holding a capability to it until he gives it to someone else.

Suppose an administrator creates a block of space he wishes to dedicate to a particular user. The act of creation returns a capability(unforgeable reference) to that object, and the admin is currently the only one holding that capability; no one else is even aware of its existence. Once he grants the capability to the user, the user now also has access to that space. The admin does not (necessarily) lose it.

One could design the system such that the admin could not access the private space in any meaningful fashion (plausible deniability/common carrier) and thus the user may use it as he wishes; or one could design it such that the admin has full access to any objects created from that space (full auditing support and higher level policy enforcement).

Capability security is simply enforced, pure object-oriented reference mechanics. Until you give B a reference to C, B cannot refer to C or induce any sort of direct changes in C (in Java and .NET VMs). Same with capabilities.

Re:Need for a superuser?

[Qzukk]

I think the problem is that what you see as "superuser", capability-based systems see as "user with all capabilities".

In this case, theres a capability that says "create or modify accounts" and some user(s) will be given that capability, and those users will be responsible for creating or resetting passwords on accounts, and hopefully they won't all take the same airplane together, or at least that they have a password to an account saved in some vault somewhere.

Re:Need for a superuser?

[m50d]

So a determined malicious insider can do everything they can do under traditional unix, yes. But there's defense in depth here. For example, you can probably eliminate all your setuid binaries, just give them the capabilities they need. Cdrecord gets the "set own niceness very high" capability, but a cdrecord vulnerability doesn't make a local root one. Mplayer gets the "direct access to video card" capability. People who just need to be able to mount iso images don't need the root password. It's not a panacea, but it's another layer of protection.

Re:Need for a superuser?

[3TimeLoser]

It helps separate responsibility.

I'm thinking out loud here, but let's assume there is an account or role (lets call it Auditor) that is used to create admin accounts and can recover password/encryption keys. Ideally, this account would be separate from the admin accounts used to manage the system and be the only one with access to certain audit logs/resources/encryption keys.

This way, the Auditor account cannot manage the system or have root access to the file system, but it can recover encrypted data or create/delete admin accounts. On the other hand, the admin accounts cannot administer the Auditor account or delete audit logs, but can do just about anything else on the system.

Granted, there is nothing that prevents the Auditor from resetting an admin password or creating a new admin, but that can be tightly controlled and monitored by manual process. For example, the Auditor credentials are only known by the CIO and only used when needed with direct supervision. These credentials can also be sealed and locked up in case the CIO dies or something. Any other use of those credentials should immediately throw up red flags and launch black helicopters.

It would be nice if the OS enforced these roles, and I think that's what this discussion is all about.

I'll shut up now.

Re:Need for a superuser?

[archeopterix]

One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

How is this resolved without a superuser?

The "missing password" problem is orthogonal to having root vs not having one. After all, unix admins die too, although one might find it hard to believe.

There are interesting cryptographic methods that solve this problem in a tricky way. An algorithm of this sort encrypts data(for example the root password, or just the key giving you some important privileges) with n keys so that k keys (k<=n) are sufficient to decrypt the data and less than k keys are not. You can then distribute the n keys among n trusted persons (the members of the board or whatever) and hope that even if the admin dies, at least k of the n persons will survive to meet and decrypt the data. Of course you could just give the power-key to every of the n persons but then you'd have to worry about too much power in one hand.

This are similar to error correction algorithms (where at least some percent of uncorrupted bits lets you get the uncorrupted message) but in error correction you don't have to prevent people from receiving the message when there are too many errors. Both kinds of algorithms rely on similar principles (for example the fact, that recreating a k-th degree polynomial requires k+1 values in different points).

Re:Need for a superuser?

[shrimppoboy]

Linux has capabilities, and has had them as an integral feature for years. Root does not, necessarily have all powers on Linux system. That is just the way almost everyone does it. A quick perusal of almost any kernel source will show that capabilities are queried throughout. It is not that one must be root - one must have the appropriate capability. Linux is primitive as compared to some other UNIX(-like) systems in that it does not provide a convient mechanism for manipulating capabilites. But, they are there, and they work. I have created processes that were UID=0 (root) and they lacked many capabilities. This is more secure than the usual SUID and root has all capabilities situation that the vast majority of Linux systems have. Also, many sites use "sudo" to avoid giving away a root password and as a means to limiting what commands individuals can run as root. This is almost fairly helpful, and avoids somewhat the need for a superuse.

Re:Need for a superuser?

[torpor]

well, what if all disk media were suddenly wiped out, what if? what if?

seriously though, thats the point of having a 'public, exposed, exchangeable' class of data, as well as 'capabilities'. the point is, your scenario is solved, by active use of capabilities to prevent this occurring. the 'user' simply ensures it, plain and simple, the choice is theirs: did they lock their data up in their private account, thoughts bound to the ether to be taken with them, or did they 'expose what they wanted to expose to whom they wanted to expose it', through the use of advanced operating systems/behavioural-enforcement methods as are being proposed.

speaking of which, and perhaps providing insight into the answer to your question, to curb the 'general habit of people' to packrat data away that they should be properly sharing (or assigning 'rights' to, whatever), such capabilities are enforced by the operating system.

it will be interesting to see some interface paradigms for the 'connected to living human', versus 'public, connected to citizen #200030203, deceased' scenario, anyway ...

*sigh* "Computers of Tomorrow" .. sometimes, you just can't stop thinking about them, eh ... ;)

Re:Need for a superuser?

[viktor]

I see a bit of a chicken or an egg thing here. There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.

Somewhere on the system, individuals or people working together must somehow be able to create users with all possible privileges, that is correct. So individually or collectively they can do anything. That is not the difference.

The difference is that just because a program e.g. needs access to a raw network interface, it does not gain those complete privileges. Such a program will only get the privilege to access the raw network interface, but not to e.g. create new users or open arbitrary files.

With most UNIX'es all-or-nothing superuser (Solaris 10, among other, implement privileges instead), any program needing a raw network interface automatically gains the right to create users, shutdown the machine, alter any file, and anything else as well.

So the main difference isn't that there is no superuser, it's that there are many superusers, each of which can only perform a subset of all possible tasks requiring extra privileges. And that means that the Helpdesk staff could for example be allowed to create new accounts, without thereby automatically gaining the right to look in any file belonging to existing users. And processes can be granted any subset of what root can do without automatically gaining all the other privileges at the same time.

Re:Need for a superuser?

[ajs]

sudo is not sufficient.

With SELinux for example (or Multics or VMS or what-have-you), you are not only protected against the casual user, but the determined cracker who gets access to limited system authority. Let's say that such a user finds that your Web server is using some insecure module and gains access to the "apache" account. Well, that account has the ability to execute commands (perhaps only in certain areas) and can create/delete/modify files only in certain areas (tmp, certain cache directories, etc).

Regardless of how you became apache, you have these restrictions, so there's not much you can do. You probably don't even have permission to deface your own web site, even though you own the files! You can try to find a local compromise to use, but that has limited promise. After all, you can't even execute many of the commands that would give you likely bugs to exploit!

The best you can do is suck up whatever CPU cycles are allocated to apache and fill as much disk as apache is allowed to use, thus performing a simple denial of service.

With the sudo model, you can't at all control what someone does when they gain access to your system, other than to say that they're "not root" (i.e. non-0 UID). Using groups, ulimit, etc, you can do quite a bit more than the default, but even still, you have two problems: many resources simply cannot be limited and if the intruder becomes root, you're hosed.

By breaking up root's authority, you layer your security. This makes compromising your system a harder problem.

Re:Need for a superuser?

[Lawrence_Bird]

yes, terribly off topic but:

Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822.3.

this is Yoda, not Spock, and definitely not Spock from
the Galileo Seven

Re:Need for a superuser?

[Keaster]

Restore from the offsite backup.

Re:Need for a superuser?

[Anonymous Coward]

Easy.. It's called 'putting the password in a filing cabnet that is locked. Only the MD + 1 has the key.. The only break point is a physical one. Hell, use a biometic scanner and cut of the dead guy's hand if necessary ;-)

Re:Need for a superuser?

[Anonymous Coward]

Also, Dr. Spock is a real-life Human medical doctor who specializes in Human baby health. Mr. Spock was a fictional Vulcan science officer on board the (fictional) Enterprise.

I have never understood this sig, but most sigs are pretty inane so I usually try to just ignore them.

Re:Need for a superuser?

[Anonymous Coward]

Apprently you've never written software that needs to be run as root. It's a lot more difficult than just groups, ACLs, and sudo when you have to ensure there are no race conditions or buffer overflows that will allow any user to become root. Asshole.

Re:Need for a superuser?

[KeithIrwin]

Actually, the lack of a superuser makes this sort of thing significantly easier. In a superuser system, what happens when the superuser dies or forgets his password? You have to yank out the disc drive and use some other system to rewrite the password file. That's not precisely an elegant solution. Plus, the superuser password has such an enormous possibility for abuse that any sane administrator wants to make sure that as few people know it as possible.

In a capabilities based system, you can have a much finer grain of what can be done. So you can divide the traditional super-user responsibilities amongst several different users, meaning that there is no longer a single point of failure or a single means of abusing the system. For instance, you could have three different trusted users who have the power to remove people's passwords but not to give them new passwords and three other trusted users who can give people new passwords if their password has been removed but not to remove the password. None of these six users has to be trusted nearly as much as one user who can change user's passwords at will because each of them has less power. So because there's less possibility of abuse, the responsibility can be shared more widely.

All of the powers and duties which a superuser account has still exist. A capabilities system isn't a system in which no one can ever change passwords or access files other than their own. It's just a system in which those powers and duties can be spread out across multiple users. This means that "what if the only person who knows the superuser password dies?" is no longer an issue and it also means that powers can be delegated more. Instead of having to get someone with root every time problems need fixing, there could be different people with responsibilities for different parts. Every division could have its own password manager and its own file rights manager.

When power is decentralized there's more accountability, less possibility for abuse, and no longer a single point of failure. Asking how you can run a computer system without a superuser is sort of like asking how you can run a government without an emperor.

Keith

Re:Need for a superuser?

[BitchKapoor]

"And yes, I do have a problem with people who write documents like the ones found in eros-os.org, who think that being so tecnical (perhaps to disguise how dumb their designs are?) makes them 'smarter' than the rest of us."

Please don't take it so personally, they're just trying to get their point across as precisely as they can. Some people just write like that.

Re:Need for a superuser?

[Anonymous Coward]

So what you are saying is that you are pissed off because you didn't understand the documents.

Re:It's a microkernel.

[j1bb3rj4bb3r]

Only if you pass the proper message to the correct mailbox.
And even then only if you have permissions.

Comparison with Multics?

[CodeArt]

How Coyotos compares with Multics? Multics was most secured OS ever created with his multi-ring security architecture and security supported directly in HW.

Re:Comparison with Multics?

[dokebi]

The parent is modded +4 insightful?!?!?
Mr. Moderator, sir? I think it was a joke.

Re:Comparison with Multics?

[Valar]

http://csrc.nist.gov/publications/history/karg74.p df

Firstly, there's that. Secondly, it _was_ the most secure OS ever created, because it was one of the first to be designed with multiple users/networked use in mind. However, keep in mind that it was built with 1960s computer science, 1960s ciphertech, without the lessons learned over the next 40 some odd years, for use on machines with _very_ limited computing power. In other words, it doesn't hold a candle to modern secure operating systems, except for the security by obscurity that comes from not being able to find anyone to work the damn thing.

Re:Comparison with Multics?

[Elwood P Dowd]

Dunno about this Coyotos thing, but a major point of EROS was its checkpointing system & memory architecture. In my completely uninformed understanding, the idea was that there was no filesystem, and the persistent disk was only used to provide virtual memory and checkpoint the memory state.

So if you turn off the computer, and turn it back on again, it loads the last checkpoint, and your processes are all running and in the same state. That's what they mean by "Extremely reliable". There are supposedly processes running in KeyKOS, a similar OS, that have been running since before the computer's current hardware had been built. If that makes sense.

Dunno if Multics did that.

Re:Comparison with Multics?

[Elwood P Dowd]

Ah, but I am full of crap:

Coyotos picks up where EROS left off. From an application builder's perspective, the major change is that Coyotos removes persistence from the architecture. This leads to many simplifications in the implementation, and it has a bunch of consequences for the system utilities, but an application designer probably doesn't care that much -- if anything, it makes the system ``feel'' much more conventional.

So nevermind about that persistence crap.

Re:Comparison with Multics?

[DavidHopwood]

There is a discussion on coyotos-dev at the moment about the decision to remove persistence; it's entirely possible that it will be reversed. Subscribe if you have an interest in this (but read the archive of the thread first).

Re:Comparison with Multics?

[GeorgeMcBay]

Multics was also a huge commercial failure, because security tends to get in the way of people using computers to get real work done.

I'm not suggesting that all security is worthless, and some systems need to be really, really secure, I'm just noting that there's a lot of people (developers and sys/network admins) who are enamored with the theoretical underpinnings of security to the point where they implement security measures that do more harm (in terms of reducing or eliminating productivity) than good.

Re:Comparison with Multics?

[sjlumme]

No, Multics did not have orthogonal persistence. Also, as it says in the linked page, Coyotos is different from its predecessor EROS exactly in that it does not have orthogonal persistence.

Re:Comparison with Multics?

[Richy_T]

World, meet Sarbanes-Oxley.

Rich

Re:Comparison with Multics?

[Anonymous Coward]

There are also quite a few people who are enamored with propagating the myth that security and "people using computers to get real work done" are mutually exclusive. Usually these are people who don't know jack shit about security and are just trying to justify their ignorance.

Re:Comparison with Multics?

[drinkypoo]

Similar but not identical is the apps Palm Computing wrote for the Tandy/Casio/GRiD Zoomer/Z-PDA7000/2390, which either essentially or literally (I forget which) saved their data as a memory dump.

Re:Comparison with Multics?

[multicsfan]

I'm not sure if it was intentional, but when I was working on Multics a system crash occured while I was doing a long listing on a hard copy terminal. When the system came back up an hour later, my listing resumed without dripping a single character.

Re:Comparison with Multics?

[multicsfan]

Security never got in the way of development or use. Users managed their own security with very intelligent defaults. Security on files and directories is controlled by access control lists. An access control list item specified the .. that a particular permission applied to. any component could be a * for all so a public project file might have a acl entry *.gcc.* for all users on the gcc project. Note that one of the defualt entries was for the backup system so you could block the backkup daemon from backing up one or more files.

Re:Comparison with Multics?

[multicsfan]

Multics was a commercial failure as it was not marketed by Honeywell. Multics was available as a product in the very early 70's, however a customer had to ask for Multics by name, threaten to go to IBM/DEC/CDC/etc before they could even get a proposal with pricing. The first Multics system was booted in 1969 and the last one was shudown IIRC in late 2000. Due to internal politics in Honeywell, Multics was never activly sold by Honeywell. GCOS was activily sold. Multics only ever entered a contract proposal when wither the customer insisted on Multics or GCOS could not meet the benchmark, but Multics cold (GCOS and Multics ran on the same basic hardware. Multics had VM, GCOS did not among many other differences).

coyotos site

[bladx]

love their site design ;)

Looks exciting

[RatRagout]

Maybe we will finally get an operating system with a thorough security model....hopefully not so thorough that it can't be used...

Re:Looks exciting

[LurkerXXX]

There already is one. OpenVMS

BitC looks nasty

[Panaflex]

((At least (to me).))

(pan)

Re:BitC looks nasty

[Tumbleweed]

(((Score)==(+3))(Insightful)))

I haven't seen so many parentheses since my cat slept on my keyboard. *ba-bam!*

Re:BitC looks nasty

[Anonymous Coward]

It looks a lot like lisp to me.

Re:BitC looks nasty

[Lorens]

Site says that the lisp-like syntax is to describe the language, and that a C-like syntax could be written.

Re:BitC looks nasty

[Jugalator]

Yes, it seems like a bitch to program in.

Re:BitC looks nasty

[Patrick May]

The syntax looks remarkably like Scheme. If you aren't familiar with Scheme (or Common Lisp), you should be. Even if you don't use it in your day job, learning Scheme will change the way you view programming.

Check out Structure and Interpretation of Computer Programs.

Re:BitC looks nasty

[Tumbleweed]

I think they should alternate the nesting between parentheses and braces. You know, to make it more readable. :)

Re:BitC looks nasty

[Dasein]

Well, I have to admit to not being a lisp-style syntax fan but take a look at the features. Type inference, pattern matching, theorem proving...

I can't tell you how many times I've wished that we were using a language that had type inference and pattern matching.

Re:BitC looks nasty

[Fahrenheit 450]

Yeah, but it looks like they stripped off a couple of ML's better features (currying and modules), dropped tail call optimization, and slapped scheme's syntax (or lack thereof) onto it. I'll have to read their rational a bit more carefully, but it seems like they're just trying to create a slightly better Lisp machine... Although Lisp could successfully escape the confines of the Lisp machine. BitC seems pretty iffy outside of Coyotos.

Re:BitC looks nasty

[sjlumme]

They mention explicitly that the syntax is just a surface-level thing, and that they may well support alternative "sugared" syntax later on. Aside from that, there is one very great advantage to LISP-style syntax, which is that any program finds an obvious representation in a data structure that is primitive in the language's runtime system. Therefore, you can very easily build powerful macro systems and other source-code manipulating tools. That may sound arcane, but anyone who has done some serious programming in a LISP dialect can tell you that real source-to-source macros (as opposed to C's textual-substitution macros) can greatly simplify programs, and eliminate the need for bloating the language standard with control structures that could easily be defined by the user. To see that the need for macros in operating systems is apparent, one only needs to look at the Linux kernel, which bends gcc macrology over backwards in many places.

Re:BitC looks nasty

[aka.Daniel'Z]

So, BitC is based on LISP, cool!

Re:BitC looks nasty

[aka.Daniel'Z]

oh, my bad, there was supposed to be some -like tags there.

Re:BitC looks nasty

[naasking]

They're trying to create a language with ML-like semantics but with total control over data respresentation, such that it is suitable for use in writing operating system software (or any other low-level, high performance software). No garbage collection is an option for instance (since the variance in collection times is too high, it is unsuitable for real-time code).

Re:BitC looks nasty

[Jonathan S. Shapiro]

It may surprise you to learn that the BitC group agrees. I have a fair bit of lisp/scheme experience, but nobody else likes it.

The current, lisp-like syntax is only an interim choice of surface syntax. It's one compelling advantage is that it is trivial to parse, which lets us get on with focusing on making a productive compiler. It also lends itself well to representing the program text as data that can be manipulated within the language, which is going to be extremely useful in the verifier.

Still, when the time is right (not yet -- BitC is still stabilizing) we should perhaps hold a syntax contest.

shap

Re:BitC looks nasty

[Peaker]

Type inference sure is nice... But its main feature is performance.
If you dont care about performance, use dynamic typing.
Most programmers don't really code for performance..

Re:BitC looks nasty

[Dasein]

I have a running argument with one of my friends about this. My position is that there are whole classes of errors that are caught at compile time with type inference.

His position is that, yes, that's true. But that the same class of errors is caught by even the most rudimentary unit tests.

I think he's correct for code that gets exercised. However, it's pretty difficult to get really great code coverage on unit tests -- especially of error handling code.

However, I think everyone can agree that putting the burden of type book keeping on the programmer (as in C/C+/Java) isn't as productive as a language with TI or dynamic typing.

Re:BitC looks nasty

[Panaflex]

That's good news! I am not patently against lisp.. but it is very wordy for system developers IMHO.

Good Luck!
Pan

Re:BitC looks nasty

[Peaker]

I think the point is not that Unit Tests are a good substitute for static type checks.

I think the point is that static type checks are not a good substitute for Unit Tests.

I trust a line that has never run, but passed static type tests pretty much the same as I trust a line that has never run and passed no tests - that is, I don't trust either.

Re:BitC looks nasty

[Dasein]

Agreed. However, his point is that, since we're both respectable developers and neither of us would omit the unit tests, C/C++-style type checking is redundant book keeping and that type inference is of limited practical value.

I have to say, however, I've worked on a number of projects where developers wrote a large volume of unit tests. Then later, brought in code coverage tools. Invariably, everyone is dismayed at the truely huge amount of work required to simply get every line executed. (Simulating full/failing disks, torn database pages, dropped packets, other extenal events in such a way to get code coverage is hard.)

The first one I was involved in had automated tests that took >24hrs to run. When they brought in code coverage tools they found that they had a 60% coverage. A large proportion of the uncovered code was in error handling. (BTW, This claims that trying to get more that 80% code coverage is a mistake.)

Anyway, my point has always been that, even good tests aren't going to exercise every line so it's nice (but not a substitute) to be able to prove that some aspect the code is correct.

On a similar note, I haven't played with the BitC theorem prover:

--- Snip from the docs ---
11.1 Proof Obligations: Theorems
The defthm form introduces a proof obligation that must be discharged by the BitC Prover. The body of a theorem is a boolean expression that is considered to be discharged if its result is #t for all possible variable instantiations:

(defthm name truth-expr)

---

However, it looks interesting but kinda insane.

I keep thinking that I should just go out and develop a new language -- people have paid me for developing language implementation before (C, SQL, XQuery, and Java). However, <whine>I don't wanna. Can't somebody else do it.</whine> ;-)

Re:BitC looks nasty

[Peaker]

Actually, in my code, code coverage tools always show at least 90% coverage by my unit tests...

I use neat tricks and tools to simulate failures though, that I invented myself :-)
Maybe others have less powerful ways to simulate the external environment...

His article simply tries to state the code coverage does not guarantee 0 bugs, which is ofcourse true, but completely off the point.
Also, the "little return on investment" is simply untrue in my experience, because the investment is not as huge as they claim - unless lacking the proper tools.

(Did you notice the linked article author is still in the dark Hungarian notation days?)

Re:EROS utilizes FUCK

[spac3manspiff]

Unless it's implemented on a RISCy processor

That's not the right question

[Anonymous Coward]

Any user could encrypt data, leaving it locked forever if the key is lost. That's just the nature of electronic keys. When someone loses a physical key there is always some way to spend enough money to open the safe or whatever. That's not true in the world of encryption. The solution to that problem lies outside of the scope of the OS. Or rather, the Unix/Linux/MS Windows designers decided to put it in the scope of the OS by making certain types of protection non-existant. But that's not a solution to the problem; that's just omitting features which should be there, like giving users good encryption tools for stored files.

Re:That's not the right question

[Enonu]

Would it be possible to design an enryption system such that if semi-trusted party X spent Y CPU-cycles brute-forcing, it could be broken, but for all other parties no?

Re:That's not the right question

[timster]

Yes, that is possible, and I'll tell you how to do it. Though beware, IANACE (I am not a crypto engineer)

Encryption systems with multiple keys can be made by encrypting the text with a secret key K, and then placing K itself at the beginning but encrypted with various keys X, Y, and Z. So if you have any of the keys X, Y, or Z, you can decrypt K and then you can decrypt the text.

Hypothetically it would not be so hard to take our key K, encrypt it with some insecure algorithm, then encrypt *that* with some strong algorithm via key T, and store it in the file. So if you are our semi-trusted party, you'll have key T, and you can obtain a version of K encrypted with an insecure algorithm. By using brute-force you could thus recover the key.

Re:That's not the right question

[Wesley Felter]

If the data is encrypted with an N-bit symmetric key, you could escrow N-56 bits of the key with your trusted party and they could brute-force the remaining 56 bits in a few days.

Alternately, you could use secret splitting to divide the escrowed data among M trusted parties such that K of them must cooperate to recover the data.

Re:That's not the right question

[Anonymous Coward]

Before you insult the Windows NT kernel by lumping it in with inferior linux "me too" software, be aware that Windows NT DOES offer this protection with encrypted NTFS volumes. You clueless mindless Linux shill sheep-drone.

Re:That's not the right question

[Doctor Memory]

It would probably be simpler to encrypt person A's encryption key with trusted person B's public key and escrow it. Then, if something happens to A, B can retrieve the key from escrow and decrypt it. You could cascade this to produce a "chain-of-command"-style process, whereby the key must be sequentially decrypted by a string of people before the original is recovered.

Re:That's not the right question

[imbaczek]

Given enough money, every code is breakable, be it electronic cypher or safe combination.

Re:That's not the right question

[ichimunki]

How does money assist in breaking a cipher text that was encrypted using a one time pad?

Re:That's not the right question

[DarkTempes]

you need money to pay for the necessary processing power and crackers to break it almost anything (probably could remove the almost) today is crackable....most especially non-military non-intelligence encryption methods it's just a matter of time and money to break it that's the whole reason why they want quantum cryptopgrahy, as it would theoretically be unable to be cracked it's kinda like the general misconcept that one-way hashes are truly one way...they arn't for the most part, you can use rainbow tables to narrow it down to a rather small number of possibilities

Re:That's not the right question

[mibus]

Nothing can crack something encrypted with a One time pad, purely because there is an infinite number of "correct" possibilities, and no way to know which was intended.

Not unless you have a copy of the full pad, anyway.

(Basically, if you're randomly "cracking" the pad, for a five-character message, you'll get all possible five-character combinations as being equally valid! There's also no way to say "well, the first part is [x] thus the second part is [y]").

Hashes have nothing to do with one-time pads.

Re:That's not the right question

[Jim McCoy]

You are so full of it I do not even know where to begin...

you need money to pay for the necessary processing power and crackers to break it almost anything (probably could remove the almost) today is crackable...

Unless your money has somehow bought you a loophole in information theory, a properly used one-time pad is UNBREAKABLE and no amount of processing power will ever change this fact. You could burn cycles until the heat-death of the universe and be no closer to cracking the message than when you started. Even using "standard" cryptography it is easy to build a cipher which is computationally infeasible to break, the only thing which will change this is a breakthrough in mathematics.

most especially non-military non-intelligence encryption methods it's just a matter of time and money to break it that's the whole reason why they want quantum cryptopgrahy

Math doesn't work differently for the military, for spies, or for you and me. Quantum crypto solves the key distribution problem, but it does not actaully encrypt the message. If you and I were to use a quantum crypto channel to exchange a message an evesdropper could still sniff the key (it is improbable, but still possible), the only benefit of quantum crypto is that you would know that this evesdropping occurred. In this case evedropping becomes a denial of service attack.

most especially non-military non-intelligence encryption methods it's just a matter of time and money to break it that's the whole reason why they want quantum cryptopgrahy

You are just making this up as you go along, aren't you? A hash is used for authenticating messages, not encrypting them, but it suffers from the difficult problem of trying to take a large number of bits and distill them down into a smaller number of bits in a non-reversible way. It is that last bit (the non-reversible part) that is the problem. Your claim that you could build a rainbow table for something "simple" like SHA1 is laughable. Check out an article by a real physicist (I suggest Seth Lloyd's "Physical limits of computation") to get a reality check. The short version is that if you could use quantum spin to record your rainbow table into a mole of carbon it would just barely fit. OTOH it would take you around 10,000 years to initialize your super-database because you are limited by how quickly you can flip bits (which takes energy and produces heat) and unless you want to be computing at the wavefront of a thermonuclear explosion there is a practical limit to how much energy you can put into your system. Now, when the time comes to read this data you are going to want to do a massively parallel search, so you need to spread out your data. To keep it under the previously mentioned heat limit you need to spread out your quantum database to be something on the order of 10^20 cubic meters, which is only 90% of the volume of the planet earth. I am sure that everyone else on the planet will be happy to live on the remaining 10% when your "infinite money" check clears the bank...

In short, physics trumps money in this case.

Re:That's not the right question

[soulhuntre]

Would it be possible to design an enryption system such that if semi-trusted party X spent Y CPU-cycles brute-forcing, it could be broken, but for all other parties no?

It's already done - several vendors implement systems where a master key can unlock sub-keys.

Re:That's not the right question

[izomiac]

AS other people have explained, true OTPs are uncrackable (the weakest part is the random number generator, but, unless you are trying to make a crackable OTP, even pseudo-random numbers are still essentially unguessable). But, you are saying that all crypto algorithms are crackable given enough money... Ok, for starters lets look at DES. Last time I checked, a machine that could crack a DES message in a day costed about $1,000,000. Since we're assuming infinite money that wouldn't be much of a problem. The problem is that it can crack one message a day. How many of these machines do you think exist in the world? Even large networks of computers take several hours to crack DES (I think the record's around three hours, but I could easily be wrong). DES, however, wasn't designed to have that much computing power thrown at it. So stronger crypto algorithms were developed. Take AES for example. Unless you somehow got extremely lucky (correct key in the first .00000...00001% of the keyspace) it is impossible to bruteforce/cryptoanalyse an AES encrypted message with today's technology (certainly not within someone's lifetime, even if they did live to 1,000 years, or 1,000,000 for that matter). But what about quantum computers? Sure, they'll eventually obsolete current encryption schemes, but that'll still take a while (if it's even possible to build such advance quantum computers). Right now, they can factor numbers like 18. Not exactly a threat to any modern form of encryption. Even with an infinite amount of money, you couldn't buy/build one that would be even remotely useful for cracking. So I'm sorry to disappoint you, but Big Brother still can't break modern encryption by throwing money at it. It's true that encryption is a deterrent (time/effort needed to crack), but right now the time factor is related to how soon computing power can catch up to today's encryption.

When in doubt, remember:

[Anonymous Coward]

"It contains all the design mistakes you can make, and manages to even make up a few of its own." - Torvalds regarding Mach/Microkernels (Though he says it's not OSX, I still think he meant it, he just didn't want bad press so he reclassified)

"For example, I used to like the _concept_ of microkernels, I just disliked every implementation I had ever seen (both Mach and Minix included, which was the basic reason for the debate/flamewar in question). These days I've pretty much come to the conclusion that the reason few people like microkernel implementations is that the whole concept is flawed -- even if it sounds good in theory." - Torvalds

Re:When in doubt, remember:

[Anonymous Coward]

Oh please. It's just one guy's opinion. Other very intelligent ppl *do* favor micro-kernel models.
When in doubt, think for yourself.

Re:When in doubt, remember:

[Detritus]

Since when did Linus Torvalds become an expert in the design of new operating systems? I'm serious.

He's a very smart guy and a gifted programmer, but he has restricted himself to a niche, implementing UNIX compatible operating systems on Intel architecture computers.

Re:When in doubt, remember:

[renoX]

Except of course that his OS is not only running of Intel computers..

As for reimplementing Unix, you're right that it isn't particulary original, which is a *good thing* because last I looked each time an OS tries to be original it fails..

EROS failed: they never got it off the ground (I wish better luck to its successor but the 'yet another language' will need serious marketing to be accepted..), Hurd has not failed yet, but whether it will success in gathering users is hard to say, do you see a pattern here?

Beside "normal" micro-kernels such as Chorus, QNX, etc.. the only "good" original "OS" I can think of is L4, but if we measure success by the number of users..

Capabilities

[Tet]

a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root.

This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS? But mechanism alone won't solve your problems. You need to have suitable policies that make use of those mechanisms. And as the Fedora guys have found out with their SELinux adventures, getting the policies right for any non-trivial system is a bitch.

Re:Capabilities

[Greyfox]

Yah. Your average home user will likely end up setting up an account with all capabilities turned on, thus putting you right back at square one with a "root" user. Every once in a while we see some bozo who wants to ignore 30 years of sysadmin experience and give his regular account root permissions. They usually say exactly the same thing too, "Oh, it's OK, I know what I'm doing," and "I'm not running anything important on my system, so no one will bother attacking it." You know who you are heh heh heh.

Security is a habit, like good hygene. Most people realize that they need to floss and change their underwear more than once a month and stuff like that. We just need to promote good security habits, too.

Re:Capabilities

[superpulpsicle]

For an OS to be a hit, it needs to be marketable. Windows has games, gui, buggy or not... it squeeze in noticible new features. Linux wasn't marketable until KDE and new features came in. Security is just a boring selling point.

Re:Capabilities

[plcurechax]

Your average home user will likely end up setting up an account with all capabilities turned on,

This is a research OS being worked on at an university (John Hopkins) by several graduate students. It is not intended to being part of Fedora Core 4.

Just like Trusted Computing platforms like Trusted Solaris and Trusted HP/UX (I forget the name for the Trusted version of VMS, and several others) this is not intended for mainstream replacement of "mainstream" OSes. For that look at PaX, exec-shield, NX support (processor feature supported in new versions of Windows and Linux), and Microsoft's Pallidium/NGSC and whatever name Intel is using for their trusted (DRM-friendly) hardware (chipsets and motherboards).

Re:Capabilities

[Anonymous Coward]

Most people realize that they need to floss and change their underwear more than once a month

Once a month?! what are you a metrosexual? I change my underwear every other month and it's fine, ask my colleagues. They're the ones sitting way over there - next to the open window.

Re:Capabilities

[Lorens]

* And that is exactly the point! *

The user has a lot of privileges. He can read all his files, delete them, whatever.

But there is absolutely no reason that mplayer ou xpdf should have any rights whatsoever except to read (-only) the file you give to it, and to use some real estate attributed to it by the window manager.

(xpdf had some buffer overflows recently...)

So you can run an untrusted program, even jokes sent in e-mail, since they are confined, and your MUA is confined anyway in case there is an interpretation problem in the subject (remember those % and .. in URLs?)

With a cap-aware window manager (that is also developed, and even works), this becomes natural.

Re:Capabilities

[lems1]

Agree 100%.

Perhaps people should go and read these two articles/essays first:

http://www.eros-os.org/essays/capintro.html
htt p://www.eros-os.org/essays/ACLSvCaps.html

Re:Capabilities

[Anonymous Coward]

They're aiming for more. From the site:

"If we are successful, we will produce the first general-purpose operating system and utility set with end-to-end verification of security and correctness properties that extends all the way through to the code. If we are not successful, we will merely move the ball forward substantially towards this goal.

"Since this goal is obviously daft, it may be relevant to say something about why I think it may be possible to pull it off..."

Re:Capabilities

[Elwood P Dowd]

EROS has other advanced features aside from capability based security:

What is Persistence?

Different systems use the word ``persistence'' to mean very different things.

In EROS, persistence means that the system periodically saves a copy of everything you are doing. If your dog trips and knocks the plug out of the wall (don't laugh - my dog actually did this to me), EROS will restart wherever it last saved your work, complete with windows, applications, and everything you typed.

Typical configurations of EROS save what you are doing every 5 minutes. In practice, this seems to be often enough to prevent major losses.

IIRC, you can do all kinds of fun things with your checkpoints, like point them at tape drives once in a while, or send them over the wire to hot backup hardware, or whatever. But the point is that you aren't backing up your disk, you are backing up your entire system state including running processes.

They also advertise that it is a RTOS, but I don't know what they mean by that in this case.

Re:Capabilities

[naasking]

This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS?

You wouldn't need a separate OS... if it weren't for the fact that Posix/Linux "capabilities" are not real capabilities. Furthermore, EROS/Coyotos has much finer-grained access control, ie. a capability to a memory page, or a disk sector, rather than "capabilities" only to coarse-grained objects such as terminals as in Posix.

Re:Capabilities

[RovingSlug]

... Every once in a while we see some bozo who wants to ignore 30 years of sysadmin experience and give his regular account root permissions. ...

I pray for the day that every computer user neither needs to be a sysasmin with 30 years of experience nor needs the perpetual support of sysadmins (IT departments, sysadmin friends, etc).

Just because it's the status quo doesn't mean it's the way it should be.

Re:Capabilities

[LnxAddct]

Have you ever used SELinux? It's security model is undeniably the best I've ever seen. The only thing is, if your not careful, you can easily lock yourself out of your own system. SELinux achieves just about everything EROS is trying to achieve, except SELinux actually extends it further and it runs on a platform with a lot of support and software already available. To check out what it is capable of, go download Fedora Core 3 which comes with it by default and has some policies for various services.
Regards,
Steve

Re:Capabilities

[Botty]

To all you programmers out there, I imagine they would have to lock the memory access while they write it out to disk. But how is this practical?

Do you really want your state information being saved every 5 minutes on a heavily loaded database server with 16GB or ram. Locking the memory pages would be a horrible mess to prevent corruption while pages 1-100 are simultaneously trying to be written to disk and being modified by program A.

Not only that, but as you approach large memory sizes, this becomes infeasable with current technology. The OS would spend most of its time trying to sync 1GB of memory so you get a clean state without mashing a read of variable A with a write on variable A. This becomes an even bigger problem as you get more CPUs in a system. If you want to prevent programs from writng to memory while you copy it down you are going to take a large performance hit, if you let programs modify the memory easier, then you risk not having a sane saved state.

Perhaps they have solved these problems? If they dont have a good idea of what they need to do already this seems like it would be an absolute B**CH to code with an ugly compromise between system speed and concurrent access and getting a reliable saved state.

When I tell VMWware to save my state, it stops THE ENTIRE VM and not a single instruction executed(inside the VM) until its done. Same with console emulators, there is a small pause while they stop the process from running until they're done writing the state.

Then, based on what I said above, how could they possibly be a real-time OS on top of that if they need to HALT execution of certain things to get state info. Real-time performance and saved states seems mutually exclusive to me. If you have even 1 real-time thread you cant afford to stop it to save its state thus your whole RTOS concept dies. If you want real-time you cant guarantee that you'll get a clean state saved.

How are they adressing these VERY LARGE issues? Perhaps someone can enlighten me if I am going in the wrong direction with this though...

(Sorry, I just got done making a C++ class thread safe and its a pain with many compromises. Thats where most of this rant came from.)

Re:Capabilities

[naasking]

I run gentoo SELinux on my server. SELinux is a difficult to use system, and I suspect is even less powerful than a full capability system like EROS/Coyotos/KeyKOS. The only advantage of SELinux is it's current hardware support.

Re:Capabilities

[Elwood P Dowd]

1) Obviously these are hard problems, and these smart people have worked very hard on all the issues.

2) They are abandoning persistence for Coyotos.

And no, the concept of an RTOS does not go out the window due to persistence. No, they do not have to halt everything to do a checkpoint. If the performance hit of checkpointing would not allow them to keep their contract with a real time thread, then... they would not make the contract with that real time thread, and their RTOS is still an RTOS, isn't it.

Re:Capabilities

[ajs]

Your reply is a non-sequitor. The grandparent was simply drawing a comparison to Fedora's use of SELinux to demonstrate the kinds of social problems that security roles do not solve for.

Please read before posting.

Re:Capabilities

[Anonymous Coward]

Have you ever used SELinux? It's security model is undeniably the best I've ever seen.

What's the technical difference between SELinux and systrace?

Re:Capabilities

[Deusy]

"This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS?"

Why the need for any competing software at any level? Why not just focus on existing stuff and forget innovating through new ideas in new software?

I'm glad Linus didn't talk like that.

Re:Capabilities

[Anonymous Coward]

Capabilities are not intrinsically stronger than access control lists. There is no silver bullet here. The point is to subdivide, so that an attacker (or a bug) can only affect a known portion of the system, not the whole enchilada.

In particular, capabilities don't keep a mail tool from being shipped with debug mode turned on. They don't keep your browser from having a buffer-overflow bug. They just see to it that a compromised browser can't read /etc/passwd. A compromised mail tool can't start logging keystrokes. And like that.

Re:Capabilities

[Tet]

Why not just focus on existing stuff and forget innovating through new ideas in new software?

I agree with what you're saying completely. I just didn't see any new ideas here... Innovation doesn't come from rehashing old ideas just for the sake of it. It comes from writing something new because the old system didn't do what you wanted.

Re:Capabilities

[Anonymous Coward]

This has been possible in Linux (and some proprietary Unices) for some time now.

Not to mention Windows NT, but we all know where the default policies put that.

Re:Capabilities

[Anonymous Coward]

There is no technical difference between SELinux and systrace, because they are both severely flawed and that is what the capabilities in EROS and Coyotos are trying to fix.

Re:It's a microkernel.

[alnjmshntr]

only on slashdot can a comment like Microkernels SUCK! get modded flamebait.

Re:EROS utilizes FUCK

[Hooya]

and life's a BitCh.

Coyotos

[Deathlizard]

Hmm. does it work with Roadrunner? :)

Re:Coyotos

[dAzED1]

why would roadrunner care? They're just handing out an IP...

Re:Coyotos

[B3ryllium]

In order to get it to work with Roadrunner, you need to buy some Acme-brand ADSL rocket shoes.

Guaranteed to singe hair off of nether regions.

Re:Coyotos

[Anonymous Coward]

it doesn't run very well, but your mileage may vary snice i had it installed on this lousy Acme computer

Wrong

[Anonymous Coward]

There are many examples of Unix systems with mandatory access controls, and role based capabilities. For Linux, you have GRsecurity, SELinux, and RSBAC.

There are others too.

Son of a...

[tepples]

Imagine what happens when Microsoft tries to compete by making a buggier implementation of BitC. It'll give us yet another reason to BitC# at Microsoft.

Re:Son of a...

[Anonymous Coward]

You forgot to include .NET!

Re:Son of a...

[Kyont]

Dang, you beat me to it. I was thinking of a version with a hyperthread-supporting local application protocol (BitCH-SLAP).

Re:Son of a...

[Panaflex]

Heh.. if the include files have .h suffixes.. then every program should start like this:

include( "Bitc.h" )

Pan

Licencing.

[Anonymous Coward]

Is it me, or is there no mention of what kind of licence it will be distributed under?

I had hoped to see some mention of one of the following:

+ GNU;
+ BSD;
or MIT.

Re:Licencing.

[Lorens]

EROS was distributed under GPL (eventually). One can hope that it will be the same here.

Re:Licencing.

[Jonathan S. Shapiro]

Yes, we probably should have answered this. Bear in mind that the Coyotos project is very new, and the website is only a week or two old.

All of the work done in SRL is done under open source licenses. It is our strongly held philosphy that real security cannot be accomplished without the light of regular public exposure. If you want it done wrong, check with Redmond.

We haven't selected a license yet, but it will almost certainly be GPL/LGPL as EROS was.

shap

security

[dioscaido]

I don't know... the unix model of security seems adequate, if not sufficient, for most (all?)security needs. The problem comes when users get thrown in the mix. It's an eternal battle between usability and security.

Re:security

[kahei]

This is a horribly, horribly naive thing to say.

The unix model of security is extremely simplistic -- though it could be argued that this is preferable to a more comprehensive system that happens to have gaping holes made in it, ie Windows. I suppose you could argue that the unix model is effective considering it's extreme simplicity -- but it remains a system not designed with security as a primary goal, and not granular enough for security to be easily retrofitted.

You would be well advised to at least learn about Windows, not because it is particularly secure, but because it's easy and lots of security concepts from outside the Unix world are found in it, such as ACLs and fine-grained (only compared to Unix) privileges.

Of course, Windows then goes and does exactly what Unix does, and gives all the privileges to one user and requires that user's token to be used all over the place. But to be honest, usability is what propagates a system, not security.

Re:security

[Anonymous Coward]

Hmmm ... sounds like a nice, warm & fuzzy little world you live in.

If you pay any attention to the OpenBSD project(s) .. you'll recognize, your statement is pretty much wrong. There is a ton that can be done to improve security in the unix world.

Re:security

[TheAwfulTruth]

"Of course, Windows then goes and does exactly what Unix does, and gives all the privileges to one user..."

That is of course only /by default/.

Any proper admin can give any differnt list of permissions to any different number of users. You can have DNS admins and printer admins and Install admins and anything else you like. If you set it up that way.

The problem is, people are so exasperatingly lazy about actualy *doing* anything about security that it really doesn't matter in the end. You can hand the most sophisticated and secure OS to a person and the first thing they will do is assign every priv to a single user so they can start using their machine. (Someone in this discussion thread even mentioned that would be the first thing they would do with this system by hacking it)

"Security" in my mind is doomed to failure as a general state of being becuase only about 5% of the population cares at all, even the population that should be educated on the subject, I.e. the Admins.

This is the sad truth. :(

so...

[mogrify]

#include <BitC.h>

License?

[tdvaughan]

Does anyone have any idea what license it uses? I hunted around their site but couldn't find any info. The fact that they plan to release the source and releases suggests some sort of OSS license though.

The same old saw

[Anonymous Coward]

That's like saying "cars are safe enough, it's the drivers that are the problem." Actually, there are a whole bunch of things that have been done to make cars safer: seatbelts, better brake lights, ABS brakes, etc. Saying "it's the users' fault" is just an excuse for doing nothing, when there are plenty of things that could be done. I'm tired of hearing it.

Re:The same old saw

[Anonymous Coward]

That's a bad analogy. Cars are very safe, but the vast majority of humans are incapable of operating them safely. Very few accidents occur because of mechanical failure or engineering flaws. Operating systems are mostly insecure due to poor software engineering.

A good start

[LordNite]

Capabilities and verifiable code are a good start. Now it just needs a systems programming language that allows for proof (mathematical proofs that is) of correctness. Basically, get something better than C and some of the problems inherant in UNIX will disappear.

Re:A good start

[Jonathan S. Shapiro]

See the BitC specification.

And contrary to what one reply said, BitC is memory safe.

It is true that in general program verification is undecidable. This means that there exist some programs whose correctness cannot be decided. In practice, there is an even bigger class of programs whose correctness we don't know how to even define. But there is a large class of programs that are both definable and verifiable, and operating systems and compilers (correctly implemented) both appear to be in the class. There is a long list of work demonstrating verification success on similar things. I should put up a page referencing it.

shap

forgotten lessons of Ada 83 or too young to know?

[museumpeace]

"...It also specifies a new language, called BitC which allows the programmer to prove that the code implements certain semantics, thus providing another layer of verifiable security...."
Developers, promoters and users of this language should consider the fate of Ada83 language before they invest a ton of effort or money. Yes, it may be strong as Fort Knox but writing software costs money and the language supports provability but does NOT eliminate the need to do up front design and heavy integration testing at the end of a project...Only the proprietors of Fort Knox would consider the cost benefit ratio of such software worthwhile. The rest of us would have to weigh it more carefully. C-derived languages got a lot of code written quickly mostly because they did not encumber the engineer with many considerations beyond the function or behavior and representation of data...the "I'm not going to give you a chance to screw up" approach to programming embodied in Ada does not map well to typical [if somewhat shoddy] coding practices and creates a much steeper learning curve for would-be programmers. I admit I have yet to RTFA but I already have this "here we go again" feeling.

So many good ideas never make it...

[EmbeddedJanitor]

If it does not run POSIX or Windows programs I can't see anyone ever getting sufficiently motivated to ever use this for anything other than niche applications (eg. firewalls, secutiry equipment,...).

Computer security is a low priority concern for most people. If you had a perfectly secure OS, but not the OS you want then people would not even turn the computers on and that would be secure, right?

Secutiry is mainly a people thing anyway. Give 'em Linux and they'd just run everything as root.

Re:So many good ideas never make it...

[suso]

Well, provided that the world does not destroy itself first, if you give this OS design 10 years or so, I'll bet it will have just as many programs written for it as Linux does now. And it will be worth it.

Its like the saying goes "Saying that trinary computing is not worth it is like saying in 1990 that its just not worth it to build an open source unix like kernel".

Re:So many good ideas never make it...

[dgatwood]

Except that no one said that in 1990. The popularity of Linux was in large part a reaction to USL (Bell Labs) trying to crack down on the openness that Berkeley was showing with respect to UNIX proper. If anyone said it made no sense to build an open source UNIX-like kernel, it was because there already was one, and it was called UNIX.

This is a completely different situation. It remains to be seen whether this will see any traction in the industry. In a way, there are similar concepts, but they are all grafted on. Most modern UNIX/Linux varieties have some level of capabilities management, whether at the kernel level or through support apps (or both). Examples include sudo, Mac OS X's disk image and AppleShare mounting, etc. All of these involve things that are typically done as the root user, but are instead carried out by a non-root user through various mechanisms.

However, all of these systems have one major difference: the super-user can get around them. This is important when you consider how most OSes are used. Most computers are single-user systems where one person has complete control. The rare exceptions are usually in companies, where, as many people have mentioned previously, data recovery from terminated/dead/retired employees is far more important than employees hiding data from each other.

The idea of a language designed around security seems interesting in a lot of ways, so long as the implementation isn't too inconvenient. I'm not quite as convinced about the notion of changing the security model of an OS. I'm sure the DOD would love it, but I'm not convinced it has any practical advantages in the real world, at least as a replacement (as opposed to an augmentation) for existing security models.

Perhaps that's how their security works

[freejamesbrown]

Make the interface so hard to use that no one can even get to anything. No command lines or script interfaces, and yet everything is tabbed funny and offset so you can't even tell what you are looking at with the GUI.

m.

RTFA dude

[Anonymous Coward]

They developed a language called BitC for doing exactly what you described. You not only didn't RTFA but you didn't even read the one-paragraph story version of it. But you know enough to post!

Re:RTFA dude

[LordNite]

The language is still based on C and allows, through the "unboxed" types, direct pointer access. (Unless I am misreading the BitC doc.) Allowing any sort of direct pointer manipulation foils any attempt at mathematical proof.

Therefore I think that my comment stands.

Re:RTFA dude

[LordNite]

These guys are quite a bit smarter than me, however.
BitC looks cool. It looks like (again) a step in the right direction.

I am beginning to think, though, that mathematical proof and the low-level memory access required to implement operating systems are to some extent mutually exclusive.

Re:RTFA dude

[Anonymous Coward]

uhm, wouldn't this have some bearing on your plan for a formally complete system ?- Godel's Incompleteness theorem

Re:RTFA dude

[Asterixian]

Actually, being based on C is not what makes verification problematic. Verification of programs in any Turing-complete language is undecidable!

As a simple example, try to verify whether the following program obeys certain "security" properties:

if (system.verify(program)) {do evil deed}
else {be nice}

This is the same classic style of counterexample used to prove undecidability of the halting problem, of virus detection, and so on.

Re:RTFA dude

[Anonymous Coward]

Verification of programs in any Turing-complete language is undecidable!

All that this says that there exist programs whose correctness can't be proven. It does not say that we cannot produce programs which are correct along with proofs of their correctness.

Re:RTFA dude

[rjh]

Among the things which make software verificaton difficult are aliasing (pointer aliasing, referencing, equivalences), arrays, side effects, and lack of functional composition.

As it happens, C has all of those save for referencing. Pointers? Yep. Equivalences? Yep. Arrays? Yep. Side effects? Damn near inescapable even if you try. Lack of functional composition? Yep.

The Undecidability issue is a complete red herring, as several others have already pointed out.

Yes, C really is that unsafe of a language, to the point where I'm hard-pressed to think of how to make a language less safe than C. Use something else if at all humanly possible.

It has no writeable drives or network access

[freejamesbrown]

It has no writeable drives, network access, or output port support and the only GUI looks suspicously like a windows 95 bsod... hmm.

m.

with a Linux emulator

[Anonymous Coward]

must port linux emulator to windows....

Re: with a Linux emulator

[Anonymous Coward]

been done, it's called LINE. Syscalls are dreadful dread slow in LINE tho, so you'd probably want coLinux instead, which is a port of usermode linux to windows. It's damn fast -- in fact, some I/O outruns native Linux itself.

Need for a webmaster?

[JoloK]

Man, those Coyotos folks desparately need someone at least a little web savvy to handle their project site. What a disaster!

Re:Need for a webmaster?

[Anonymous Coward]

Name one decent looking open source project site.

Re:Need for a webmaster?

[KillerDeathRobot]

Mozilla.org

No software so secure

[hey]

I'm sure it'll be super-secure since there will be no buggy software for it (actually no software). There won't be an worms or virus either!
Just one problem - it can't do anything useful either.

Re:No software so secure

[arudloff]

(ahem)

"complete with a Linux emulator layer."

Re:No software so secure

[Jouser]

I didn't see any Linux software at Best Buy this weekend...

Re:forgotten lessons of Ada 83 or too young to kno

[plcurechax]

Since Jonathan S. Shapiro is a professor at John Hopkins University, and has been involved in EROS since 1991, I suspect he has had the chance to met Ada 83.

Re:It's a microkernel.

[Anonymous Coward]

only on slashdot can a comment like Microkernels SUCK! get modded flamebait.

Only on Slashdot can a comment like "microkernels ROCK!" get modded insightful or informative. Or debated at all, for that matter.

Re:forgotten lessons of Ada 83 or too young to kno

[museumpeace]

To elaborate a bit on what happened to Ada 83:
That version supported provability of correctness, a feature that was easy to sell to a security conscious customer [not customers as there was really only one]. But that provability meant that many dynamic coding practices, in particular the method dispatching needed for object oriented programming, were not tolerable: for a compiler to prove code was right, it had to be immutable and look at run time exactly as it did at compile time. This restriction proved intolerable and the next version, Ada 95, added features in a vain attempt to achieve OOness...and explicitly abandonded provability for the more valuable and pervasive need: re-use. on-the-fly and informal and inherent re-use by inheritance. Too little too late though: what got proved was that Ada proved to be a language even its mother didn't love. [I mean the BNF has 277 production rules...it is seriously ugly to map to other languages.]

rigorous = unpopular

[PMuse]

It sounds wonderful, doesn't it?

Come, raise a toast to all those restrictive languages that are so wildly popular with programmers today. Let us all thank Wirth that none of their free-wheeling, permissive contemporaries are still in use.

But you need r00t to change the iptables.

[aristus]

Sucks, eh? :) The reason to have a "superuser" is because new stuff comes up all the time. The capabilities model is useful when the general applications are already known, and set out at system setup. Once a system is running for a couple years and there's a new Whizbang Network Filesystem Protocol, you either need to set the bastard up from scratch or have some user that can define new capabilities. That user is effectively r00t.

Re:But you need r00t to change the iptables.

[Anonymous Coward]

> you either need to set the bastard up from scratch or have some user that can define new capabilities. That user is effectively r00t.

No it's not. ALL it can do is assign new capabilities. It can't, for example, alter the audit trace of its activities. It can't even access those functions -- far as the granter is concerned, the functions don't even exist. Yes, the granter is quite powerful, but there is nothing that requires a single granter of all capabilities -- or even that one exist at all if new stuff isn't coming up all the time. Real-world secure systems don't screw with their configuration just for the hell of it.

Re:But you need r00t to change the iptables.

[tepples]

Sucks, eh?

That's why there's sudo.

Once a system is running for a couple years and there's a new Whizbang Network Filesystem Protocol, you either need to set the bastard up from scratch or have some user that can define new capabilities.

For production servers that experience a radical change in functionality, some would argue that setting the lovechild up from scratch is probably preferable.

What about a tripwire?

[mac-diddy]

Sure, this might be a secure OS, and you might be using "Systems Management," but unless you are using something like radmind to fully tripwire your machine, you really don't know what's there.

I don't think so.

[hummassa]

Not really a joke

OT. Sorry, tried to start my own EROS project

[Anonymous Coward]

"For those who haven't been following the EROS project,

Sorry, I tried to start my own EROS project.

I tried BitC once...

[goldspider]

But it was a real BitCh to learn.

Another one for the hosts file... Vibrant Media

[gluino]

One way to block those double-underlined "intellitxt" ads is to host-file them... (look in html source, search for intelli...

0.0.0.0 uk.intellitxt.com
0.0.0.0 toms.us.intellitxt.com
0.0.0.0 www.vibrantmedia.com
0.0.0.0 vibrantmedia.com
0.0.0.0 intellitxt.com
0.0.0.0 compnet.us.intellitxt.com
0.0.0.0 askmen.us.intellitxt.com
0.0.0.0 forbes.us.intellitxt.

Liyotux

[Doc Ruby]

I think those problems can be solved better by relying only on memory-access objects with bounds checking, and signature/ACLs for every method call, and a stripped microkernel that's privileged only for HW and IPC access. Linux itself could be refactored along these lines, applying lessons learned by experimenting with Coyotos.

Re:Liyotux

[foxed]

Linus hates microkernels.

Re:Liyotux

[Doc Ruby]

Linus doesn't own the trademark on "Liyotux", and can't stop us from using the kernel source to make it, as long as we release the new code under the GPL.

Re:Liyotux

[foxed]

I never said he could stop you, nor do I think he's infallible.

But it was an early design decision to have a large monolithic kernel, and AFAIK Linus still thinks it was a good one. We have a real, very usable OS. Other microkernel-based OSs seem to have taken a long time, be big on good design and small on functionality.

If you think a microkernel is so fundamental to a good OS, why not contribute to HURD or build on Mach instead of rewriting/refactoring Linux?

Re:Liyotux

[Doc Ruby]

I never said that you said those things. But when we mention something, the implication is that it matters. When a contradictory viewpoint matters, it means its concerns could stop what is being suggested. You don't really need that spelled out, right?

Linux started with modules compiled into the kernel, and now they're not. I'd like to see Linux continue to evolve into a nanokernel, and it's a good place to start. HURD and Mach aren't good starting points for becoming good OS'es, because there's no SW to run on them, compared to Linux.

Doesn't really matter does it

[bigberk]

Doesn't matter too much what extra security layers are in your OS if your users are just haphazardly clickety-clicketying everything in front of their noses.

Re:Doesn't really matter does it

[Anonymous Coward]

If you users can't be trusted, remove their ability to install anything.

Re:Doesn't really matter does it

[William Tanksley]

Actually, it does matter -- if the user's email applications can't run programs that delete files (and such), the users can clickety all they want.

Capabilities are amazingly powerful. If you can't refer to something, there's no way to possibly mess that something up.

That does require some clever configuration, but current work seems to show that such configuration is conceivably possible.

-Billy

Re:Doesn't really matter does it

[Anonymous Coward]

users won't settle for apps that have such limitations. realistically, users will need applications with lots of dangerous powers. and therefore they ultimately have the power to destroy their computers (or not).

BitC?

[Trolling4Columbine]

For a while there I thought this new language was named after my ex-girlfriend.

Re:BitC?

[gimpimp]

with jokes like that, i'm surprised you ever had one.

kidding :)

Hmmm...

[noblesse oblige]

While that was nice, my favorite feature of EROS (besides the name) was the idea that instead of a filesystem a disk was simply non-volitile memory cache. That facilitated my next favorite idea, orthogonal persistance, the somewhat like a persistant software suspend. I'd be interested in finding out (while the home page does not say) if these were the shortcomings of EROS it was alluding to.

Re:Hmmm...

[naasking]

Unfortunately, transparent orthogonal persistence is pain once networking is tossed in the mix. If the code must recover from the failure of a network, then why not the failure of the machine as well? The circumstances are so alike, that it just makes sense to abandon transparent orthogonal persistence, and devise a solution that will work uniformally in both circumstances.

No that is an insightful question

[ChiralSoftware]

If you browse the Eros archives, you can see that Mr. Shapiro (the creator of Eros) makes frequent references to Multics as the inspiration for Eros (and therefore Coyotos). I'm not able to answer that question myself but clearly there is a close connection between Coyotos and Multics.

Re:No that is an insightful question

[naasking]

There is no direct historical relation between Multics and EROS. See The Path to Coyotos. Multics is not even capability-based, and doesn't even appear on the map of capability computation which shows the development history proceeding from Hydra, to Gnosis/KeyKOS and ending at EROS.

Re:No that is an insightful question

[CodeArt]

I had in mind Multics ring architecture where most restricted subsystems run in rings 6 and up. This means that for example Web browser can be moved into ring 7 and the system will be automatically protected from malicious and hostile outside environment. It seems to me that Multics architecture can be more easily adapted to existing two-ring architecture of Windows and UNIX (kernel and user mode) without breaking millions of existing applications.

Coyotos?

[ee96090]

Am I the only one who read it as Coitus?

Re:Coyotos?

[Anonymous Coward]

Make sure you have Coitus with your BitC!

Eros?

[Anonymous Coward]

Why not just call it pr0n OS?

Interesting for inspiration only

[Anonymous Coward]

We can't just scrap the existing OSs of today, even Windows. These will simply have to be hardened as best as we can. I see a new OS as useful mostly for testing ideas that can be borrowed by other mainstream OSs.

security sells pile of shit

[Anonymous Coward]

If you only use the buzz word "security" you can sell a pile of shit nowadays. And I am not talking about energy yielding cow manure...

Naming

[kallisti]

So, instead of using the name of a God of Love, they changed to the name of a prostitute's rights organization. Do they ever want to be found in a search?

Re:Naming

[belg4mit]

Ummm, a coyote is a canine (hence the logo of the linked group). Who the hell do you expect to find your random reference?

Re:Naming

[KillerDeathRobot]

But they're not Coyote OS, Coyotos looks like a regular word.

Re:forgotten lessons of Ada 83 or too young to kno

[Dasein]

Go ahead and RTFA. I'm only marginally familiar with Ada83. However, I'm a fan of functional programming languages. I can't tell you how many times I've wished for type inference and pattern matching.

The problem is that, like Haskell, I will probably never work for a company who adopts BitC.

A tight race between two emerging Secured OSS

[Dark Coder]

Which one will it be the first to procure the secured operating system?

IEEE BOSS

or

Coyote OS

My money is on Coyote.

Re:A tight race between two emerging Secured OSS

[maniac_inside]

Yeah, especially since it is the one that has been slashdotted :-)

SELinux, capabilities

[ceswiedler]

And this will suffer from the same problem: capabilities and ACLs are very difficult to get right, and require extremely good tools as well as informed administrators.

For quite a while (as the OP points out) the Linux kernel hasn't checked for "uid=0". Instead it checks for one of many capabilities, like CAP_SET_SYSTEM_TIME or whatever. You can give these fine-grained capabilities to other users. SELinux does something similar for applications, letting you restrict in extremely fine-grained detail what a process can do.

The key word is fine grained. It's pretty difficult to build a sand castle if you have to move individual grains. If you can manage it, it's one hell of a sand castle, but you need tools, patterns, and layers to do it.

Implementing capabilties, roles, contexts, etc. doesn't solve anything by itself, any more than a compiler solves problems by itself. It gives us the ability to solve the problem, but we're still left with the hard work.

The most interesting work going on in this area IMO is (believe it or not) Fedora. They're trying really hard to integrate SELinux into a usable operating system. It's much harder than it looks; at the moment they only have certain services running under SELinux restrictions, but eventually they'll get to a complete model where it really will be difficult to comprimise the system.

It's not hard to secure a system; just turn it off. It's very hard to secure a system so that it allows "approved" actions and disallows everything else.

Re:SELinux, capabilities

[LurkerXXX]

VMS/OpenVMS admins have been doing that for a long, long time...

Re:SELinux, capabilities

[William Tanksley]

The things the Linux kernel calls "capabilities" aren't the type of capabilities that EROS and Coyotos talks about. Making them finer-grained, as you say, would only increase the security problem and slow the system down. Read up on "object capabilities" to see what is meant, and why they can make system administration much easier and safer.

-Billy

Re:SELinux, capabilities

[Anonymous Coward]

There is no reason why users, administrators or distributers should define the required capabilties, application programmers can do that just fine! In fact its what they do when they type OS_set_time_of_day() and OS_how_about_fetching_me_file(filename). (And lets not forget the ever populair OS_SSL_connect_to_guy_with_certificate(guywithcert .com,certificate) )

The trick is ensuring the user and administrator know what is going on. Something the feodora people currently cant really do as messing with capabilties is, if you allow me to summarise your post, black magic. No user is ever going to check what permissions an application got using a commandline tool and some technical information on what a specific capabilities means. I recall attempts to fix this by promting users if they would like to give an application permission to do stuff once the application requested something from a SElinux kernel

Once the OS allows for fine grained access control, and application programmers define the grains, solving this isn`t a structural problem but a userinterface problem. I like the java web start aproach (similair to applets). Basicly you distribute software along with a list of required capabilities/permissions. Once someone installs software this (short) list is shown in very plain english along with the identity of the person/organisation that signed the software. The users or administrator can then make an informed decision, do I trust person/organisation X with capability Y. In java webstart the legwork of ensuring that as a result of this decision only X can do Y or nothing at all then goes to the webstart GUI and the java sandbox.

Ofcourse this can be optimized, there is no need to ask if a person trusts the operating system coders with his or her data combined with network access and everything else, the user does this by running the operating system. Also, once one application signed by a person gets permission to do something its hard to think of reasons why other code signed by the same person cant get the same access. And when in a coorporate environment a software source has been declared trusted for a purpose this decision applies to all machines that can be used for this purpose, it would be nice if this decision could be configured into these systems somewhat efficiently.

Anyway educating users about what application permissions are (read and write personal files and connect to somguy.com) should be easier then explaining what file extentions are not okay for email attachments today *and* what vendors have a reputation of selling code filled with the most stupid buffer overflow bugs *and* explaining what zombie machines, spyware and open relays are.

Re:SELinux, capabilities

[dumky]

The difference is that systems can't be secured today because it requires too much configuration (ACLs) and ACLs are limited anyways. But capabilities allow for better security starting from the design. It's less in the hands of administrators and more in the hands of developpers.
Agreed that it's not trivial for developpers to get right and it will require some training (the same way that programmers are trained to good design). It's lucky that it makes things easier for developpers by allowing for more focused security reviews.

Also it makes things less error-prone, by being secure by default (no authority is implicitly given to a new process unless some capabilities are explicitly given to it).

Mac OS X, however does deal with this issue.

[Aram Fingal]

The File Vault feature of Mac OS X is an example of what the Anonymous Coward said is missing from Unix/Linux/MS Windows, if I understand his comment correctly. File Vault deals with the possibility of a lost person/key by having a master password, separate from root. It's also a stronger encryption than what is used for authentication as root to the OS.

This is like the behavior where you typo your login password after the eighth character. You get into your account because the OS, like other BSD based OSes, only uses an eight character password, but your keychain won't unlock until you provide it the full, correct password.

Re:Mac OS X, however does deal with this issue.

[sp0rk173]

You get into your account because the OS, like other BSD based OSes, only uses an eight character password

Nope. Both FreeBSD 5.3 and OpenBSD 3.5 require you enter your entire password, even if it's longer than 8 characters. I just tried it on a couple machines. I remember that both RedHat and SuSE 9.1 only required 8 characters of a long password back when I had access to machines that ran those...I never understood why. I just chalked it up to Linux's inherent insecurity.

Re:Mac OS X, however does deal with this issue.

[Dog's_Breakfast]

The problem existed on all Unix (and Unix-like) systems, but it was solved a few years ago. Any recent Linux distro behaves the same way as the recent BSDs - you have to type the entire password, not just the first 8 characters. I'm trying it right now in Fedora Core 3, and I can confirm that my 12-character passwords require that I type all 12 characters.

Re:Mac OS X, however does deal with this issue.

[williewang]

Only older versions of *NIX use the old DES encryption algorithms for passwd hashing. MD5 is commonplace now (which allows for >8characters--up to 128 for the insane, actually--and blowfish is offered on all BSDs (blowfish has yet to be cracked, to my knowledge, while there are many MD5 crackers out there). I would imagine it is available on linux as well.

Re:Mac OS X, however does deal with this issue.

[sp0rk173]

Very good to know. I always thought that Gentoo required my full password but, but as i no longer use it (or any linux distribution for that matter), I couldn't test it out.

Long-running processes

[Anonymous Coward]

That's funny but it does make sense. A process is just a state that can be serialized like any other state. And any state that can be serialized can be unserialized on some other piece of hardware, why not. But that is a very funny concept.

Assigning Permissions

[Wallslide]

I'm curious how an OS with no Superuser can allow someone to assign permissions to other users. Are there Superusers for different parts of the OS, and if I want my access to span across these parts, I have to get access from multiple "superusers?"

Re:Assigning Permissions

[Anonymous Coward]

Something along these lines:

Have a capabilitor account (or several) which assigns capabilities. Assigning capabilities cannot be delegated to any non-capabilitor account (except via su login). No capabilitor account may possess any other capabilities (such as creating users, accessing filesystem data, or starting processes).

Now a compromise on that account is not sufficient to execute arbitrary code (but may allow D-O-S as the account can revoke capabilities from principles that need them).

Color Me Paranoid

[ewhac]

While I can see a role for EROS and other capability-based systems in places where security is not just important, it's the product (banks, the military, intelligence agencies), I become deeply suspicious when someone suggests placing such systems in the consumer marketplace (desktop computers, media servers, etc.).

The reason I become suspicious is because capability-based systems are designed to distrust the person using them, including the machine's owner. Again, in environments where security is paramount, this is a reasonable thing to do -- you don't want personal or sensitive information getting in the hands of an unauthorized person, even if they own the machine it's stored on. But in all other environments, the machine should treat the owner as God and obey all commands and yield up any and all data He/She demands.

I fear that capability-based systems will be one of the prongs media companies will use to attack Fair Use and other rights. I worry that "content providers" will demand PCs that distrust their owners and obey their commands, not mine. Capability-based systems are an excellent way to bring this about. Yes, I know capability-based systems can be hacked into obeisance, but it's a lot more trouble. Frankly, I would prefer it didn't happen at all.

Schwab

Re:Color Me Paranoid

[alienmole]

I agree with all your concerns. But one big problem is that the need for better security of the "distrust the user" kind extends far beyond the examples you gave. Many fairly ordinary companies have multiple levels of sensitive information - stuff only certain managers and departments should have access to, etc., and stuff that administrators should not have access to - and the existing OS mechanisms for dealing with all of these requirements are pretty weak. Many companies would jump on board very quickly if capability systems were widely accessible and well-integrated into existing environments (i.e. Windows).

So then the big question will be, is it going to be worth Microsoft's while to maintain an entirely different security model for home use than for business use?

Of course, there's always Linux...

Re:Color Me Paranoid

[treyb]

Howdy ewhac!

We don't design capability systems to distrust their owners or operators. Rather, we design them to do exactly what we tell them and no more. With a capability system, you can configure an email client to run any executable/script/whatever that shows up in your inbox and restrict (or confine) it in significant ways: use no more than X% CPU, use no more than Y megabytes of RAM, draw into only this region of the display, etc. If the incomming executable wants other resources, a dialog box pops up and tells you exactly what it wants at which point the user gets to decide. In a typical UN*X environment, any program running as a user has all of the powers of that user, but with no practical way to let the user choose which files to protect or how many resources it can consume.

As far as Fair Use goes, I think that requiring a network authorization for each play of a media file will educate consumers more quickly than a billion-dollar ad campaign. I expect this education to cost the sellers of such restricted media a huge chunk of their bottom line.

-- Trey

Re:Color Me Paranoid

[naasking]

The reason I become suspicious is because capability-based systems are designed to distrust the person using them, including the machine's owner.

This is simply not the case. If you search the EROS and E-lang mailing lists, you will find many examples of the active project members asserting that securing a machine against it's owner is simply impossible.

You are mistaking "the user/owner" with "the software that runs on the user's behalf", ie. the shell, browser, etc. Capability systems are designed for the user to grant the least authority to programs that run on his behalf. They enable the user to protect himself from potentially malicious software by limiting the damage they can cause (read up on confinement and POLA).

Ultimately, the owner is in complete control of the machine. However, the programs running on the machine should be properly constrained in the capabilities they receive. This is proper security.

But in all other environments, the machine should treat the owner as God and obey all commands and yield up any and all data He/She demands.

Nobody will disagree with you here.The problem is: how can the user protect themselves against potentially malicious software that must operate on their data? This is the problem we are facing today with viruses, trojans, etc. This is the problem that capability systems are very well-suited to solving simply because they trivially follow the Principle Of Least Authority (POLA).

I fear that capability-based systems will be one of the prongs media companies will use to attack Fair Use and other rights. I worry that "content providers" will demand PCs that distrust their owners and obey their commands, not mine.

It's certainly a concern, but again, any machine is simply unsecurable from its owner. Just like how mod chips were developed and widely deployed by XBox users, so will any such "media conglomerate" security measures be circumvented.

Safety not formalism

[Anonymous Coward]

These people are creating a new language to program the operating system in, which "combines the 'low level' nature of C with the semantic rigor of Scheme or ML". When will people learn that it isn't the lack of semantic rigor (aka provability) of C that is the problem... it's the memory allocation and pointers?

Just look a the Java standard library, since it's roughly on the same par as a kernel (it is huge, complicated, and has to defend against malicious use). Sure, there are bugs, but in 10+ years there have only been like 2-3 security flaws cause by the standard library (as opposed to some vuln in a C-based library is uses), and those were problems with dynamic class loading. It's not because Sun's Java developers are THAT much better coders than anybody else, it's because Java is a safe language (no arbitrary pointers or manual memory handling).

Why doesn't somebody make a few tweaks to Java and use it to make an OS? That would be way better than some scheme language that has all the dangerous features of C added back in and that nobody wants to program in anyway (stylistically). But at least these guys are trying to use a better language for the OS.

Re:Safety not formalism

[Anonymous Coward]

Lack of semantic rigor is a problem for they want to do with the language. Java doesn't cut it.

Why the new language?

[de Selby]

I love what EROS did and have very high hopes for this project, but why the new language? Some Java people (maybe that's why...) already inspired by EROS created (or just 'E'), a capability secure Java based laguage.

Either way, things I like:
*Provable security
*Extremely fine grain, almost fractally self-similar, security
*No need for 'root'

Things I'm not so sure about:
*No filesystem (at least with EROS)
*Not having 'root' is such a change, it's hard for me to understand how someone would take care of a system

Re:Why the new language?

[de Selby]

"EROS created (or just 'E')"

Ack! It killed my "E-Lang (or just 'E')" link.

//Use preview. Use preview.

It's working though

[m50d]

Restrictive languages are far older than I am. And since they've been around all my life, I can handle them. I know C, I'm pretty good at it - after all, you have to be - but although there's a few very cool things you can do with it for fun, I'd honestly prefer something with bounds-checking for real coding. Not that I make mistakes, of course, and I even wrote one program that depended rather heavily on accessing just outside an array. But it's simply easier to write a good program if your language can stop buffer overflows for you.

Capability security systems under Linux

[mseaborn]

The purpose behind the EROS or Coyotos kernels is to provide a *fast* capability-based system. You can build a capability system on top of Linux using sockets and other mechanisms; it'll just be slower. It's easier to build in some ways, but the total complexity (including Linux's complexity) is higher, so you have a bit less confidence about how secure the whole thing is.

An example of this is Plash http://freshmeat.net/projects/plash/. Plash runs processes under Linux with access to nothing by default (by putting them in a chroot() jail, etc.), except that it can make requests to objects via a socket using an object-capability protocol. Plash also provides a modified GNU libc so that normal Linux executables make their filesystem requests as object invocations, basically virtualising the filesystem.

Plash shows how unmodified Unix programs would work under EROS/Coyotos: it provides a shell (similar to Bash) that lets you run Linux programs with access to a limited set of files, in a convenient way.

They should remove persistence, no question

[Anonymous Coward]

And here is why: They have been working on this since 1991. At some point a project needs to "shit or get off the pot". At some point all momentum is lost and people start making jokes about it (cf. Hurd) and then the project will never recover. The way to keep momentum is to not only make promises of what the system will do in the future, but to show them some of what it can do (maybe not perfectly) today. If implementing persistence is going to slow them down from getting something out the door they should leave it out. Also, not having persistence makes it more "conventional" which is going to get more software written for it. And finally, it's not at all clear to me that having persistence magically built-in is the right thing to do. That's not clear at all. Like in Java there are various persistence systems like JDO and Hibernate but they all have to have special query languages. That's the right way to do it. Persisting an object and just having an object in memory really do have different meanings and should not be handled "transparently". I think that if the Eros/Coyotos guys had had some experience with Java and Hibernate/JDO/etc they would come to a different conclusion about this.

Re:They should remove persistence, no question

[DavidHopwood]

Persistence was one of the things in EROS (and earlier in KeyKOS) that was completely implemented and worked fine. It is not difficult to implement, especially for people who have experience of checkpointing algorithms from two previous systems.

Nothing about orthogonal persistence stops you from taking a "conventional" approach to persistence (or a hybrid approach) in any particular application. Also Coyotos will have a Linux compatibility layer, which should help to get over the initial application compatibility hurdle.

Finally, having persistence built-in *is* the right thing to do for a capability system, since it minimizes the overall complexity of restoring the security state.

Re:forgotten lessons of Ada 83 or too young to kno

[Wesley Felter]

Only the proprietors of Fort Knox would consider the cost benefit ratio of such software worthwhile.

I think this is a great analogy for Coyotos. Developing and verifying the kernel will cost tens of millions of dollars, but once it's done it can be used by a lot of people for a long time without much change.

Persistence

[mknewman]

It appears that Persistence was removed from Coyotos. Not sure why, as it appeared to be one of the key features in EROS that differentiated it from 'conventional' OS's. Now what I'm reading is you are simply building a capability based kernel and will run Linux on top. Yeach. Marc

Re:Persistence

[Animats]

No, that was an improvement.

First, if you put "persistence" in the OS, the OS has to know about disks, which, otherwise, a microkernel does not.

More significantly, "persistence" means keeping your mistakes around. Memory leaks are forever. Software upgrades are very tough.

OS design needs to go in the other direction, that of efficient transaction processing, where execution environments are created, used, and quickly flushed. That's better from a security and reliability standpoint.

Re:Persistence

[naasking]

First, if you put "persistence" in the OS, the OS has to know about disks, which, otherwise, a microkernel does not.

Not necessarily. Both EROS and L4 have no knowledge of the disks in the kernel proper, yet both support transparent orthogonal persistence. Only knowledge of the memory mapping structures are needed, and the kernel needs to know of those anyway.

More significantly, "persistence" means keeping your mistakes around. Memory leaks are forever.

Until the software crashes or is killed. Then you restart the service. No different from a regular system.

OS design needs to go in the other direction, that of efficient transaction processing, where execution environments are created, used, and quickly flushed. That's better from a security and reliability standpoint.

Incidentally, both EROS and Coyotos support exactly what you suggest. Each IPC is an implicit transaction, execution contexts are extremely lightweight, and communication is blazingly fast.

See the Coyotos history page for a discussion of the properties of Coyotos. Or check out Towards a Verified, General-Purpose Operating System Kernel on the docs page

A simple solution?!

[adeydas]

How about having better password and encryption algorithm recovery features to close the loop-hole.

Re:A simple solution?!

[greenrd]

Uh, that would rather destroy the whole fucking point of encryption, wouldn't it.

Not true

[Wesley Felter]

Some researchers are working on trojan-resistant/phishing-resistant user interfaces that make it much harder for users to screw things up.

Security?

[KingBahamut]

Hmmm, might have interesting merits though. A security focused OS? Call me moronic, but isnt that the idea behind SElinux crap?

Re:Security?

[Anonymous Coward]

You're moronic.

That's not the EROS website!

[ahkbarr]

They have one for each state, like this:

http://www.eros-minn.com/eros.htm

They even have escorts for you if you need help installing.

Re:That's not the EROS website!

[Anonymous Coward]

I'd have to say that the website you pointed out is considerably better than the actual Coyotos website... The Coyotos site is the kind of website that was meant to be left in the 80's. It scares me that a group of people can build an OS but can't build a simple website that works..

Re:forgotten lessons of Ada 83 or too young to kno

[Anonymous Coward]

I admit I have yet to RTFA but I already have this "here we go again" feeling.

Funny, I have the same feeling about your post

No persistence

[Anonymous Coward]

Check the history, they're getting rid of persistence in Coyotos...they want to make it posix-compatible and more familiar to people. The other big change is writing the whole thing in BitC, using patterns that allow security proofs on the entire kernal: "If we are successful, we will produce the first general-purpose operating system and utility set with end-to-end verification of security and correctness properties that extends all the way through to the code."

Re:forgotten lessons of Ada 83 or too young to kno

[hercubus]

there should be only one...

CPU: 6502
programming language: assembler
OS: CPM
graphical desktop: none

now can we stop whinging about the one true OS / language / GUI??? _real_ programmers need none

Re:It's a microkernel.

[j1bb3rj4bb3r]

what the hell is the mod down for redundant???
did you read the whole thread?

Re:forgotten lessons of Ada 83 or too young to kno

[museumpeace]

its a lot to read..skimming

....skimming

....yumm, nice parens! tastes a bit like Lisp...hurray for econmomical parsing.
....skimming...
monomorphic variables ? what happens to procedure with two variables not bound as to type? infer all you want but how to mix/promote types?
....no module idea, charset limited to 7bit unicode: thats gotta get fixed.

(fixint size align signed)

OMG! Shades of Ada "MOD" types in wolves clothing!..breaks all attempts at straightforward mapping to C/C++/Java short of introducing a class template that replaces "int" and overloads all the arithmetic and bitwise operators...yuch! SKIMMING HALTED

indeed, here we go again. Actually not a bad language...just not of this world.

Re:forgotten lessons of Ada 83 or too young to kno

[William Tanksley]

Developers, promoters and users of this language should consider the fate of Ada83 language before they invest a ton of effort or money.

Yes -- Ada83 died on the vine not because it couldn't get programmers, but because it couldn't get reasonable compilers. The hurdles were just far too high.

Now there is a reliable, cheap, well supported Ada compiler, and in spite of the lack of programmers many projects are able to use Ada appropriately.

BTW, Ada didn't support provability; it encouraged software engineering principles. A later branch of Ada (SPARK Ada) was developed to support provability, and it's finding a surprising amount of use in critical embedded system, enough so that some proposed modifications from it were taken for the Ada 2005 specification. (Interestingly, every SPARK Ada program is a correct Ada program which compiles and executes in precisely the same way on every Ada platform and compiler.)

the "I'm not going to give you a chance to screw up" approach to programming embodied in Ada does not map well to typical [if somewhat shoddy] coding practices and creates a much steeper learning curve for would-be programmers.

Although there's truth in this, it doesn't lead one to C; it leads to Smalltalk, Python, and Lisp.

I do get the impression that you probably don't know Ada, and almost certainly haven't used it. Is this the case?

-Billy

Yes but ...

[avoisin]

You first have to get the Anvil, Catapult, and Boulder modules from ACME corporation

Your money is gone.

[Anonymous Coward]

They both lost. They are trying to solve a problem that doesn't really have any demand for being solved, and trying to do it by scrapping everything we have and starting from scratch. How many people do you really hear complaining that unix isn't gay? VMS is dead for a reason, let it go.

PARENT +1 FUNNY

[Anonymous Coward]

... it is :)

Re: Build a better solution via design

[dumky]

One thing about capability-based secure systems is that they allow for better security solutions to be designed. For example, you could build a a capability that would have read access to all the things you need backed up.

Capability-based security

[dumky]

More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).

Re:forgotten lessons of Ada 83 or too young to kno

[Anonymous Coward]

CP/M never ran on 6502s!

Re:It's a microkernel.

[Horse Rotorvator JAD]

what the hell is the mod down for redundant???

Because slashdot is a clusterfuck of ignorance and stupidity?

Re:forgotten lessons of Ada 83 or too young to kno

[dvdeug]

That version supported provability of correctness,

There's only steps of provability. Ada 83 was more provable than most languages, but there's a lot more to it. And its failure in many cases seems to have been high-price, low-quality compilers designed for sale only to the DoD, which fought Ada internally in a lot of places.

he next version, Ada 95, added features in a vain attempt to achieve OOness

In a vain attempt? Do you care to explain why Ada 95 is not an OO language?

explicitly abandonded provability

Not really. Again, there are steps of provability, and Ada is still easier to prove correct than C. It's also possible to produce an Ada subset (SPARK) that is strongly provable; the company that did that has looked at a C++ subset on the request of customers and dismissed it as impossible.

what got proved was that Ada proved to be a language even its mother didn't love.

There's a lot of people out there that love Ada. Personally I got tired of beating my head against C++. (No, this is not an excuse for a flamewar; it's a personal choice.)

[I mean the BNF has 277 production rules...it is seriously ugly to map to other languages.]

C++ is a complete pain to map to other languages, and nobody seems to care. I don't know where you came up with that number, but I strongly suspect that C++ would be more. In any case, if everyone liked simple syntax, we'd all be using Lisp; most grammar complexities are added on the excuse of making things easier for the programmer at the cost of making it harder for the compiler.

Re:forgotten lessons of Ada 83 or too young to kno

[dvdeug]

the "I'm not going to give you a chance to screw up" approach to programming embodied in Ada does not map well to typical [if somewhat shoddy] coding practices and creates a much steeper learning curve for would-be programmers.

And for that we all pay on a daily basis as boxes get rooted and used as zombies and spam servers. It is so easy to stop buffer overflows, at such a little cost, that it's a crying shame C is still being written for anything that connects to the network. (C++ might be better, if people would give up their arrays and use bounds checked classes instead.)

Access..

[Adam9]

Looks like Microsoft Access SQL statements to me!

Re:forgotten lessons of Ada 83 or too young to kno

[sjlumme]

Well, then DO RTFA. Ada, as well as PL/1, COBOL, Java and similar atrocities, is "specified" by a several hundred page document designed by committee. In its case, a military committee. Its flaws were manifold and pointed out before the spec was even ready (by, among others, Edsger Dijkstra). I would not hesitate for a moment to agree with you that Ada did not fulfill its promise; nor, for that matter, did PL/1, COBOL, or Java. BitC, on the other hand, as far as I can tell, turns out to be a tiny language, with a syntax based on Scheme and a semantics based on ML with a whiff of Pascal for the low-level details. It's description is terse and clear, and it seems to focus on fixing glaring problems with previous languages rather than making the programmer treat their work like a form in triplicate.

Help me understand

[DrYak]

Except the existence of root,
What's the difference between a "capability"-based OS, and a Unix-like os with correct group policies ?

I mean I you want some user to be able to to partitionning on SCSI drivers, juste assign "/dev/sd*" to group "scsi-disk" and make user member of that group.

Even Windows NT family could do this if there wasn't that "user-mode can almost only browse web for near everything else you need to be admin" problem.

This is NOT a troll.
Could someone explain me what's the big deal ?

Re:Help me understand

[slittle]

I mean I you want some user to be able to to partitionning on SCSI drivers, juste assign "/dev/sd*" to group "scsi-disk" and make user member of that group.

Try mount a filesystem, even one where you own the source device and mount point, as a non-root user. Without pre-configuring it in fstab as root, that is.

Re:forgotten lessons of Ada 83 or too young to kno

[Anonymous Coward]

Sorry, but the Ada ISO specification is way shorter than the ISO C++ spec.
So it looks like your little ad hoc theory is completely wrong.

Re:forgotten lessons of Ada 83 or too young to kno

[museumpeace]

Well, you are quite right that the array bounds checking built into Ada would toss an exception anytime somebody tried a buffer overflow attack on an IP stack. I have to explain my rather jaded view of Ada: I am getting paid to translate 10 year old ada code to C++. Its a nightmare. In theory [and all the whitepapers, now yellow with age, on Ada vs C++ assure me] Ada is superior. Wonderful! But the fact that Ada has 2 or 3 ways to enforce things that are damned awkward in C++ is only an obstacle for me. I expect that interchangability between the proposed BitC [which actually strikes me as a pretty good language as far as I have read] and other languages will be similarly broken by the significant differences between what is built in and what must be programmed in to code written in the various languages.
BTW, page 479 of Schildt's 3rd Ed. of C++ the Complete Reference shows how to create a templated class that replaces arrays and overloads the array ref operator, [] for bounds checking. I wish I was working with a clean slate instead of 50k lines of code sans authors
I wish there were as clean a way to emulate bit lenghth wraping and packing in C++...they are primative in Ada so code that uses them has no syntactic handles upon which to work an automated change.

Even FreeBSD has capabilities ....

[konmaskisin]

see /boot/kernel/mac_*.ko for a few ....

Imagine a Beowulf cluster of these...

[Michael Woodhams]

Seriously. The group I work in has a Beowulf cluster. The scheduling is, IMAO, rather a mess. Although there are queues for (e.g.) jobs that use 16 nodes simultaniously, I doubt anything on such a queue would ever get run, because there are never 16 free nodes simultaniously. Short jobs can wait for ages for a node while long jobs run.

All this is hard to avoid with the current architecture. If it were possible to suspend a process, dump it to disk, and later restart on a different node, the scheduling could be much more rational:

* Clear 16 nodes to start a multi-processor job. Put the suspended jobs back in the queue for the next free processors.
* Suspend long-running jobs to give potentially quick jobs waiting on the queue a chance to run.

(Disclaimer: I'm just a user on our Beowulf cluster - I'm not too familiar with the current capabilities. Perhaps they are more advanced than I think.)

DarkTempes, meet the Period

[Anonymous Coward]

He's a neat little dot. Basically, when you're done making a statement, you put him at the end. By doing this, readers can clearly tell where one statement ends and another one is about to begin! It's really great. Without him, written words can get confusing and all jumbled. Like your post!

Re:DarkTempes, meet the Period

[Llama_STi]

nice.

Obligatory links.

mmm

[Anonymous Coward]

The web page is a joke

Re:forgotten lessons of Ada 83 or too young to kno

[kbielefe]

As a software engineer who uses C and Ada approximately equally, I'm afraid I'm going to have to disagree on which language encumbers the programmer more.

C programmers constantly have to be aware of array indices going out of bounds, pointers being valid, making sure values are constrained appropriately (like keeping a day of the month being between 1 and 31), accidentally assigning two incompatible variables to each other, and a host of other potential problems. When a mistake is made in any of these areas, the effects of the bug are often far removed from the source.

Ada, on the other hand, is more of a set-and-forget language. Yes, it might take one or two extra lines of code to declare a variable, but it pays off by making the body of the function much more consise, easier to write, easier to maintain, and less likely to contain bugs.

Consider aircraft software that must deal with altitudes in feet and meters as an example. An Ada compiler will instantly catch most unit confusion errors that a C programmer may spend hours tracking down or even worse, never find.

The irony is that Ada is a great language for sloppy programmers because it catches so many careless mistakes, and those are the very people who shun it.

Persistance = EROS shortcoming?

[Alwin Henseler]

While that was nice, my favorite feature of EROS (besides the name) was the idea that instead of a filesystem a disk was simply non-volitile memory cache. That facilitated my next favorite idea, orthogonal persistance, the somewhat like a persistant software suspend. I'd be interested in finding out (while the home page does not say) if these were the shortcomings of EROS it was alluding to.

Probably: yes. My feeling is that orthogonal persistance and extreme reliability (2 goals of the EROS project) are conflicting goals.

Orthogonal persistance is very useful from a user point of view: you don't need to 'save' files, you don't need to 'close' apps, so noobs can't forget it. Application programmers don't need to worry about closing files, there's just a state of the app that's saved in regular intervals, transparently done by the OS.

But the other goal, extreme reliability, requires something else: extreme simplicity of some aspects/components of the OS. If you introduce too much complexity, the extreme reliability goes out the door.

My guess is that EROS has shown that you can't have both as a core feature, and that you are forced to choose: drop the extreme reliability, or move the persistance feature out of the core into another layer (like do it an application level). It seems that developers have chosen the latter, to preserve reliability as a core feature. IMO a good choice: persistance may be a nice thing to have, but no good to use it everywhere. The project history explains this some more.

Security focused? Have you seen the source code?

[Anonymous Coward]

An easy example:

char *strcpy(char *to, const char *from)
{
char *start = to;
while (*from)
*to++ = *from++;
return start;
}

Hint: what if 'to' is greater than 'from'?
If they're pushing a security focused OS, why the hell are they writing it in C in the first place? Given that they are writing it in C, they aren't exactly going out of their way to avoid pointer problems, are they?

Re:forgotten lessons of Ada 83 or too young to kno

[dvdeug]

But the fact that Ada has 2 or 3 ways to enforce things that are damned awkward in C++ is only an obstacle for me. [...] I wish there were as clean a way to emulate bit lenghth wraping and packing in C++...they are primative in Ada so code that uses them has no syntactic handles upon which to work an automated change.

So Ada is bad because it does something's better than C++? If it's easy in Ada and hard in C++, shouldn't that make Ada the better language?

Capabilities — not POSIX “capabilities&#

[Pan T. Hose]

a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root.

This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS?

Linux? Kids these days... Capabilities is a feature from the 1970s. If Coyotos is anything like EROS or KeyKOS, then they don't mean POSIX "capabilities" but real capabilities as described in 1975 by Jerome Saltzer and Michael Schroeder in the famous The Protection of Information in Computer Systems paper: "Capability--In a computer system, an unforgeable ticket, which when presented can be taken as incontestable proof that the presenter is authorized to have access to the object named in the ticket." For an excellent introduction to capabilities, read What is a Capability, Anyway? by Jonathan Shapiro. Then read the Capability Theory by Sound Bytes essays by Norman Hardy for more informations. Those papers are classics, just like Reflections on Trusting Trust by Ken Thompson. It's a must-read for anyone who wants to have even the slightest idea about computer security at all.

Not true

[Anonymous Coward]

With the right number of bits, you can set it up so that someone would have to convert all the mass of the Earth into computer chips and use it to crunch numbers for a billion years to decode it. No amount of money can accomplish that; it's outside of the realm possibility now, and will be for a long long time. The number of bits needed to achieve this is low and in routine use; it's something like a 256 bit key. Google around for it.

Only if the file owner wants to use it

[billstewart]

If the data owner encrypts something using a key that only he knows and a decently strong encryption system, you're out of luck if he doesn't give you the key. There are crypto systems that do things like secret sharing (N people have a partial key, and at least K of them have to get together to get the real key), or the data owner could give the semi-trusted person N bits of a key and brute-force gets the rest, but if the data owner doesn't do that, you're out of luck.

Even if some administrator has "dredge through the raw disk" permissions, that doesn't mean you need One Big Omnipotent Superuser that has *all* the special permissions. Controlling printer hardware or network routing protocols or delivering email don't all need to be done by the same process or the same person, and it's much safer to keep those powers separate (even if the same Actual Human ends up owning all those capabilities.)

Mod Parent Up - Actually Understands Capas

[billstewart]

That's the first comment I've read here that actually has some understanding of capability-based OS's...

Capabilities are Radically Different

[billstewart]

Capability-based Operating Systems are a radically different model for security and operations than anything Linux+SELinux does, or anything System V/MLS or the other multi-level-secure OS's did, though they've got their good points also. It's a bottom-up security design, and you really can't do anything to an object unless the owner of that object gives you a capability that lets you, as opposed to having some mediation system that stops you from doing things you're not supposed to. In capability-based systems, if you don't have permissions to manipulate an object, you can't see it at all.

KeyKOS was usable, within a limited application space that made sense 20+ years ago. EROS was pretty rough, and how much work it got depended a lot on what Jon was up to any given year (and his students, after he was teaching), but adapting to all the modern things like TCP/IP and X and Email and such took work - maybe they'll finish this time :-) Some of the people involved (I think it was an incarnation of KeyKOS, with Bill and Norm) were once at a trade show where the people next to them were advertising the reliability of their system, and got very annoyed by a few cycles of "Here's KeyKOS running, let's start some complex application running, let's pull the power cord out of the wall, see the blinkenlights go dark, plug it in, blinkenlights start up again, application's running just fine except the clock ticked a couple of times, think the machine in the next booth could do that?" That's the reliability-and-persistence aspect of the system rather than the security aspect of it, but they're related, and it's more than just tacking on a journaling file system.

On the other hand, security-oriented systems spend a lot of time either saying "No", or at least not saying "Yes", that getting stuff done isn't always easy, and for a lot of people, Knoppix and a UPS can provide enough security and reliability.

C++ is just as dangerous as C

[billstewart]

I really like C - it's simple, powerful, obvious, does what you think it does, doesn't lie to you about what it's doing, and if you want to shoot yourself in the foot, the hole goes right smack through your third metatarsal bone. It was a great language for many things, but almost nobody should be using it for almost anything any more, and almost nobody should allow anybody else's C programs onto their system.

With C, it's perfectly easy to write safe, reliable, trustable programs - but the language doesn't force you to do so. C++ gives you a bunch of tools that are safer than doing some of the same things by hand, but it also doesn't force you to use them, and you can usually take your old dangerous C programs and force the C++ compiler to accept them (though some dangerous activities might need to be wedged pretty hard to get them to work :-) C++ has the advantage that some of the basic I/O libraries don't have some of the glaring holes that C's stdio.o does, but you can still *use* stdio if you want. You don't *have* to do dangerous and stupid things in C++, but you didn't have to do them in C either. It's still possible to drill a nice neat hole in your third metatarsal, but in C++ you're as likely to take out the second and fourth while you're at it, or maybe just nail a couple of toes.

I never did any real work in Ada, but I read a lot about it back in the day. It pretty much forced you to do a lot of your design work upfront before getting down to coding, which was often a Good Thing on larger projects, and meant that more of your bugs got dealt with at the design stage than at the coding stage.

Capability-based OS != Unix policies

[billstewart]

Check out the papers on eros-os.org, or look at the docs on coyotos, or look up KeyKOS. http://coyotos.org/docs/osverify-2004/osverify-200 4.pdf.
This is using the term "capability" in an entirely different manner than the Unix-policy folks use it. A "Capability" in this context is approximately an object-method handle - everything interesting in the system is an object, and to invoke any method on an object, you need to know the capa that invokes the method, and you can only know that if something that already knows that capa decides to tell you. A capa is represented as a long enough string of bits (e.g. 64 or 128) that you won't guess it. The granularity of a capa is often as fine as "a block of disk" or "a page of RAM". Objects that you don't know capas for are invisible - rather than the OS deciding whether to permit or refuse you access to it (which you may be able to spoof), if you don't know any capas for an object, you don't have a way to ask for access to it. Just because something's extremely secure doesn't mean it's easy to use.... and the underlying models are sufficiently different from Unix that you can't usually just port your code and make a few tweaks.

Since it's object-based, the natural storage model is persistent objects, and EROS and its relatives spend a lot of time making sure they stay persistent, e.g. syncing them to disk when needed - they tend to not mind if you do things like unplugging the power cord while processes are running, and start right where they left off when you plug them back in. On the other hand, the storage models aren't what you're used to unless somebody's written an emulation layer on top of it, and the emulations may also be different than what you're expecting.

Re:Need for a superuser? CLIPPER CHIP

[Anonymous Coward]

Hmmm, in this day of Homeland Security, just design the CPU board with the CLIPPER CHIP and give the keys to the FBI to hold onto til they day you have a need for them! :)

Re:forgotten lessons of Ada 83 or too young to kno

[museumpeace]

Don't get me wrong; Ada is technically a better language. And what, other than technology especially concerning reliability, criteria should be used to measure a language? You measure it against the needs of your job and the costs you can bear. My employer's job is to find people who can maintain Ada code...they failed in that. So my job is to translate Ada code to C++ and as I've tried to explain, that is hard...Its an "interesting" problem but its using me up and teaching me nothing that will make me more employable in a year or two

Re:forgotten lessons of Ada 83 or too young to kno

[Jonathan S. Shapiro]

In fact, Jonathan was at Bell Labs when the first validated implementation of Ada83 was completed by a guy down the hall: Charlie Weatherall.

Re:forgotten lessons of Ada 83 or too young to kno

[Jonathan S. Shapiro]

While I don't entirely agree, there is a real and valid point to consider here, but let's look at it more closely:

• Writing a program in BitC doesn't mean you have to verify it, only that perhaps you can. BitC has merit over existing systems programming languages purely on grounds of expressiveness and safety.
• Ada83 was both excessively restrictive and provided insufficiently expressive abstraction capability to be useful. It was a 1960's language (okay, perhaps 1970's) language standardized when better languages were coming into play.

That being said, it also needs to be said that there is a small body of programs whose correctness is critical: operating systems, power substation control systems, flight control systems, medical systems, and so forth. It simply isn't a goal (for us) to take over the entire systems programming world with this language. It's our goal to be able to do a smaller set of critical things well enough that I'ld be willing to run the resulting code on my (personal) pacemaker when the time comes to need one.

shap

This is the way

[starseeker]

If I understand what they are doing correctly, this is the path that must be taken if we are to have a truly robust computing world.

Human beings make mistakes, which are iteratively corrected. This is OK, but it turns out when it comes to computers a DEVELOPER correction does not translate into a USER correction 100% of the time. People do not update systems. And systems are so complex nowadays that often times fixing one problem will break other software, mission critical software. This is unacceptable, but it is a fact of life. So if we want a clean, non-virus ridden network that is also worldwide, we have to Get It Right The First Time.

Coyotos is a possible solution to the statement "if we built houses the way we build computers/networks/OSs/software, the first woodpecker would destroy civilization." From the ground up, if we do it RIGHT with the best tools we can bring to bear (i.e. formal proof) we can stop worrying so much about woodpeckers.

There is no such thing as 100%, of course. Proofs are checked either by computers programmed by humans, or by humans. Both are fallible. But this is as close as we are going to get to a perfect system, and with any luck it will raise the barrior of entry for black hats so high they won't even bother.

It's a lot of work to create, and far more work to re-educate all the programmers out there. But there is NO easy solution. The thinking represented by Coyotos, in my opinion, represents the only POSSIBLE solution. So let's hope in 20 years universities are teaching BitC as the default language. Computer programmers and developers have been solving the same basic problems over and over and over for the past few decades. Thanks to open source, a new philosophy can and needs to emerge - express the logic of your feature to the computer once, completely, and be done forever. Then we can build to greater things.

BitC: A Lisp-like language

[RevAaron]

I gotta say it- I'm surprised as hell no one is complaining about BitC, the Lisp-like language behind Coyotos. Don't get me wrong, I love Lisp, whether it's CL, ISLISP (kind of my favorite), Scheme or something else... But it seems to me, basing a project in some Lisp-like language is a recipe for an early death. The current FOSS community is pretty harsh towards languages outside of the accepted mainstream as far as how much support it gets. It seems that the language choice of E, something based on Java, would have had a much better chance to draw users.

Not that I'm into selecting a language for those reasons... My projects are almost all in Squeak Smalltalk and will continue to be so until Slate or something better than Squeak comes along. ;)

Re:forgotten lessons of Ada 83 or too young to kno

[museumpeace]

Thanks. Informed perspective is what I always HOPE for in /. comments and once in a while I get it! I shouldn't complain about my job, but as a tax payer, I am aghast at what I am paid to rescue 10 year old algorithm's from death by insupportability. I would LOVE to be translating the crypt full of Ada to some language that was not downright hostile to non-zero-based and range checked array indices [to mention one of several headaches they pay me to endure]. I am tempted to mention BitC to the Lab supervisor but they weren't the ones who chose to abandon Ada...the customer is always "right" about C++ :-(
Personally, I jumped from C to Java and then got dragged back into C++ and lately have had to learn Ada PDQ...the weakness of my opinions about Ada has no end of great exuses. [Actually, I wish the world had stopped changing after we got DEC to ordain BLISS for systems programming but try and tell 10000 cowboy engineers what language they ought to use!]
If anything, the years since the rise and fall of Ada have led to an attenuation of the extent to which humans can intervene ( man-in-the-loop style or as human-monitored autonomous systems) in the operation of critical software. Consider for instance how much of our defense relies on space born platforms...if you have a bug or a lack of stability up there, you pray for a work-around. More than ever, we need tools that, at the very least, don't get in the way of making reliable systems.

Re:Well, Duh...

[GooberToo]

Actually, that's not true. The same problem comes up with key management. You can always have a system whereby, one person does not have permission to create an account to every other system. By allowing other accounts (which the admin can not create) to counter-sign, thus giving permission to the counter-sgned elements of the system, completely removes the concept of one account is god.

Of course, this is still not perfect and greatly increases complexity, but systems which address the chicken and the egg problem are very obtainable.

Of course, you'll come back and say, well the admin will just create more counter-signing accounts and then do his won counter signing....but for those new counter signing accounts to work, would have to be counter signed by the actual counter-signers to achieve that level of access, in the first place.

Basically, this means that you would have to have a fixed number of base counter signing accounts, which get greated and setup, during initial system setup. Like I said, this is easily obtainable....just more complex...and requires administration, ideally, by three or more admins; whereby, the more admins you have, the harder it is to cheat the system.