Re: linux security Michael R. Casaretto (mcasaret@gte.net)
Sun, 12 Apr 1998 00:21:48 -0700

I am still interested in beta testing the EROS Operating System. Please get back to me about this. I am very interested in operating systems and security. I hope that you will allow me to help in this.

Michael R. Casaretto
mcasaret@gte.net

P.S. Please respond to this ASAP
-----Original Message-----
From: Jonathan S. Shapiro <jsshapiro@earthlink.net> To: cap-talk@eros.cis.upenn.edu <cap-talk@eros.cis.upenn.edu>; eros-port@eros.cis.upenn.edu <eros-port@eros.cis.upenn.edu> Date: Thursday, April 09, 1998 1:56 PM
Subject: linux security

>This is a bit off topic, but I want to address it anyway. It is
>partially an account for why capability systems remain important.
>
>[Ian (I think) wrote:]
>> >> > There aren't that many security oriented OSs around

>> >> > The only ones I can think of are NT, OS/2 (Pretty bad
>> >> > security actually), Unix / Linux, and BeOS.
>
>[I replied]
>
>> >I think that any examination of the systems Ian lists on the
>> >merits will demonstrate that they are not even a reasonable
>> >beginning at seriously secure systems.
>
>[Ian responded:]
>> A well set-up version of Unix is virtually untouchable. Unix is
>> also very mature, and its security has been tested over a long
>> time.
>
>I think what we have here is a difference of opinion about what
>"security" means.
>
>It's fairly easy to build a system that cannot be cracked from the
>outside. Pulling the network cable is a good start. Pulling the plug
>and locking the door helps too. Both solutions are universal :-)
>
>The security architectures of UNIX/Linux, OS/2, NT, and BeOS were
>relatively late concerns in the architectures of the respective
>systems. There is 30 years of empirical experience out there that
>says afterthought security doesn't work.
>
>To set the ad hominem arguments aside, though, let me try to explain:
>
>When I say that none of the previously mentioned systems are really
>designed to be secure, I mean in part that their attention to security
>pretty much stops at the box boundary -- you are either in or out.
>Once in, the internal boundaries are fairly minimal.
>
>External (i.e. black box) security, in the end, is controlled by
>authentication and communication protocols that are dictated by
>external standards. In many cases these standards are not especially
>secure.
>
>ALL of the systems named are vulnerable to external denial of service
>attacks, and to a great many security attacks. One critical
>demonstrator of this is that there exists no means to argue
>successfully that all security holes have been closed, or even that
>all security exposures have been limited to any single piece of code.
>This is why, in spite of the long history of testing, security
>problems are still being found 19+ years into the life of the UNIX
>design.
>
>This is an area where capability systems are strong.
>
>EROS is primarily concerned with security *within* the box boundary.
>More generally, it is concerned with the propagation of information,
>including both data and faults. I want to know that a subcomponent of
>an application is not in a position to broadcast my data to the net.
>I also want to know that when that subcomponent takes a dive it will
>not take out the whole application. Finally, I want to know that all
>of my carefully constructed security boundaries will be recovered
>after a system crash.
>
>This is something that capability systems are potentially good at,
>which UNIX provably cannot handle for reasons having to do with the
>potential flow of information in the system. If you want to take up
>that last gauntlet, please first read the paper that Sam Weber and I
>have done, where we showed how it can be formally proven:
>
> http://www.cis.upenn.edu/~shap/EROS/popl98.300dpi.ps
>
>[I may have got that URL wrong -- you can find it off the
>'publications' link on my home page].
>
>The short explanation is that there is no way to prevent two UNIX
>processes from communicating, because they share access to a mutable
>resource -- the file system.
>
>
>
>shap
>