Module 2

Software Security Practices

Introduction
This module will discuss Evidence-based security vs. code access security, best
security coding practices, oAuthentication to system resources and services and
Encryption of data between systems and services in different phase of programming.

Lesson 1
Evidence-based security vs. code access security

I. Learning Outcomes

In this lesson, the students should be able to:

1. Understand the important of setting permission and security in terms of

protecting some programs.

II. Core Content

Evidence-Based Security Policy

How does the Common Language Runtime (CLR) decide which permissions to
grant and which to deny? Code access security is also known by another name:
evidence-based security. The CLR examines the evidence associated with the
code to determine which security policy group the code belongs to. The CLR then
checks what permission set is associated with that code group. (Permission sets
and code groups are described later in this article.) If the code group has the
permissions demanded, the request is granted; if not, an exception is thrown.

Evidence
To understand security policy, you first have to understand what evidence is. As
mentioned earlier, evidence is used to authenticate the code. As such there are
several identity permissions that are used to identify code:

 PublisherIdentityPermission models the software publisher's digital

signature. This answers the question: Who published the assembly?

 SiteIdentityPermission models the web site where code originated. This

answers the question: From what web site did the assembly come?
  StrongNameIdentityPermission models the strong name of an
assembly. This answers the question: What is the name of this assembly?

 ZoneIdentityPermission models the zone where the code originated,

corresponding to the Internet Explorer zones: Local intranet, trusted sites,
Internet, Restricted, and My Computer. This answers the question: From
what zone did the assembly come?

 URLIdentityPermission models the URL and the protocol where the

code originated. The entire URL, including the protocol and the filename, is
part of the identity. This answers the question: From what URL did the
assembly come?

You can examine the evidence associated with an assembly. The evidence
collection associated with an assembly can be obtained from the evidence
enumerator.

Although they derive from CodeAccessPermission, these are not code access permission classes.
Evidence is extensible. You can define your own types of evidence.

Code Groups and Permission Sets

Code identity permissions are used to define a security policy code group. For
example, all code whose ZoneIdentityPermission is MyComputer belongs to the
predefined MyComputerZone code group. A permission set is a named set of
permissions that can be associated with a code group. Administrators specify
which code groups and permission sets are defined for their system. By
determining which code group an assembly belongs to, the CLR can determine
which permissions are allowed or denied to an assembly. More than one code
group can be associated with a permission set.

There are several built-in permission sets:

 Nothing: No permissions (cannot run).

 Execution: Permission to run, but no permissions that allow use of

protected resources.

 Internet: The default policy permission set suitable for content of unknown
origin.

 LocalIntranet: The default policy permission set for within an enterprise.

 Everything: All standard (built-in) permissions except permission to skip

verification. This is the only built-in permission set that can be modified.
  FullTrust: Full access to all resources protected by permissions that can be
unrestricted.

Determining Security Policy

Security policy is defined on four levels: enterprise, machine, user, and

application domain. The most restrictive level determines the policy. For
example, if reading a certain file is allowed on the enterprise level but denied on
a particular machine, reading the file is not allowed for assemblies on that
particular machine. On the other hand, if reading a particular file is denied on the
enterprise level, no computer in that enterprise could read that file.

Application domain security policy is defined by the host of the application

domain and is not discussed in this article. Security policy on the other three
levels is determined by administrator-defined code groups and their associated
permission sets.

Security policy is stored in several XML-based configuration files. Instead of

editing these configuration files directly, the .NET Configuration Tool is used.
This tool is used for several other tasks in addition to security. It's an MMC snap
(mscorcfg.msc) found in the Windows directory under
Microsoft.NET\Framework\vx.x.xxxx, where x.x.xxxx represents the current
version of the .NET Framework.

What Does Code Access Security (CAS) Mean?

Code access security (CAS) is a security mechanism by which the common

language runtime (CLR) of the .NET framework can restrict the managed code to
execute operations with a limited set of permissions.

CAS enforces security policies in the .NET framework by preventing unauthorized

access to protected resources and operations. Unlike traditional security
methods, where user credentials are obtained from the user, CAS is designed to
address the issues faced when obtaining code from external sources, which
contain bugs and vulnerabilities. These bugs and vulnerabilities may make a
user's system vulnerable to malicious code, which may be performing tasks
without the user knowing it. CAS actually knows and allows only those
operations a given user's code can and cannot perform. This feature is applicable
to all managed code targeting the CLR.

CAS provides evidence-based security built on a layer above the security

provided by the Windows operating system. While Windows is based on the
permissions of the user, CAS is based on the evidence for the assembly. The
assembly contains the permissions defined in the security policy and forms the
basis for allowing code to execute necessary actions.

CAS is built on the following elements, among others:

 Permissions: These are the basic rights needed to access a protected

resource or execute a protected operation.
 Permission Set: This is a set of permissions, such "full trust", "nothing",
"Internet", "local intranet" and others.
 Code Group: This is a logical grouping of code with a specified condition
for membership such as LocalIntranet_zone and Internet_zone.
 Evidence: This is assembly-related information such as application
directory, publisher, URL and security zone.
 Security Policy: This is a set of rules configured by an administrator to
determine the permissions granted for a code expressed hierarchically at
four levels as enterprise, machine, and user and application domain.
The code-executing privileged operation demands the CLR for one or more
permissions. The actual permission is calculated using the union of permission
set in the code groups and then an intersection at the policy level. The CLR
ensures the demanded permissions are in the granted permissions of the method
of that assembly. If permission is not granted, a security exception will be
thrown.

CAS provides two security modes to define permissions for code:

 Declarative security is implemented by defining security attributes at the

assembly level, class level or member level. Declarative mode is used
when calls need to be evaluated at compile time.
 Imperative security uses run time method calls to create instances of
security classes. Imperative mode is used when calls need to be evaluated
at run time.

CAS has limitations, including the malfunctioning of an application moved to

another system when the security policy is different. In addition, there is no
control on unmanaged code and no control of the development of applications to
cater to the needs of different scenarios of security settings on user systems.

To effectively use the fine-grained security technology of CAS, developers should

write type-safe code, use declarative or imperative syntax based on context,
request permissions from run time for code to run, and use secure libraries.
III. Assessment

Activity 1

Instruction: Write your answer in a one whole sheet of yellow paper. Write
your name and subject description at the above.

Guide Question
1. What is the important of putting a security and setting some permission in
some program, system or application?

IV. References

https://www.techopedia.com/definition/25169/code-access-security,
https://www.informit.com/articles/article.aspx?p=25356&seqNum=5