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: permissions idea (Re: [9fans] on the topic of viruses)

[Douglas A. Gwyn]

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I'm still wondering a random number created by a certain computer
> program is really random???  :-)

It's easy enough, when the hardware exists (and cheap to provide when
not already available), but there's no real need for it to implement
capas; processes can't really loop to guess values for a capa, since
one wrong guess terminates them, and there is no backward inheritance
so forking the guesses doesn't help.

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

[okamoto]

>Capability-based security is
>an old idea, but there have some recent developments
>that may make it more practical.

I'm still wondering a random number created by a certain computer
program is really random???  :-)

Kenji   -- yes, I'm kidding--

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

[presotto]

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

Create two groups:

friends
acquaintances

then create the file

> file
chgrp -o friends file
chgrp acquaintances file
chmod 640 file

Make yourself the leader of friends and acquaintances.

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

From: Matthew Hannigan <mlh@zip.com.au>
To: 9fans@cse.psu.edu
Subject: Re: permissions idea (Re: [9fans] on the topic of viruses)
Date: Tue, 02 Oct 2001 17:11:08 +0200
Message-ID: <3BB9D90C.C27A64E3@zip.com.au>



"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