[svlug] eWeek article on MS Outlook

kmself@ix.netcom.com kmself at ix.netcom.com
Tue May 16 12:48:51 PDT 2000

On Tue, May 16, 2000 at 12:31:26PM -0700, Deirdre Saoirse wrote:
> On Tue, 16 May 2000 kmself at ix.netcom.com wrote:
> > The issue of executable content/execute bit is irrelevant when a file
> > can be sourced by an interpreter.  Examples include sourcing files
> > from the shell running a file against an interpreter, interpreters
> > which take files as arguments, and files which are executed or
> > interpreted by mediating software.  Examples, you ask?
> That's fine, except it has squat to do with desktop vs. command-line, as
> JC is asserting. My counterexample is the MacOS paradigm, where scripting
> was never a major part of the paradigm. Opening a file is opening, not
> executing.

I disagree, though it's a matter of degree, not an absolute.  Any
graphical interface adds a layer of indirection between user, data, and
applications.  There is no single logical association between clicking
(or double-clicking) a desktop icon, and the actions resulting from it.
The GUI provides this linkage, and it's often deliberately obscured from
the user.  Given a graphical shell, a file association might be "execute
file", or it might be "run foo on file".  If foo is an authoring tool,
you've opened your wordprocessor.  If foo is an interpreter, you're now
running a program.

Again, what does it mean to "open" a file, a link, a reference,...,
in a GUI?  The command line offers the user the option to apply any
specific tool to the data, the GUI, by design and intent, focuses
(or limits) this choice.


> > While the Mac may not have had the same tradition of scripting, my
> > understanding is that modern tools, including Unix shells, Perl, and
> > Python, might soon be available for the platform.  This spanks of an
> > argument closely paralleling "security by obscurity" with similarly
> > dangerous" implications.
> Perl and Python are already available for MacOS and have been available
> for years. 

...I strongly suspected you might say as much <g>

> I don't see that the security is ANY different for anything
> that can be, as you make the point, sourced into an interpreter.

You now have desktop icons, no?, that can be sourced by an interpreter
by clicking on them?  I'm not overly familiar with the Mac interface, and
I'm asking the question for information.

> > Linux and Unix have tended to be free of the types of viruses and
> > worms which plague Microsoft platforms.  While user, file, and process
> > security models under Linux provide some protection from the more
> > grossly damaging effects of typical MS Windows viruses, a world in
> > which content is treated as trusted and can be easily or automatically
> > executed is one in which viruses and worms can be spread.  There is no
> > magic shield preventing the same brain-dead application architectures
> > which have come into being in the Windows world from emerging on the
> > Linux landscape.
> >From what I see, the potential is there all along with one exception:
> there's limited damage one can do in a multi-user system when not running
> as root.


> There is NO way to reliably determine what is or is not a virus. None.


> And, for this sort of thing, there is no way to effectively prevent it,
> even on Linux. Worms are easily written and can be spread easily in
> interpreted languages.

Which brings us back to the concept of a sandbox.  How to build, how to
enforce, and how safe even a good sandbox makes things.

> -- 
> _Deirdre   *   http://www.sfknit.org   *   http://www.deirdre.net
> "Linux means never having to delete your love mail." -- Don Marti

...unless it's Martian love mail?  (Referring to an earlier sig.)

Karsten M. Self <kmself at ix.netcom.com>         http:/www.netcom.com/~kmself
    What part of "Gestalt" don't you understand?
GPG fingerprint: F932 8B25 5FDD 2528 D595  DC61 3847 889F 55F2 B9B0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20000516/473f98f8/attachment.bin

More information about the svlug mailing list