Message-ID: <871080DEC5874D41B4E3AFC5C400611E026EE417@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: Counseling not to use Windows (was Re: Anonymoussurfing my ass\!)

Comments inline.

Paul Schmehl (pauls@...allas.edu)
Supervisor of Support Services
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/


> -----Original Message-----
> From: David F. Skoll [mailto:dfs@...ringpenguin.com] 
> Sent: Monday, July 15, 2002 2:10 PM
> To: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] Counseling not to use Windows 
> (was Re: Anonymoussurfing my ass\!)
> 
> > Sorry to pick on your example but an extension merly indicates what 
> > kind of data is in the file.
> 
> Not under Windows as it is configured by 99.99% of end-users. 
>  If you name a file "foo.txt", very different things happen 
> if you click on the file than if you click on the exact same 
> file named "foo.exe".

That depends on how the admins configure things. :-)  Here at UTD, for
example, it isn't possible to execute a VBS file unless you know what
you're doing.  It's also possible to restrict the executables that a
user can run, using group policies.
> 
> > A .txt extension suggests that a user might want to
> > hand the file to a program that'll treat the file as plain ASCII, 
> > similarly an .exe extension suggests that a user might want to give 
> > the file some memory and time slices and treat it as a 
> program in it's 
> > own right. You could load the .exe into notepad, and you 
> could execute 
> > the .txt file.
> 
> Again, for 99.99% of end users, such fine points are 
> irrelevant.  To them, clicking on an .exe runs the program.  
> Windows even "helpfully" hides the extension by default.

And you think they will do *better* at this in *nix?  You've pinpointed
the problem, but missed the solution.  The problem is the *users* who
are ignorant and chose to remain that way.  The solution is for the
*conscientious* admins to understand that truth and find ways to defend
the enterprise *anyway*.
> 
> That is true when it comes to memory protection, but what 
> you're talking about is filesystem protection, and Linux 
> doesn't "pretend" anything -- it enforces it.  I believe it 
> is possible under some versions of Windows to allow read 
> access but not execute access to files and directories, but 
> again, 99% of end-users don't know this and don't configure it.

Your ignorance of Windows is showing.  It is possible, under all
"modern" versions of Windows (not the 9x variety) to get as granular as
this (at the directory or file level):

Full Control
Traverse Folder / Execute File
List Folder /Read Data
Read Attributes
Read Extend Attributes
Create Files / Write Data
Create Folders / Append Data
Write Attributes
Write Extended Attributes
Delete
Read
Change
Take Ownership

It isn't the OS that's the problem.  It's the manufacturer's choices of
default settings and the ignorance of the users (and admins in many
cases.)  Isn't this precisely the same problem on *nix?  Give me an
ignorant user on a default install of *nix and I'll give you a hacked
box in a few minutes (except perhaps OpenBSD, which is one of the few
that ship "secure" out of the box.)

Please don't misunderstand - I am NOT saying Windows is a good as or as
secure as Unix.  Given the choice, I'll take OpenBSD.  But the *real*
problem isn't software, it's humans.

Powered by blists - more mailing lists