Re: [9fans] on the topic of viruses

Re: [9fans] on the topic of viruses

[dmr]

Thanks for the typo-correction for the URL:

http://www.cs.bell-labs.com/who/dmr/tdvirus.pdf

is indeed the correct current place.  I heard from Duff
that he's content to have it visible.

The topic is somewhat off-topic for Plan 9, but not
by too much, because similar schemes remain plausible
in Plan 9 systems.  Among the small changes to recent
filesystems/protocols is the transmission and maintenance
of a last-modifier UID for files--one of the minor but
useful diagnostic tools that help.

Gwyn's correct, by the way, that AT&T Federal Systems
did do System V/MLS certified to B1 or B2 or so.
This was independent of the McIlroy and Reeds work,
though I'm certain there was consultation.

	Dennis

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> http://www.cs.bell-labs.com/who/dmr/tdvirus.pdf

i love the scan.  i know that i'd read it, i just can't think how.

paul vixie changed gatekeeper's kernel in '92/93 so that only root
could set the public execute bit as a form of certification, which
duff speaks of.  of course, this was just glue but nevertheless a
clever, easy to implement and efficient hack.

Re: [9fans] on the topic of viruses

[Bobby Dimmette]

System V/MLS is still being used in a few places today.  It was
available on the 3B2 (we32k and mips versions) and x86 platforms.  It
was certified C2 and B1.  The government had a contractual requirement
for MLS, but access controls seemed like a good idea anyway.  The
constraints of MLS affected usability and made it difficult to sell.

dmr@plan9.bell-labs.com wrote:

> Gwyn's correct, by the way, that AT&T Federal Systems
> did do System V/MLS certified to B1 or B2 or so.
> This was independent of the McIlroy and Reeds work,
> though I'm certain there was consultation.
>
>         Dennis

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> System V/MLS is still being used in a few places today.  It was
> available on the 3B2 (we32k and mips versions) and x86 platforms.

i'd forgotten about that system.

those 3B2's [we32k] were horrible machines.

Re: [9fans] on the topic of viruses

[Bobby Dimmette]

I think the backplane/peripheral IO was the biggest problem for the
3B2.  And it wasn't solved just by putting an R3000 on the system
board...  There was a project around 1992 to port the Plan9 file and cpu
kernels onto the mips version.  In the end, it did not prove practical.
If they had just used VME...

 From a security aspect, the we32000 was immune to stack-based buffer
overflow attacks because the stack grew downward leaving the call/return
structure unaffected.


Boyd Roberts wrote:

> > System V/MLS is still being used in a few places today.  It was
> > available on the 3B2 (we32k and mips versions) and x86 platforms.
>
> i'd forgotten about that system.
>
> those 3B2's [we32k] were horrible machines.

Re: [9fans] on the topic of viruses

[Douglas A. Gwyn]

dmr@plan9.bell-labs.com wrote:
> ... AT&T Federal Systems
> did do System V/MLS certified to B1 or B2 or so.

What I found especially fascinating was that the security
policy was enforced even within the 5620 terminal's
windowing system, so that the user could not cut and
paste data between levels in the "wrong" direction.

Re: [9fans] on the topic of viruses

[Douglas A. Gwyn]

Bobby Dimmette wrote:
> From a security aspect, the we32000 was immune to stack-based buffer
> overflow attacks because the stack grew downward leaving the call/return
> structure unaffected.

It would have to grow *up*ward to prevent an overrun of a local
variable from affecting the previous call frame.

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> It would have to grow *up*ward to prevent an overrun of a local
> variable from affecting the previous call frame.

yeah it took me a few reads of that to work out that stack grew *up*.

i was thinking, now how did the vax do it?  P1BR/P1LR trickery.

permissions idea (Re: [9fans] on the topic of viruses)

[Matthew Hannigan]

Fantastic read.  One of the most interesting bits
for me was reading x permissions described as not
really permissions at all, which is what I've always
thought.  Nice to see it repeated by a more learned
person.

My answer to this would have been to remove them
entirely, not elevate them to a certificate of trust
though?

(thinks bubble)
maybe we reassign the bits meaning: instead of
rwxrwxrwx perhaps we could have rwrwrwrwx where
the doubles are for owner, writing group,
reading group, trustable.

4 groups covers 99+44/99 possibilities.  no need
for icky acls ...

Now all I have to do is solve on disk compatibility...

-Matt
PS. sorry if all this is solved by plan9 .. I confess
I haven't installed it yet!


Boyd Roberts wrote:
> 
> > http://www.cs.bell-labs.com/who/dmr/tdvirus.pdf
> 
> i love the scan.  i know that i'd read it, i just can't think how.
> 
> paul vixie changed gatekeeper's kernel in '92/93 so that only root
> could set the public execute bit as a form of certification, which
> duff speaks of.  of course, this was just glue but nevertheless a
> clever, easy to implement and efficient hack.

Re: permissions idea (Re: [9fans] on the topic of viruses)

[Matthew Hannigan]

Matthew Hannigan wrote:
>
> maybe we reassign the bits meaning: instead of
> rwxrwxrwx perhaps we could have rwrwrwrwx where
> the doubles are for owner, writing group,
> reading group, trustable.

should read:
	.. owner, writing, reading, OTHER, trust bit.

Re: permissions idea (Re: [9fans] on the topic of viruses)

[Douglas A. Gwyn]

Matthew Hannigan wrote:
> ... perhaps we could have ...

I don't think any scheme with fixed categories of trust
can suffice for heavy-duty security.  Even the military
(fixed) "levels" are augmented by orthogonal (freely
created) "compartments" to attain betten control over
access.  The big problem in automating a security
policy is in stopping people or programs from taking it
upon themselves to circumvent the policy.  The only
viable solution I know of is for *every* mode of access
to *every* object to require the accessor to possess an
appropriate "capability".  Capability-based security is
an old idea, but there have some recent developments
that may make it more practical.

Re: permissions idea (Re: [9fans] on the topic of viruses)

[Matthew Hannigan]

"Douglas A. Gwyn" wrote:
> 
> Matthew Hannigan wrote:
> > ... perhaps we could have ...
> 
> I don't think any scheme with fixed categories of trust
> can suffice for heavy-duty security. ...	

Sure; I was just trying to figure out how
to get the mostest for the leastest.

I still think that my scheme of two groups
solves a large nr of cases.

How does plan9 solve the problem of someone
wanting to allow his close friends having write
access, acquaintances read access and others none?

I had a look at the man page but it seems to
have the same triple as unix.  Or can the
owner be a group?

Regards,
 -Matt

[9fans] capability-based design (Re: permissions idea)

[Richard]

Douglas A. Gwyn writes:

>  The only
>viable solution I know of is for *every* mode of access
>to *every* object to require the accessor to possess an
>appropriate "capability".

word.  let me give the reader a little taste of capability-based
design, for those who might not know it.  In a capability-based OS, a
program does not have free access to the filesystem.

suppose that in Plan 9 the shell and the rm command were rewritten so
that in the execution of the command

  rm foobar

the shell opened the file foobar and passed the open file descriptor to
rm.  (this would of course mean expanding the argc/argv interface so
that not only strings but also file descriptors can be passed in.)
suppose further that all commands worked this way, and that the OS
prevented commands (programs) from directly opening files.  well, more
precisely, suppose that the open subroutine would obtain the user's
permission before opening the file.

in such an OS, a command cannot modify the filesystem behind the user's
back.  in contrast, in Unix and Plan 9, a command written by a malicious
programmer can, eg, erase or introduce errors into a user's data files.

the risk of inadvertently running a malicious program is not a big
problem in practice for many of us, so the reader might not be attracted
to the idea of changing things just to avert that risk.  note though
that the capability ("capa") design averts the risk without adding a lot
of new code (as the stupid idea of digital immune systems does), but
rather mainly by readjusting the interface between shell and command.
elegant!

a more practical benefit of the capa approach that might appeal more to
the average desktop user is the discipline it imposes on app writers.
specifically, the app must asks permission (from the OS, which
then might ask the user) before doing anything significant to the user's
software environment.  

eg, if a community of users got into the habit, for example, of guarding
the ability to display animated graphics behind a capability, then an
app writer who wanted to distribute an app into that community would
have to write code that explicitly asks permission to display
animations, even if the app already had permission to write static
graphics to the screen.

another, classic example is that if you install Internet Explorer on
Windows, it or its installer is free to fuck up your already-installed
Netscape.  in a capa OS, the IE installer cannot make IE your default
browser without obtaining permission.  this restriction is enforced by
the kernel just like the restriction that the IE installer cannot access
memory belonging to another process.

a typical desktop computer is used by only one person but contains apps
written by thousands of programmers.  if you are like me, you would like
app writers to have less power over the other apps on your desktop and to
make fewer assumptions about your software environment.  this of course,
takes us outside of security per se, into the realm of giving users
more control over apps, not by exhorting app writers to change, but
by introducing a new platform that forces them to change or else
their code does not run.

Re: [9fans] on the topic of viruses

[dmr]

Might as well respond to Rob, though there are several
suspended historical questions.

The first VAX machines our own group (1127) bought were VAX 11/750s.
The Reiser+London folks in Bell Labs at Holmdel had already done
the 32V (on 11/780) that travelled to Berkeley and became 4.* BSD;
here, we were still on PDP-11/70. About the same time our
larger organization (112) decided to buy a central server for
things like mail and Usenet and various shared data: this was the
VAX 11/780 called Alice (I get mail first sent to dmr@alice.att.com).
These all, at first, ran 32V, but not the version that was
distributed.  John Reiser and Tom London did quite a few
interesting things, including an inherently more sophisticated
virtual memory scheme than earliest BSDs--at least, for example,
treating the VM page pool as integrated with the buffer cache.

However, at some point the Holmdel group perceived that
as a Unix research project they were at an end point;
USG and System III and then V were being
thought of as a potential product as divestiture approached.

They, and we, decided that 32V was over.  The VAX BSD distributions
had begun, and Chesson brought in an early BSD (I think 4.1c)
and ran it on the experimental 750.  No one here was enthusiastic
about touching its paging scheme, but this (maybe a slightly
updated) system had the character-device part scooped out
and replaced by the stream I/O mechanisms in 8th Edition.
Once this was working well enough, it displaced the 32V
systems, eventually on alice and her companion rabbit.

The early 11/750 had plenty of bugs.  I forget the precise
details of why copy-on-write wasn't easy, but it was
approximately that incorrect status was stored on a
a write-to-read-only page fault.  This or a similar bug
also affected stack extension.  (Something like: if a
calls instruction is the last one on a page, and the
stack pointer refers to a page not in memory, the
saved instruction location is not that of the faulting
instruction, but something else).

Re Presotto's observation about ICP/IP:  the
8th edition system including Streams was already pretty
much in place by the time that Robert Morris adapted
the then-current BSD TCP/IP stack to streams.  At that time,
we were using either serial communication over various modems,
and more notably Datakit. Looking back at this, one of
the satisfying things is that the communication structure
built then was adaptable so smoothly to TCP/IP when
the protocol's importance became undeniable.

	Dennis

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> >>i think i thought EGREG had something to do with it as well.

not known to work reliably at any speed, but the code is huge.

Re: [9fans] on the topic of viruses

[Ralph Corderoy]

Hi,

> I'll let someone who knows answer, such as Dennis.
> Boyd is wrong.

I thought that Thompson did it quite early on and by the time he
announced it with that paper the compiler had long since been replaced
by Johnson's PCC.

PCC was at its late formalative stage around March 1976 according to
Dennis.

    http://cm.bell-labs.com/cm/cs/who/dmr/firstport.html


Ralph.

Re: [9fans] on the topic of viruses

[forsyth]

>>i think i thought EGREG had something to do with it as well.

that, i suspect, would be chesson, and might have been prompted
by the mpx implementation.

Re: [9fans] on the topic of viruses

[rog]

> The closest we got to using 4.n BSD was when Robert Morris, now at MIT,
> imported the 4.1c TCP/IP stack into 7/8th edition (I believe in 84)
> nominally as my summer student.

it's funny, i'm not entirely sure why now, but i'd always assumed there was
some connection between the 9th/10th edition and BSD. i think my
misapprehension came from the existence in the 10th edition manuals of
deprecated(2), which held some sys calls that i'd assumed were unique
to the BSD lineage.

i think i thought EGREG had something to do with it as well.

  rog.

Re: [9fans] on the topic of viruses

[rob pike]

When Dennis wakes up he'll say more, but my foggy memory holds that
although we ran a 32V kernel for a while, we eventually cut over to a
Berkeley kernel that was then hacked to ribbons and eventually led to
the 8th edition.  It may even have been multi-step: Berkeley, 32V,
Berkeley.  There was a lot of hand-wringing over which kernel the
research machines should run.  Hands still wring today, on occasion.

-rob

Re: [9fans] on the topic of viruses

[presotto]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

Huh, I was at Berkeley from 79-83 and Ken wasn't anywhere to be seen.
I believe he left Berkeley as a student aroung 66 and taught there
for a year in 75 on sabbatical from the labs.

The closest we got to using 4.n BSD was when Robert Morris, now at MIT,
imported the 4.1c TCP/IP stack into 7/8th edition (I believe in 84)
nominally as my summer student.

[-- Attachment #2: Type: message/rfc822, Size: 2065 bytes --]

From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] on the topic of viruses
Date: Mon, 1 Oct 2001 11:51:20 +0200
Message-ID: <003401c14a5e$9feb1710$a2b9c6d4@SOMA>

> It seems more recent than I had guessed - or could the 1984 article
> have been written some time after Ken's experiment??

iirc, i think he is rumoured to have done it around when he went to UCB.
that musta been the early '80s 'cos i think that how he came back with
4.1BSD which became 8th Ed (it was around in '84).

yes, correct your family tree diagrams now :)

Re: [9fans] on the topic of viruses

[rob pike]

[-- Attachment #1: Type: text/plain, Size: 78 bytes --]

I'll let someone who knows answer, such as Dennis.
Boyd is wrong.

-rob


[-- Attachment #2: Type: message/rfc822, Size: 2587 bytes --]

From: Digby Tarvin <digbyt@acm.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] on the topic of viruses
Date: Mon, 1 Oct 2001 10:46:23 +0100 (GMT/BST)
Message-ID: <200110010946.KAA21139@cthulhu.dircon.co.uk>

Yep - that was it. A brilliant explanation too. Thanks to all that
pointed it out to me.

It seems more recent than I had guessed - or could the 1984 article
have been written some time after Ken's experiment??

Regards,
DigbyT

rob pike:
> This was described in Ken Thompson's Turing Award lecture:
> 
> 	http://www.acm.org/classics/sep95
> 
> -rob
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] on the topic of viruses

[Ralph Corderoy]

Hi Digby,

> I have often wondered if it just urban legend, or is there a basis in
> fact?

It was Ken Thompson and he described it on accepting the ACM's Turing
Award.

    http://www.acm.org/classics/sep95/

Cheers,


Ralph.

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> It seems more recent than I had guessed - or could the 1984 article
> have been written some time after Ken's experiment??

iirc, i think he is rumoured to have done it around when he went to UCB.
that musta been the early '80s 'cos i think that how he came back with
4.1BSD which became 8th Ed (it was around in '84).

yes, correct your family tree diagrams now :)

Re: [9fans] on the topic of viruses

[Digby Tarvin]

Yep - that was it. A brilliant explanation too. Thanks to all that
pointed it out to me.

It seems more recent than I had guessed - or could the 1984 article
have been written some time after Ken's experiment??

Regards,
DigbyT

rob pike:
> This was described in Ken Thompson's Turing Award lecture:
> 
> 	http://www.acm.org/classics/sep95
> 
> -rob
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] on the topic of viruses

[rob pike]

This was described in Ken Thompson's Turing Award lecture:

	http://www.acm.org/classics/sep95

-rob

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> On the subject of sneaky Unix hacks, it reminded me of a story
> that I think I first heard back in my student days the late 70s
> which I think was attributed to you Dennis...

it was ken.

> I have often wondered if it just urban legend, or is there a basis in fact?

it's all explained in _reflections on trusting trust_:

    http://www.acm.org/classics/sep95

Re: [9fans] on the topic of viruses

[Digby Tarvin]

Thanks for the fascinating read.

On the subject of sneaky Unix hacks, it reminded me of a story
that I think I first heard back in my student days the late 70s
which I think was attributed to you Dennis...

As I recall it was a trojan horse attack based on a modification
to the C compiler which caused it to recognise when it was compiling
the login program, and insert appropriate sneaky back door in the
generated code.

The really sneaky bit was that it also recognised when it was
compiling an unmodified source for the C compiler, and inserted
this and the modification above in the generated code.

The end result was that no modified source code need remain
on the system, but a complete rebuild from clean source would
result in the back door still being generated....

I have often wondered if it just urban legend, or is there a basis in fact?

Regards,
DigbyT

dmr@plan9.bell-labs.com:

> I've been interested in this too, though until now I've
> never asked TD about it directly (but just did).
>
> I retrieved the internal tech-memo version of Duff's paper
> from the BL library's collection.  It's a big page-scan
> (768KB in PDF).  Usenix doesn't seem to have the published
> version.
>
> For the moment, it's available at
>  www.cs.bell-labs-com/~dmr/tdvirus.pdf
>
> If Tom objects, I'll withdraw it.  But it's a nice paper.
>
> 	Dennis
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] on the topic of viruses

[Anthony Mandic]

dmr@plan9.bell-labs.com wrote:

> For the moment, it's available at
>  www.cs.bell-labs-com/~dmr/tdvirus.pdf

	Slight typo here. Correcting the second dash to a dot
	brings up http://www.cs.bell-labs.com/who/dmr/tdvirus.pdf
	as the URL.

-am	© 2001

Re: [9fans] on the topic of viruses

[dmr]

 > apparently point 18 in the references section of "Multilevel Security in
 > the UNIX Tradition" ( http://www.cs.bell-labs.com/cm/cs/cstr/163c.ps.gz)
 > lists a paper by tom duff called "Experience with Viruses on UNIX
 > Systems" (Computer Systems 2, 1989), which apparently tells the tale of
 > this very same virus you were discussing today...

 > i can't find the paper unfortunately, but it definitely sounds
 > interesting

I've been interested in this too, though until now I've
never asked TD about it directly (but just did).

I retrieved the internal tech-memo version of Duff's paper
from the BL library's collection.  It's a big page-scan
(768KB in PDF).  Usenix doesn't seem to have the published
version.

For the moment, it's available at
 www.cs.bell-labs-com/~dmr/tdvirus.pdf

If Tom objects, I'll withdraw it.  But it's a nice paper.

	Dennis

Re: [9fans] on the topic of viruses

[Boyd Roberts]

> i can't find the paper unfortunately, but it definitely sounds
> interesting

some of us know our history ...

[9fans] on the topic of viruses

[andrey mirtchovski]

apparently point 18 in the references section of "Multilevel Security in
the UNIX Tradition" ( http://www.cs.bell-labs.com/cm/cs/cstr/163c.ps.gz
) lists a paper by tom duff called "Experience with Viruses on UNIX
Systems" (Computer Systems 2, 1989), which apparently tells the tale of
this very same virus you were discussing today...

i can't find the paper unfortunately, but it definitely sounds
interesting

andrey