Re: I have 2 versions of .NET, which is being used

Scott M. wrote:
>> You have ignored the PDC tech preview of Longhorn. There was a lot
>> of .NET in that build - a significant portion of the code that
>> accessed your files was implemented in .NET. In the next public
>> build of Longhorn/Vista Microsoft quietly removed that stuff.
>
> Much of the promised file system features were eliminated because of
> the difficulty level in making it work reliably and securely. Since
> the OS is not managed itself, there shouldn't be any reason that MS
> *must* stuff .NET into it.

Did you look at WinFS critically (I did... do a Google search for my
name and WinFS)? It was extremely slow, partly because it was over
engineered (there were too many layers and they were trying to solve too
many problems). But the main problem was that it used too much memory.
In that build the WinFS service was the major consumer of memory. So
although I agree with the 'reliably' part of your comment I do not agree
with the 'securely' part.

It is the 'securely' aspect that is the reason why .NET must be used
more in operating system code. And yes, there is a *must* in that last
sentence. Native code will never fully get rid of exploits like buffer
overruns; with C++ 8 you have the option of using the 'secure' string
functions, but it is an *option*, and it will not affect code that has
been compiled with the older static CRT libraries. And anyway the
'secure' memory methods in the CRT in VS2005 will not prevent your own
pointer code from writing past the end of a buffer. There is a solution
that will detect buffer overruns in code that you have not written and
shutdown the process, but it involves kernel drivers that detect memory
usage. It is a third part product, it is expensive, and it is used by
the military and companies that have the money and require a more secure
system. In .NET a buffer overrun is impossible! You simply cannot do it.
The problem has gone away and the solution is free. If a developer had
the choice of writing new code she would be extremely stupid not to use
..NET!

This is just one example as to why .NET is more secure, and there are
many more, so many, in fact, that it is incontrovertable that .NET is
inherently more secure than native code. Since security is the *most*
important part of an operating system, it mandates that .NET is used as
much as possible in Windows.

However, as I have pointed out elsewhere, the security of a process is
only strong as its weakest link. That is invariably native code, so
Microsoft's current policy (in Vista) of providing mixed code (where the
main stuff is existing Win32 code and there is a veneer of .NET applied
on top) does not give any more security. They may as well not do it.

>> Hmmm, so Microsoft decides that they want some anti-spyware as part
>> of Windows. What do they do? Well they buy up a product that was
>> written in unmanaged VB and they port that code. Don't you think
>> that would be a good opportunity to rewrite the code as managed
>> code? (Heck, they could even use the VB porting tool that they tell
>> their customers to use <g>). No, they didn't do that, instead they
>> rewrote it as unmanaged C++. What does that say?
>
> But this isn't what I'm talking about at all. I'm talking about
> brand new applications *written* from the ground up. Purchasing a 3rd
> party product and re-writing it as unmanaged code just fits into what
> I've been saying in the first place - - today MS can't guarantee that

Huh? This fits in exactly with what I am saying. The example I gave is
*not* reuse, it is totally new rewriting (ie it is Giant Software's
*algorithms* that they are using in their Defender product), which means
that they can use *any* technology they choose. You cannot reuse VB
source code in C++: they had to throw away the VB code they bought from
Giant. So, they had a great opportunity to show the world how good .NET
is, they could have shown how the RAD aspect of VS.NET meant that they
produced it under schedule and under budget (these are the things they
are telling us about VS.NET, right?), but instead they decided to use
unmanaged C++. For goodness sake, all that this stuff does is monitor
the registry and file system and pattern matches with know exploits, if
VB can do it then a .NET language (any one, all of them are more
powerful than unmanaged VB) plus the framework library can do it better.

What does it say about Microsoft's attitude to .NET? (Hint: it says that
there are other reasons why they didn't want to use .NET. They are not
telling us what those reasons are, or what they are doing about those
problems.) It may not be .NET that is the problem, it may be that the
person in charge is a native code bigot, or that the team used for the
development were incapable of learning .NET, but even so, if we are not
told *why* .NET was not used there will always be a question mark over
the framework.

> all Windows OS's out there have .NET on them, so most code is
> unmanaged. It won't be until the .NET Framework is standard on most
> machines out there for you to see apps. written in .NET hit the
> mainstream.

No, Microsoft Defender will be on Vista, so .NET v2.0 will be
distributed as part of the operating system.

Richard
--
Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security Tutorial:
http://www.grimes.demon.co.uk/workshops/securityWS.htm


.

Relevant Pages

  • Re: Secure OS Thoughts
    ... > I have been reading a large amount about cryptography recently, ... > must be designed with security in mind from the outset. ... why has nobody created a secure operating system. ...
    (sci.crypt)
  • Secure OS Thoughts
    ... I have been reading a large amount about cryptography recently, ... must be designed with security in mind from the outset. ... why has nobody created a secure operating system. ...
    (sci.crypt)
  • Re: How good is Comodo Internet Security?
    ... A fully patched windows system is more secure (has less ... Security cannot be guaranteed. ... After you got used to your 'secured' operating system and browse ...
    (comp.security.firewalls)
  • Re: Secure OS Thoughts
    ... >must be designed with security in mind from the outset. ... why has nobody created a secure operating system. ... >checking memory copy functions, random stack locations etc.] ...
    (sci.crypt)
  • RE: [Full-Disclosure] [Paper] Designing secure desktop operating system
    ... Fedora Core 2 from Red Hat is free and includes SELinux. ... Designing secure desktop operating system ...
    (Full-Disclosure)