Summary

for RuBoard

Writing secure software and knowing what mobile code to trust are difficult problems. People have made numerous attempts at solving the problem before, and all the attempts have had their shortcomings.

Historically, attempts at secure execution of mobile code has had at least one of the following problems:

  • Too much necessary user expertise ” Source code requires too much understanding about compilers for most users to handle. Authenticode-signed ActiveX controls require users to make trust decisions on-the-fly , which most are not properly informed to decide. These mobile code options are simply too complicated or daunting.

  • Lack of user or administrator control over executed code ” Executable files can really only be checked for specific problems, such as viruses. They simply can't be secured in any real fashion in an efficient way. The "safe for scripting" option of ActiveX controls is only controlled by developers, although users and administrators can manage what controls are installed.

  • Inadequate power ” Java applets generally only run in a sandboxed environment that is too restrictive or cumbersome for many useful applications. Many scripting engines enabled for mobile code suffer from the same problem. Available mobile code formats seem like "all or nothing" propositions with respect to application power and flexibility.

Mainstream software applications and operating systems have suffered from security problems due to

  • Lack of safe programming environments ” Most C and C++ applications use standard libraries that too easily allow problems like buffer overflows. Also, there is no way to feasibly examine a C or C++ program to see if it is truly safe to run.

  • Marketing and ease-of-use pressure ” Many times, features are enabled in default installations of OSs or applications that shouldn't be. While this makes it easier for users to exploit the power of these software packages, it also makes it too easy for users to be ignorant of the security implications.

  • Ignorance and time-to-market pressure ” Some software designers or writers simply don't think about security until the specifications are generally done or most of the code is written. Security applied late in a project will likely be insufficient or incorrectly applied. Also, when qualified and careful programmers are rushed to finish their work, they make mistakes.

Before we can see how the .NET Framework addresses these issues, we must first understand how the .NET Framework functions. We will cover that in the next chapter. Then in Chapter 3, ".NET Developer Platform Security Solutions," we will see how the .NET Framework addresses today's security challenges.

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net