With the shipment of Microsoft Corp.s .Net Framework run-time environment last week, Windows developers have a powerful new platform for developing secure applications in any .Net language. .Net is a radical rethinking of how Windows application security works and jumps Windows security forward several generations.
In an all-day briefing with eWeek Labs, Brian LaMacchia, development lead, .Net Framework security system, described the security policy framework, code-level security attributes, isolated application storage area, cryptographic framework and other security changes in the new .Net environment.
Based on an early look at .Net Framework, eWeek Labs believes that these changes will make it far easier for developers using .Net languages to write applications that are resistant to tampering and that store user data more securely. However, the .Net Frameworks security impact will be limited as long as native C or C++ applications are common on Windows.
Wide-scale deployment of applications built on the new security model is at least a few years away, and existing Windows applications dont benefit at all from this new security model: Windows systems are still just as vulnerable to non-.Net attacks. “Ultimately, we are dependent on the security of the OS,” Microsofts LaMacchia said.
The most significant security capability in .Net is an application environment that enforces a “least privileges” programming model, one where developers can specify at development time the particular rights an application needs to run, as well as the rights the application should refuse. As with Java, .Net permissions can be set very precisely—down to files and other machine resources.
All rights are enforced at a system level and apply even if users with administrator rights run the software, something that has never before been the case with Windows.
Administrators can further restrict program rights using Microsofts new .Net Runtime Security Policy editor.
The new security model is a sea change from previous Windows security models, where programs started with administrative permissions can modify any system resource. Unfortunately, many programs are configured this way in Windows, one of the main reasons for the operating systems security troubles.
Enforcing program permissions independently of user permissions is a trademark of trusted operating systems and has long been used in high-security intelligence and banking applications.
eWEEK Labs analysis of the new security scheme did reveal some potential security problems. By default, .Nets run-time engine uses Internet Explorers zone rules to determine in which security class to run downloaded code, and this zone detection system has had many security bugs in the past. In addition, if .Net applications require the right to call non-.Net code (something that hybrid .Net/Windows programs will require), they can bypass .Net security rules.
The bottom line, however, is that the new security rules are many times better than whats currently available to C or Visual Basic developers.
eWEEK Labs West Coast Technical Director Timothy Dyck can be reached at timothy_dyck@ziffdavis.com.