derek@sask.UUCP (Derek Andrew) (11/30/84)
I have just returned from a security seminar. The speaker made some
comments about Unix and security. It seems that the last two issues
of Unix Review carried some comments from someone at Purdue. Purdue
had been working on a secure kernel implementation of Unix. A spokes-
person had stated that: using an ordinary guest account, a member of
their team could obtain superuser status within 5 minutes. On their
secure system, it would take at least 40 minutes.
This comment bothers me a little. I would really like to speak with
someone at Purdue about this. Would some kind soul that receives
Unix Review kindly send me the name of the person at Purdue that made
that statement? Of course, I won't post the results of my conversation
if it is indeed true until we move to VMS :-).
Another comment made by the speaker was that there have been 5 attempts
at generating secure Unix kernels. All attempts have not been successful
and 4 have been aborted. If anyone knows about any of these attempts,
please send me the details. I will post a summary.
So what kind of flaw exist in Unix? I am not talking about things
that can be done on other operating systems, like stealing backup
tapes, mounting Unix disks on systems which you know the root password,
running a program to simulate the login procedure or using micros
for an exhaustive search for the root password.
Are there any flaws which have no way to be plugged?
Maybe this is not the place to discuss such security issues, but as
the speaker said, "having no security on a system is better than
thinking that your system is secure".
--
Derek Andrew, ACS, U of Saskatchewan, Saskatoon Saskatchewan, Canada, S7N 0W0
{ihnp4 | utah-cs | utcsrgv | alberta}!sask!derek 306-966-4820 0900-1630 CST
"I ain't afraid o' no bugs." - Bugbustershenry@utzoo.UUCP (Henry Spencer) (12/02/84)
> Another comment made by the speaker was that there have been 5 attempts > at generating secure Unix kernels. All attempts have not been successful > and 4 have been aborted. ... This simply reflects Unix's status as the preferred operating system to try to re-implement, if you are trying to re-implement something. *Most* (all?) secure-kernel projects have been failures. Many of them have been based on Unix. So it's hardly suprising that the number sounds impressive. Yes, there are security holes in Unix, as distributed. By and large, they are curable once you know they are there. It helps if the underlying system is reasonably stable, so you get a chance to find and fix the bugs; security bugs in 4.2BSD are hardly suprising, since so much of the kernel was not thoroughly tested at release time. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
eric@milo.UUCP (Eric Bergan) (12/04/84)
It is true that there have been several attempts to develop "secure" Unix kernel, with varying degrees of success. This is not an indictment of Unix - rather it is praise for it. The reason is that there have only been a couple of other attempts at "secure" operating systems, which have also ended in failure. The fact that several attempts have been based on Unix means that the people involved thought they had a fighting chance starting from Unix. By "secure", I mean something that can run multi-level security in a provably correct way. Can you imagine trying to formally prove VM secure? It boggles the mind. -- eric ...!seismo!umcp-cs!aplvax!milo!eric
ron@brl-tgr.ARPA (Ron Natalie <ron>) (12/07/84)
> > By "secure", I mean something that can run multi-level security in > a provably correct way. Can you imagine trying to formally prove VM secure? > It boggles the mind. > Actually, VM would be alot easier to do than UNIX would.
bet@ecsvax.UUCP (12/08/84)
Wait, wait, wait, formally 'prove" VM secure? Gaaak. Not physically
possible -- it runs on an IBM S-370, and emulates complete S-370's for
each user -- including permitting users to run code in supervisor state,
which lets them run channel control programs, which can do
mindbogglingly complex things... VM, last I heard, attempts to look at a
channel control program to figure out what it might do before it runs
it, though I heard there were bugs in the attempt to sniff them out when
the channel control programs were self-modifying. I saw an article about
a year and a half or two years ago, which concluded basically that VM is
pretty secure these days since anybody bright enough to decrypt the IBM
documentation will be having more fun and making more money playing with
UNIX -- security through obfuscation.
Bennett Todd
...{decvax,ihnp4,akgua}!mcnc!ecsvax!bethenry@utzoo.UUCP (Henry Spencer) (12/09/84)
> Actually, VM would be alot easier to do than UNIX would.
The problem is not proving "bare" VM secure -- virtual machines are a
good way to tackle security, since they provide such airtight isolation --
but proving the security of a useful application environment, in which
controlled sharing is necessary. At this point, it stops looking easy.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrymjl@ritcv.UUCP (Mike Lutz) (12/10/84)
Good Lord! I never thought I'd ever be in a position where I'd support (even indirectly) anything Big Blue does, but here goes: > ecsvax!bet (Bennett Todd): > Wait, wait, wait, formally 'prove" VM secure? Gaaak. Not physically > possible -- it runs on an IBM S-370, and emulates complete S-370's for > each user -- including permitting users to run code in supervisor state, > which lets them run channel control programs, which can do > mindbogglingly complex things... So? The key word is *emulate*. None of the virtual machines actually *runs* in supervisor mode; only VM does. Since VM need only be an operating systems operating system, it need only provide barebones services to it's clients. In theory, then, VM should be much smaller and less complex than any of the general purpose systems it monitors, and the as a general rule, less complexity makes it easier to prove security. Note that MVS, CMS, and the other IBM monstrosities can be full of holes; as long as VM puts clients on distinct virtual machines, and controls the interactions among these machines, the system as a whole can be secure. >VM, last I heard, attempts to look at a >channel control program to figure out what it might do before it runs >it, though I heard there were bugs in the attempt to sniff them out when >the channel control programs were self-modifying. You betcha -- this is a big hole, but is less a problem in VM than in IBM's I/O subsystem design. This hole can be plugged, however, and IBM is already making moves in that direction. For instance, big hunks of VM have been migrated into the CPU microcode (VM ASSIST); the same technique could be used in channel microcode to "virtualize" all channel programs. For all I know, something like this might already be in place. -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {allegra,seismo}!rochester!ritcv!mjl CSNET: mjl%rit@csnet-relay.ARPA
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/11/84)
> kindly send me the name of the person at Purdue that made that statement? George Goble > So what kind of flaw exist in Unix? Same as in any substantial time-sharing system, plus its own brand due to loopholes in the kernel implementation (every OS I have ever seen has had these). Most of the ones you hear rumors about in the media are well known to UNIX old-timers and have been fixed long ago in their systems. Many of these fixes eventually make it back into some UNIX "product". See the latest BLTJ article by Morris et al. for several general methods. > Maybe this is not the place to discuss such security issues Probably not net.rumor, but in general you are better off hearing about them along with everybody else than being ignorant while some antisocial nerd breaks in and ruins your corporate files, or worse.
sigma@usl.UUCP (Spyridon Triantafyllopoulos) (01/09/85)
gee, you are saying that there have been a couple of attempts
to make a secure O.S (in general i assume) and failed
Have you logged in on the most secure operating system??
Have you logged in on a Multics lately????
Well, after using Multics for 3 years (full size, release 10.2 and going)
you GOT to use it to believe it. Very neat and very secure. now if
these wiz kids set up their apples to find the password....
anyway. I have used them all. Multics is THE BEST. (but, as
described by our local DBMS prof, Multics is Overhead City).
There is a price for everything.
-- Spiros
Spiros Triantafyllopoulos <> USENET {ut-sally, akgua}!usl!sigma
Computer Science Dept, USL <> CSNet TriantafyllopoulosS%usl@csnet-relay.ARPA
"This file contains no opinions whatsoever"