goldfarb@ucf-cs.UUCP (10/22/83)
A non-Usenet associate wants to purchase a package that tests a Unix port
for completeness of implementation and does some benchmarking as well.
He has heard of one such system called `AIM', but he has no detailed
information about it. I'd appreciate getting information on it and
any other Unix validation/benchmark packages in existence.
Ben Goldfarb
University of Central Florida
uucp: {decvax,duke}!ucf-cs!goldfarb
ARPA: goldfarb.ucf-cs@Rand-Relayderek@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
emks@uokvax.UUCP (12/02/84)
/***** uokvax:net.unix-wizar / sask!derek / 7:47 pm Nov 30, 1984 */ Are there any flaws which have no way to be plugged? /* ---------- */ Well, I don't know about "no way" to be plugged, but certainly the human factor is one of the most notorious ways in which security is breached. (I.e. Users telling other users about their passwords, overhearing the super-user account password, or disgruntled employees who have special access). kurt
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
rsk@stat-l (Rich Kulawiec) (12/05/84)
/***** uokvax:net.unix-wizar / sask!derek / 7:47 pm Nov 30, 1984 */
Are there any flaws which have no way to be plugged?
/* ---------- */
I believe the original paper on Unix security by Thompson et. al.
points out that the very existence of the superuser represents a flaw in
Unix security. As a side note for those looking for references, Berkeley
did some work on something called "data-secure Unix" a while back;
I think I saw the writeup in the ACM journal on operating systems.
--
Rich Kulawiec @ Purdue University Computing Center
{ decvax, ihnp4, uiucdcs } !pur-ee!rsk & { decwrl, hplabs, ucbvax } !purdue!rskbet@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!henryron@BRL-TGR.ARPA (12/09/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.
mjl@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
boyle@brl-tgr.ARPA (12/10/84)
Derek Andrew at U of Saskatchewan says:
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.
The second sentence means "there exists an attempt that has not been
successful". Does that mean that some attempts were successful? Or
did he mean to say "No attempt has been successful"?
Jim Boylegwyn@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.
smk@axiom.UUCP (12/19/84)
KVM was an attempt at a secure kernel implementation of VM. It got
farther than most secure OS projects.
You can't formally prove any complex system. There is too much handwaving
in showing the formal specs/model really meet your requirements and the
design meets the specs. With that much handwaving, you can have the perfect
spec and a design that implements something completely different. Nothing
short of formal ties between the stages will satisfy me (not to mention the
proofs of correctness for the compiler/assembler/translator, the machine
instruction set itself -- as anyone working on a braindamaged micro can attest
to).
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)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" Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> (01/11/85)
Multics may be the most secure O.S. in general use but it HAS been broken into. Details not available from this source. The reason Multics might be more secure is that is has help from special-purpose hardware. It would not be feasible to port Multics to a VAX, for instance.
larry@anasazi.UUCP (Larry Rodis) (01/15/85)
> Multics may be the most secure O.S. in general use but it HAS > been broken into. Details not available from this source. > > The reason Multics might be more secure is that is has help > from special-purpose hardware. It would not be feasible to > port Multics to a VAX, for instance. Since Mutlics was broken into by an Air Force Tiger Team in the early 70's and their methods of breakins fixed via Project Guardian Multics has not been broken into unless the Person breaking in had a users login name and password. Also while on the subject Honeywell is having a new computer certified by the NSA for security class A2. This computer is unix call compatible and is called SCOMP's look for it when it receives final security classification. Larry Rodis uucp: !decvax!noao!terak!anasazi!larry !ucbvax!asuvax!anasazi!larry
jbn@wdl1.UUCP (01/16/85)
One of the attempts to implement a secure kernel for UNIX was the
Kernalized Secure Operating System developed at Ford Aerospace from 1978
to 1980. This was to be a very tight system; the entire system was designed
and specified in a formal specification language (SPECIAL) and attempts
were made to prove that the system interface did not contain any design
errors that could be exploited; the proof attempt was subcontracted to
SRI International and used a program which took in the interface
specification, applied the Bell-LaPadua security model, and generated
theorems to be proved with the Boyer-Moore theorem prover. This was
interesting but not too useful in practice.
The security model was DoD-oriented; the system had classification
levels for files, and stringent rules about access. For example, programs
were not only forbidden to read data at a higher security level than the
one they were running at; they could not write a file at a lower security
level. This prevents Trojan Horse programs from giving data away.
The kernel itself did not emulate UNIX; there was a UNIX emulator
that ran on top of the kernel that did this. The kernel supported only
block-oriented files and had a flat directory structure, for simplicity;
the UNIX file system semantics were simulated in the emulator.
The entire kernel was coded in Modula I. There were no pointers,
everything was done with subscripted tables. It ran on a PDP 11/70,
worked reasonably well, but was much slower than PWB/Unix on the
same hardware. The real problem was that the kernel wouldn't fit in
64K until we took out all the speed optimizations to make it fit;
schemes to support a larger kernel by using the memory management hardware
were considered and rejected as possibly leading to security bugs. This
problem combined with a serious performance problem caused by the
emulator approach led to a very slow system; overall UNIX performance
was about 25% of PWB/UNIX.
It is still used at Logicon as a base for a special-purpose
application, but the UNIX emulator is not used; only the kernel remains.
In retrospect, had the system been implemented on a machine without
the PDP-11s address space restriction, it probably would have been much
more successful, although it inherently would have run at about half the
speed of a UNIX on the same hardware. But for many DoD applications this
would have been quite acceptable.
There were a number of useful results. One is that it was demonstrated
that it is possible to write an operating system in a very restrictive
language without overriding the type system. (Modula I did not have ANY
way to get around strong typing.) There were about 900 lines of assembler
in the system, almost all of which were present strictly to handle memory
management and domain crossing. All the device drivers and the file system
were 100% Modula I. This was at times painful, but debugging was very easy.
Once everything compiled, it tended to run. And when it didn't, finding the
problem was usually trivial. But getting everything to compile (in one giant
compile for the kernel) could take days; the compilations themselves took
20 minutes each.
Another was that the specification/verification approach needed a lot
of work to be usable. Don Good's group at the University of Texas has
advanced the state of the art much further than SRI ever did in this
area (despite much hype from SRI at the time). It is now possible to
build small, secure, real-time programs, using the Gypsy language and
its verification system developed at U. Texas.
I myself designed and implemented the file system and all I/O for
KSOS. It was an interesting two years. Many of the people on the project
went off to found Sytek, Inc, which went on to develop the local area net
for the IBM PC.
Some of the people who worked on the project were
Mike Pliner
Jay McCauley
Rance DeLong
Dan Ladermann
Mark Gang
Thomas Berson
Luke Dion
Norm Abromowitz
Ken Biba
Pat Carruthers
John Nagle
Ford Aerospace and Communcations Corp.jbn@wdl1.UUCP (01/16/85)
Another comment on UNIX security: things are getting worse. V7 Unix was substantially tighter than later versions; the only shared objects were files, there weren't too many set-UID-to-root programs, and the semantics of file protection was well understood. Since then, a lot of new machinery has been added inside the security perimeter, which includes the kernel and all set-UID-to-root programs. UNIX at the 4.2BSD level now rivals the giant mainframe operating systems of the 1960s and 1970s, and is equally weak in the security direction. There are just too many primitives and no security model.
jbn@wdl1.UUCP (01/16/85)
A secure VM kernel is indeed possible, and exists; it is called KVM/370 and was developed by Systems Development Corporation several years ago. The major problem with it is that it provides hard separation between virtual machines running on the same hardware; the virtual machines cannot intercommunicate or share files at all. The overhead is higher than standard VM, but is supposedly tolerable. It supports a DoD-type security model.
jjg@security.UUCP (Jeff Glass) (01/18/85)
> Also while on the subject Honeywell is having a new computer certified > by the NSA for security class A2. This computer is unix call compatible > and is called SCOMP's look for it when it receives final security > classification. Honeywell's SCOMP has been certified by the Department of Defense Computer Security Center (sponsored by NSA) as an A1 operating system. This means that its Trusted Computing Base (kernel, trusted software) has been formally specified and verified. Reliable sources tell me that an announcement will appear in ComputerWorld magazine. > Since Multics was broken into by an Air Force Tiger Team in the early > 70's and their methods of breakins fixed via Project Guardian Multics > has not been broken into unless the Person breaking in had a users login > name and password. the Multics OS has been completely revised since then; Multics is also being evaluated by the DODCSC, and will have a B2 rating. The major difference between an A1 rating and a B2 rating is that formal specification is not done for a B2 evaluation. /jeff -- security!jjg@mitre-bedford.ARPA (MIL) jjg@security.UUCP (UUCP) decvax!cca!security!jjg (UUCP) {allegra,ihnp4,utzoo,philabs,uw-beaver}!linus!security!jjg (UUCP)
smk@axiom.UUCP (Steven M. Kramer) (01/19/85)
Just to clarify the Larry's discussion on the SCOMP -- it is beging evaluated
for A1 (formally verified specs) by NSA. A2 means code verification and
to my knowledge is beyond the state of the art.
Also, just because we don't hear of breakins to OS's doesn't mean they don't
happen. Would your local bank advertise such facts with no other reason but
to just say, "Oops, it happened to us!" Would the US Intelligence community!!?!
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)waynef@AMSAA.ARPA (CSD) (05/01/85)
Dear Larry,
I heard you wanted some mail , so I thought I'd send you some. Uh, ok,
Uh , ok, so I typed this letter in and everything, uh I'm going to stop
now and stuff. Ok, have a nice weekend and all.
Your buddy,
Bobrkn@ORNL-MSR.ARPA (Roger E. Stoller at 576-7886) (10/08/85)
does anyone have any experience with a product called eunice(which is in all likelyhood spelled wrong here) which is a version of unix which runs under vms? please reply to rkn@ornl-msr.arpa. thanx
toense@NBS-VMS.ARPA (TOENSE, ROBERT) (10/11/85)
I am resisting the temptation to flame. We are currently using Eunice under VMS on our 780. We will soon be running 4.2(3?) BSD. Enough said. Robert E. Toense TOENSE@NBS-VMS.ARPA ------
fm@MITRE-BEDFORD.ARPA (10/18/85)
[ ... does anyone have info about eunice ... ? ] Yes. We're using Eunice on top of VMS. It's a poor excuse for UNIX. Very buggie -- very slow. We've had so many problems with the cshell in our version that we've completely shut it off. We still use the Bourne shell and seem to be able to avoid most of the problems we were having. Eunice is better than not having a UNIX environment but just barely. We've got DECshell on order and expect it to be superior as an add-on to VMS. We'll have to be satisfied with the version 7 flavor of UNIX -- no cshell with DECshell. Frank Martin The MITRE Corp. Houston, TX