Title: Design Principles for Secure Mechanisms
1Design Principles for Secure Mechanisms
C. Edward Chow
CS591 Chapter 5.4 Trusted OS DesignCS691
Chapter 13 of Matt Bishop
2Design 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
3Overview
- 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.
4Examples
- 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!
5Example for Avoiding Inconsistency in Policies
- Policy rule1 TA needs any cheating.
- Policy rule2 ensure the privacy of student
files. - Case
- TA reminds student file not submitted.
- Student ask TA to look for files in students
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.
6Examples 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.
7Principle 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, subjects
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?
8Example of Tomcat User Access Control Files
- lt?xml version'1.0' encoding'utf-8'?gt
- lttomcat-usersgt
- ltrole rolename"cs526stu"/gt
- ltrole rolename"softwareRequester"/gt
- ltrole rolename"tomcat"/gt
- ltrole rolename"cs526prof"/gt
- ltrole rolename"role1"/gt
- ltrole rolename"manager"/gt
- ltrole rolename"admin"/gt
- ltuser username"cs526stu" password"xxxx"
roles"cs526stu,manager"/gt - ltuser username"softwareRequester"
password"sesame" roles"softwareRequester"/gt - ltuser username"tomcat" password"xxxx"
roles"tomcat"/gt - ltuser username"cs526prof" password"xxxx"
roles"tomcat,cs526prof,manager,admin"/gt - ltuser username"role1" password"xxxx"
roles"role1"/gt - ltuser username"both" password"xxxx"
roles"tomcat,role1"/gt - lt/tomcat-usersgt
- 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.
9Mail 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??
10Principle 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.
11Principle 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.
12Principle 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.
13Principle 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, - Isnt 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. Plaitiffs lawyer filed
law suit containing the source code!
14Principle of Separation of Privilege
- A system should not grant permission based on a
single condition. - Separation of duty principle.
- Company checks gt 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).
15Principle 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.
16Principle 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.