×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Coyotos, A New Security-focused OS & Language

Hemos posted more than 9 years ago | from the locking-things-down dept.

Operating Systems 296

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

296 comments

I, for one (-1, Troll)

Anonymous Coward | more than 9 years ago | (#11470297)

welcome our new coyote overlords.
Will it be like planet of the apes?

heh (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11470304)

niggers.

It's a microkernel. (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11470318)

Microkernels SUCK!

Re:It's a microkernel. (1, Redundant)

j1bb3rj4bb3r (808677) | more than 9 years ago | (#11470342)

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

Re:It's a microkernel. (0, Flamebait)

alnjmshntr (625401) | more than 9 years ago | (#11470459)

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

Re:It's a microkernel. (0)

Anonymous Coward | more than 9 years ago | (#11470737)

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.

Need for a superuser? (3, Interesting)

PornMaster (749461) | more than 9 years ago | (#11470334)

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? (3, Funny)

Andreas(R) (448328) | more than 9 years ago | (#11470389)

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? (1)

Sexy Commando (612371) | more than 9 years ago | (#11470396)

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? (0)

Anonymous Coward | more than 9 years ago | (#11470681)

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?

That's not the right question (5, Insightful)

Anonymous Coward | more than 9 years ago | (#11470398)

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.

with a Linux emulator (0)

Anonymous Coward | more than 9 years ago | (#11470692)

must port linux emulator to windows....

Re:Need for a superuser? (5, Interesting)

Coryoth (254751) | more than 9 years ago | (#11470450)

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? (3, Interesting)

GeckoX (259575) | more than 9 years ago | (#11470601)

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? (2, Insightful)

OwnedByTwoCats (124103) | more than 9 years ago | (#11470708)

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? (0)

mr.newt (244023) | more than 9 years ago | (#11470905)

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? (1)

lems1 (163074) | more than 9 years ago | (#11470960)

... 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? (1)

Qzukk (229616) | more than 9 years ago | (#11470756)

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? (1)

kaisyain (15013) | more than 9 years ago | (#11470472)

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? (1)

tepples (727027) | more than 9 years ago | (#11470533)

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.

But you need r00t to change the iptables. (1)

aristus (779174) | more than 9 years ago | (#11470780)

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:Need for a superuser? (2, Insightful)

Sheetrock (152993) | more than 9 years ago | (#11470602)

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.

So many good ideas never make it... (0, Flamebait)

EmbeddedJanitor (597831) | more than 9 years ago | (#11470606)

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... (1)

suso (153703) | more than 9 years ago | (#11470944)

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:Need for a superuser? (1)

dfj225 (587560) | more than 9 years ago | (#11470613)

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.

Comparison with Multics? (5, Insightful)

CodeArt (540731) | more than 9 years ago | (#11470345)

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? (1)

dokebi (624663) | more than 9 years ago | (#11470733)

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

No that is an insightful question (2, Informative)

ChiralSoftware (743411) | more than 9 years ago | (#11470869)

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:Comparison with Multics? (1)

Valar (167606) | more than 9 years ago | (#11470852)

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? (4, Interesting)

Elwood P Dowd (16933) | more than 9 years ago | (#11471009)

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.

coyotos site (0, Redundant)

bladx (816461) | more than 9 years ago | (#11470350)

love their site design ;)

Perhaps that's how their security works (1)

freejamesbrown (566022) | more than 9 years ago | (#11470614)

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.

Looks exciting (2, Insightful)

RatRagout (756522) | more than 9 years ago | (#11470356)

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

It has no writeable drives or network access (1)

freejamesbrown (566022) | more than 9 years ago | (#11470688)

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

m.

Is it just me? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11470364)

Or is this pronounced coitus?

BitC looks nasty (2, Insightful)

Panaflex (13191) | more than 9 years ago | (#11470371)

((At least (to me).))

(pan)

Re:BitC looks nasty (2, Funny)

Tumbleweed (3706) | more than 9 years ago | (#11470427)

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

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

Re:BitC looks nasty (0)

Anonymous Coward | more than 9 years ago | (#11470455)

It looks a lot like lisp to me.

Son of a... (5, Funny)

tepples (727027) | more than 9 years ago | (#11470484)

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... (0)

Anonymous Coward | more than 9 years ago | (#11470695)

You forgot to include .NET!

Re:Son of a... (3, Funny)

Kyont (145761) | more than 9 years ago | (#11470940)

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

Re:BitC looks nasty (2, Informative)

Lorens (597774) | more than 9 years ago | (#11470724)

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 (2, Insightful)

Dasein (6110) | more than 9 years ago | (#11470931)

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.

When in doubt, remember: (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11470400)

"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

Capabilities (4, Interesting)

Tet (2721) | more than 9 years ago | (#11470442)

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 (2, Insightful)

Greyfox (87712) | more than 9 years ago | (#11470635)

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 (1)

superpulpsicle (533373) | more than 9 years ago | (#11470718)

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 (2, Insightful)

plcurechax (247883) | more than 9 years ago | (#11470777)

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 (0)

Anonymous Coward | more than 9 years ago | (#11470779)

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 (1)

Lorens (597774) | more than 9 years ago | (#11470832)


* 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 (1)

lems1 (163074) | more than 9 years ago | (#11471003)

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

Wrong (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11470481)

There are many examples of Unix systems with mandatory access controls, and role based capabilities. For Linux, you have GRsecurity, [grsecurity.net] SELinux, [nsa.gov] and RSBAC. [rsbac.org]

There are others too.

Licencing. (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11470485)

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. (2, Informative)

Lorens (597774) | more than 9 years ago | (#11470751)

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

security (0)

dioscaido (541037) | more than 9 years ago | (#11470496)

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.

The same old saw (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11470552)

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 (0)

Anonymous Coward | more than 9 years ago | (#11470794)

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.

Re:security (2, Insightful)

kahei (466208) | more than 9 years ago | (#11470836)


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.

License? (1)

tdvaughan (582870) | more than 9 years ago | (#11470526)

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.

A good start (1)

LordNite (65590) | more than 9 years ago | (#11470564)

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.

RTFA dude (0)

Anonymous Coward | more than 9 years ago | (#11470642)

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!

forgotten lessons of Ada 83 or too young to know? (3, Insightful)

museumpeace (735109) | more than 9 years ago | (#11470604)

"...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.

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

plcurechax (247883) | more than 9 years ago | (#11470723)

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:forgotten lessons of Ada 83 or too young to kno (1)

museumpeace (735109) | more than 9 years ago | (#11470772)

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.]

Re:forgotten lessons of Ada 83 or too young to kno (2, Informative)

Dasein (6110) | more than 9 years ago | (#11470993)

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.

co3k (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11470675)

this exploitation, riv4lry, and we'll

Need for a webmaster? (1)

JoloK (728770) | more than 9 years ago | (#11470696)

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

No software so secure (1)

hey (83763) | more than 9 years ago | (#11470707)

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.

rigorous = unpopular (2, Funny)

PMuse (320639) | more than 9 years ago | (#11470773)

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.

What about a tripwire? (1)

mac-diddy (569281) | more than 9 years ago | (#11470785)

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

OT. Sorry, tried to start my own EROS project (0)

Anonymous Coward | more than 9 years ago | (#11470790)

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

Sorry, I tried to start my own EROS project.

Another one for the hosts file... Vibrant Media (1)

gluino (233242) | more than 9 years ago | (#11470809)

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 (2, Insightful)

Doc Ruby (173196) | more than 9 years ago | (#11470820)

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.

Doesn't really matter does it (1, Insightful)

bigberk (547360) | more than 9 years ago | (#11470834)

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.

Hmmm... (4, Interesting)

noblesse oblige (840634) | more than 9 years ago | (#11470843)

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.

Eros? (0)

Anonymous Coward | more than 9 years ago | (#11470911)

Why not just call it pr0n OS?

Interesting for inspiration only (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11470970)

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.

Frost pisT? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#11470973)

your replies rather on baby...Don't bombshell hit fastest-growing GAY

security sells pile of shit (0)

Anonymous Coward | more than 9 years ago | (#11470982)

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...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...