Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: Todd Montgomery <tmont@****.WVU.EDU>
Subject: Smart Frames the last.
Date: Tue, 13 Jul 1993 13:56:13 -0400
I took a good long look at VR last night and I got to admit I have
changed my mind about frames slightly. I think that they CAN operate
without a connection to the deck. BUT I do not think that they may
perform system functions. Reasoning:
Frames are viral constructs. What would a frame need a deck for.
It fits with their explanation better that they may be autonomous.
Even smart frames are not going to be able to get around
simple Security measures to perform system functions.
But, as I said earlier, programs could be written to place
in frames that would allow them to perform limited
functions, downloading being the most prevelant.
For those of you who agree with me (Yeah right!),
I think I will work of this and see what I can come up
with for these programs. These programs could be used
by deckers who would rather use a program to download
than using the system function. The automatic idea
that comes to mind is to make the program degradable
because of the increase in security which is constantly
occurring. Ideas?


-- Quiktek
a.k.a. Todd Montgomery
tmont@****.wvu.edu
tmont@***.wvu.edu
un032507@*******.wvnet.edu
Message no. 2
From: Dave Sherohman <esper@*****.IMA.UMN.EDU>
Subject: Re: Smart Frames the last.
Date: Tue, 13 Jul 1993 14:14:32 -0500
> Even smart frames are not going to be able to get around
> simple Security measures to perform system functions.

What about if the decker told the frame how to get around a specific
system's security when the frame was launched? (Besides, isn't this sort
of thing the reason that frames are required to have AutoExec in the
first place?)

> The automatic idea
> that comes to mind is to make the program degradable
> because of the increase in security which is constantly
> occurring. Ideas?

By that logic, shouldn't _all_ utilities degrade?

esper@***.umn.edu
Message no. 3
From: Todd Montgomery <tmont@****.WVU.EDU>
Subject: Re: Smart Frames the last.
Date: Tue, 13 Jul 1993 22:05:06 -0400
> From: Dave Sherohman <esper@*****.IMA.UMN.EDU>

>
> > Even smart frames are not going to be able to get around
> > simple Security measures to perform system functions.
>
> What about if the decker told the frame how to get around a specific
> system's security when the frame was launched? (Besides, isn't this sort
> of thing the reason that frames are required to have AutoExec in the
> first place?)
>

A decker would have to have figured out how to get around a nodes security
BEFORE he sends a frame into it. Then he{would have to program this
knowledge into the frame. By this time the system has changed. The
decker could do it on the fly, but they would have had to have worked
with the node before he launches the frame. If the decker has already
worked with the frame, what good is sending it in unless it is a
follow up?

Auto-Exec is required because the frame can't perform an Execution Test.
Check out SRII under Execution Test. Frames have no hacking pool so
they have to have Auto-Exec to even be able to execute ANY program.

> > The automatic idea
> > that comes to mind is to make the program degradable
> > because of the increase in security which is constantly
> > occurring. Ideas?
>
> By that logic, shouldn't _all_ utilities degrade?
>

No. The execution test in SRII which is replaced by Auto-Exec, which
does degrade, taylors programs to work on systems to get past the
security and make the system accept the programs. So in an indirect
way all utilities do degrade (through Auto-Exec, or by making an
execution test.) Execution test is done by the decker to taylor the
programs to get passed security on nodes. There is a very good explanation
in SRII.

-- Quiktek
a.k.a. Todd Montgomery
tmont@****.wvu.edu
tmont@***.wvu.edu
un032507@*******.wvnet.edu

Further Reading

If you enjoyed reading about Smart Frames the last., you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.