16
1 cs69 1 chow C. Edward Chow Design Principles for Secure Mechanisms CS691 – Chapter 13 of Matt Bishop

Design Principles for Secure Mechanisms

  • Upload
    tejana

  • View
    31

  • Download
    0

Embed Size (px)

DESCRIPTION

Design Principles for Secure Mechanisms. C. Edward Chow. CS691 – Chapter 13 of Matt Bishop. Design Principles for Security Mechanisms. Based on the ideas of simplicity and restriction. J. Saltzer and M. Schroeder Proceeding of IEEE 1975 describes 8 principles for security mechanism - PowerPoint PPT Presentation

Citation preview

Page 1: Design Principles for Secure Mechanisms

1cs691 chow

C. Edward ChowC. Edward Chow

Design Principles for Secure MechanismsDesign Principles for Secure Mechanisms

CS691 – Chapter 13 of Matt Bishop

Page 2: Design Principles for Secure Mechanisms

2cs691 chow

Design Principles for Security MechanismsDesign Principles for Security Mechanisms

Based on the ideas of simplicity and restriction.

J. Saltzer and M. Schroeder Proceeding of IEEE 1975 describes 8 principles for security mechanism Least Privileges

Fail-Safe Defaults

Economy of Mechanism

Complete Mediation

Open Design

Separation of Privilege

Least Common Mechanism

Psychological Acceptability

Based on the ideas of simplicity and restriction.

J. Saltzer and M. Schroeder Proceeding of IEEE 1975 describes 8 principles for security mechanism Least Privileges

Fail-Safe Defaults

Economy of Mechanism

Complete Mediation

Open Design

Separation of Privilege

Least Common Mechanism

Psychological Acceptability

Page 3: Design Principles for Secure Mechanisms

3cs691 chow

OverviewOverview

Simplicity makes designs and mechanisms easy to understand.

Simplicity reduces the potential for inconsistencies within a policy or set of policies.

Minimizing the interaction of system components minimizes the number of sanity checks on data being transmitted among components.

Restriction minimizes the power of an entity. The entity can access only information it needs.Only communicates with other entities when

necessary, and in as few and narrow ways as possible.

Simplicity makes designs and mechanisms easy to understand.

Simplicity reduces the potential for inconsistencies within a policy or set of policies.

Minimizing the interaction of system components minimizes the number of sanity checks on data being transmitted among components.

Restriction minimizes the power of an entity. The entity can access only information it needs.Only communicates with other entities when

necessary, and in as few and narrow ways as possible.

Page 4: Design Principles for Secure Mechanisms

4cs691 chow

ExamplesExamples

Sendmail reads configuration data from a binary file, compiled (freezing) from a text version of the configuration file.

3 interfaces: The mechanism that edits the text configuration file. The mechanism that comples (freezes) the text file. The mechanism sendmail used to read the binary (frozen) file.

Version control problem. What if text configuration file is newer than the binary file. Sendmail warns the user?

Should sendmail rechecks the parameters in configuration file? If the compiler allows the string name as default UID (daemon)

while the sendmail accepts only integer as UID, the input routine of sendmail will read “daemon” and return error value 0. 0 as UID is root!

Sendmail reads configuration data from a binary file, compiled (freezing) from a text version of the configuration file.

3 interfaces: The mechanism that edits the text configuration file. The mechanism that comples (freezes) the text file. The mechanism sendmail used to read the binary (frozen) file.

Version control problem. What if text configuration file is newer than the binary file. Sendmail warns the user?

Should sendmail rechecks the parameters in configuration file? If the compiler allows the string name as default UID (daemon)

while the sendmail accepts only integer as UID, the input routine of sendmail will read “daemon” and return error value 0. 0 as UID is root!

Page 5: Design Principles for Secure Mechanisms

5cs691 chow

Example for Avoiding Inconsistency in Policies

Example for Avoiding Inconsistency in Policies

Policy rule1: TA needs to report any cheating. Policy rule2: ensure the privacy of student files. Case:

TA reminds student file not submitted. Student asks TA to look for files in student’s directory. TA finds two files. Unsure which files. TA reads the first file, it turns out to be written by other TA reads the 2nd file, it turns out identical except names. TA reports the cheating. Student charges TA violating his privacy by reading the first set

of files.

Policy rule1: TA needs to report any cheating. Policy rule2: ensure the privacy of student files. Case:

TA reminds student file not submitted. Student asks TA to look for files in student’s directory. TA finds two files. Unsure which files. TA reads the first file, it turns out to be written by other TA reads the 2nd file, it turns out identical except names. TA reports the cheating. Student charges TA violating his privacy by reading the first set

of files.

Page 6: Design Principles for Secure Mechanisms

6cs691 chow

Examples of RestrictionsExamples of Restrictions

Government officials are denied access to info for which they have no need (the “need to know” policy). They cannot communicate that which they do not know.

Case: Imparting information by not communicatingBernstein and Woodward, Watergate reporters, ask the source to hang up if information was inaccurate, remain on the line if the information was accurate.

Government officials are denied access to info for which they have no need (the “need to know” policy). They cannot communicate that which they do not know.

Case: Imparting information by not communicatingBernstein and Woodward, Watergate reporters, ask the source to hang up if information was inaccurate, remain on the line if the information was accurate.

Page 7: Design Principles for Secure Mechanisms

7cs691 chow

Principle of Least PrivilegesPrinciple of Least Privileges

A subject should be given only those privileges that it needs in order to complete its task.

Exception case?: for certain action, subject’s access right can be augmented but relinquished immediately on completion of the action.

Append right? vs. write right In practice, most system does not have the granularity

of privileges and permission required to apply this principle precisely.

The designers of mechanisms try their best? Does the root/administrator user concept violate the

above rule?

A subject should be given only those privileges that it needs in order to complete its task.

Exception case?: for certain action, subject’s access right can be augmented but relinquished immediately on completion of the action.

Append right? vs. write right In practice, most system does not have the granularity

of privileges and permission required to apply this principle precisely.

The designers of mechanisms try their best? Does the root/administrator user concept violate the

above rule?

Page 8: Design Principles for Secure Mechanisms

8cs691 chow

Example of Tomcat User Access Control Files

Example of Tomcat User Access Control Files

<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="cs526stu"/> <role rolename="softwareRequester"/> <role rolename="tomcat"/> <role rolename="cs526prof"/> <role rolename="role1"/> <role rolename="manager"/> <role rolename="admin"/> <user username="cs526stu" password="xxxx" roles="cs526stu,manager"/> <user username="softwareRequester" password="sesame" roles="softwareRequester"/> <user username="tomcat" password="xxxx" roles="tomcat"/> <user username="cs526prof" password="xxxx" roles="tomcat,cs526prof,manager,admin"/> <user username="role1" password="xxxx" roles="role1"/> <user username="both" password="xxxx" roles="tomcat,role1"/></tomcat-users> User with Admin role can start/shutdown the Tomcat web server. User with Manage role can insert/delete web applications. User with cs526stu role can read cs526 web pages. When the user first accesses the web site, the user will be asked for the username and

password.

<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="cs526stu"/> <role rolename="softwareRequester"/> <role rolename="tomcat"/> <role rolename="cs526prof"/> <role rolename="role1"/> <role rolename="manager"/> <role rolename="admin"/> <user username="cs526stu" password="xxxx" roles="cs526stu,manager"/> <user username="softwareRequester" password="sesame" roles="softwareRequester"/> <user username="tomcat" password="xxxx" roles="tomcat"/> <user username="cs526prof" password="xxxx" roles="tomcat,cs526prof,manager,admin"/> <user username="role1" password="xxxx" roles="role1"/> <user username="both" password="xxxx" roles="tomcat,role1"/></tomcat-users> User with Admin role can start/shutdown the Tomcat web server. User with Manage role can insert/delete web applications. User with cs526stu role can read cs526 web pages. When the user first accesses the web site, the user will be asked for the username and

password.

Page 9: Design Principles for Secure Mechanisms

9cs691 chow

Mail Server Access RightsMail Server Access Rights

Mail server accepts mail from Internet and copies the msgs to a spool directory.

A local server will complete delivery. Mail server needs rights

to access network port 25, To create files in the spool directory To alter those files (copy msg to file, rewrite delivery address if

needed, incase of aliases?) It should surrender the right when finishes. It should not access the users’ files. Local server only has the read and delete access to spool direcotry. The admin should only be able to access subjects and objects

involved in mail queueing and delivery, in case it is compromised??

Mail server accepts mail from Internet and copies the msgs to a spool directory.

A local server will complete delivery. Mail server needs rights

to access network port 25, To create files in the spool directory To alter those files (copy msg to file, rewrite delivery address if

needed, incase of aliases?) It should surrender the right when finishes. It should not access the users’ files. Local server only has the read and delete access to spool direcotry. The admin should only be able to access subjects and objects

involved in mail queueing and delivery, in case it is compromised??

Page 10: Design Principles for Secure Mechanisms

10cs691 chow

Principle of Fail-Safe DefaultsPrinciple of Fail-Safe Defaults

Unless a subject is given explicit access to an object, it should be denied access to that object.

If the subject is not able to complete its action/task, it should undo those changes it made in the security state of the system before it terminates. If the program fails, the system is still safe.

What happens if the program crashes, not fails? Mail server should not write msg to a different directory

than spool (if it is full). It should just close the network connection, issue an error msg and stop.

Unless a subject is given explicit access to an object, it should be denied access to that object.

If the subject is not able to complete its action/task, it should undo those changes it made in the security state of the system before it terminates. If the program fails, the system is still safe.

What happens if the program crashes, not fails? Mail server should not write msg to a different directory

than spool (if it is full). It should just close the network connection, issue an error msg and stop.

Page 11: Design Principles for Secure Mechanisms

11cs691 chow

Principle of Economy of MechanismPrinciple of Economy of Mechanism

Security mechanisms should be as simple as possible. Fewer errors; less checking and testing Bad example: Mechanism on host A allows access

based on the ident protocol. Ident protocol sends the user name associated with a process that has a TCP connection to a remote host. A compromised host can send any identity.

Interface to other modules are particular suspect. Example of DoS attack using Finger protocol. It returns

infinite streams of characters. Client will crash.

Security mechanisms should be as simple as possible. Fewer errors; less checking and testing Bad example: Mechanism on host A allows access

based on the ident protocol. Ident protocol sends the user name associated with a process that has a TCP connection to a remote host. A compromised host can send any identity.

Interface to other modules are particular suspect. Example of DoS attack using Finger protocol. It returns

infinite streams of characters. Client will crash.

Page 12: Design Principles for Secure Mechanisms

12cs691 chow

Principle of Complete MediationPrinciple of Complete Mediation

All accesses to objects be checked to ensure that they are allowed.

Unfortunately, most OS will check the access right when the object was “open”, but will not check access right again when the client program reads. The OS cached the results of the first check.

If the owner disallows reading the file after the file descriptor is issue, the kernel will still allow the client process to read.

DNS server caches Domain name-IP address entries. The attacker can “poison” the cache with incorrect entries, a host will be routed to a spoof site.

All accesses to objects be checked to ensure that they are allowed.

Unfortunately, most OS will check the access right when the object was “open”, but will not check access right again when the client program reads. The OS cached the results of the first check.

If the owner disallows reading the file after the file descriptor is issue, the kernel will still allow the client process to read.

DNS server caches Domain name-IP address entries. The attacker can “poison” the cache with incorrect entries, a host will be routed to a spoof site.

Page 13: Design Principles for Secure Mechanisms

13cs691 chow

Principle of Open DesignPrinciple of Open Design

The security of a mechanism should not depend on the secrecy of its design or implementation.

Attack such as disassembly and analysis, dumpster-diving for source code,

Isn’t “Security through obscurity” a good principle? Example: cryptograph software, algorithms. How about proprietary softare/trade secrets? The famous Content Scramble System (CSS). 1999

break by Norway group. Plaitiff’s lawyer filed law suit containing the source code!

The security of a mechanism should not depend on the secrecy of its design or implementation.

Attack such as disassembly and analysis, dumpster-diving for source code,

Isn’t “Security through obscurity” a good principle? Example: cryptograph software, algorithms. How about proprietary softare/trade secrets? The famous Content Scramble System (CSS). 1999

break by Norway group. Plaitiff’s lawyer filed law suit containing the source code!

Page 14: Design Principles for Secure Mechanisms

14cs691 chow

Principle of Separation of PrivilegePrinciple of Separation of Privilege

A system should not grant permission based on a single condition.

Separation of duty principle. Company checks > 75K signed by two officers. Berkeley Unix allows a user to change to root if

The user knows root password.The user is in the wheel group (the group with GID

0).

A system should not grant permission based on a single condition.

Separation of duty principle. Company checks > 75K signed by two officers. Berkeley Unix allows a user to change to root if

The user knows root password.The user is in the wheel group (the group with GID

0).

Page 15: Design Principles for Secure Mechanisms

15cs691 chow

Principle of Least Common MechanismPrinciple of Least Common Mechanism

Mechanisms used to access resources should not be shared.

Virtual machie/memory concept follows this. Internet access route should not be shared? How to restrict the attackers’ access to the segment of

Internet connected to a web site? Purdue SYN intermediary system. Secure Collective Defense Project.

Mechanisms used to access resources should not be shared.

Virtual machie/memory concept follows this. Internet access route should not be shared? How to restrict the attackers’ access to the segment of

Internet connected to a web site? Purdue SYN intermediary system. Secure Collective Defense Project.

Page 16: Design Principles for Secure Mechanisms

16cs691 chow

Principle of Psychological Acceptability

Principle of Psychological Acceptability

Security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present.

Example SSH. Example: not allow access after 3 tries.

Security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present.

Example SSH. Example: not allow access after 3 tries.