Counseling not to use Windows (was Re: Anonymous surfing my ass\!)

[full-disclosure () lists netsys com (David F. Skoll)]

On Mon, 15 Jul 2002, Roland Postle wrote:

> > because of programming errors.  Encoding metadata such as "executableness"
> > in a filename, for example, is a fundamental design flaw, and one that's
> > impossible to correct without changing Windows' design.

> 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".

> 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.

> As for the actual security of whether a user /can/ execute a file, Windows
> doesn't seperate 'read' and 'execute' privileges well enough. However it's
> my understanding that's got more to do with the design of the x86 memory
> architecture than Windows' design. Linux just pretends to seperate 'r' and
> 'x' privs because it's a unix clone. I'm prepared to stand corrected on that
> though.

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.

> I agree completly that Windows does have some fundamental design flaws that
> prevent it being locally secure. A better example might be the ability of an
> application to send messages to another application, apparently without
> regard for who the owner of the target application is.

:-)  I'm not familiar enough with Windows to be aware of things like that.
Thanks.

Regards,

David.