C. Edward Chow - PowerPoint Presentation

Slide1

C. Edward ChowPresented byMousa Alhazzazimalhazza@kent.edu

Design Principles for Secure Mechanisms

BySlide2

Design Principles for Security MechanismsBased on the ideas of simplicity and restriction.J. Saltzer and M. Schroeder Proceedings of IEEE 1975 describes 8 principles for security mechanismLeast PrivilegesFail-Safe DefaultsEconomy of MechanismComplete MediationOpen DesignSeparation of PrivilegeLeast Common MechanismPsychological AcceptabilitySlide3

OverviewSimplicity 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.Slide4

ExamplesSendmail 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 compiles (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 recheck the parameters in the 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!Slide5

Example for Avoiding Inconsistency in PoliciesPolicy rule1: TA needs to report any cheating.Policy rule2: ensure the privacy of student files.Case: TA reminds student that the file was not submitted.Student asks the TA to look for files in the student’s directory.TA finds two files. Unsure about which files.TA reads the first file, it turns out to be written by other student.TA reads the 2nd file, it turns out to be identical except for names.TA reports the cheating.Student charges TA with violating his privacy by reading the first set of files.Slide6

Principle of Least PrivilegeA subject should be given only those privileges that it needs in order to complete its task.Exception case: for certain actions, a subject’s access right can be augmented but relinquished immediately on completion of the action.In practice, most systems do not have the granularity of privileges and permissions required to apply this principle precisely. The designers of mechanisms try to do their best.Slide7

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

Manager

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

.Slide8

Mail Server Access RightsMail 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 directoryTo alter those files (copy msg to file, rewrite delivery address if needed)It should surrender the right when finished.It should not access the users’ files.Local server only has read and delete access to the spool directory.The admin should only be able to access subjects and objects involved in mail queuing and delivery.Slide9

Principle of Fail-Safe DefaultsUnless 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. 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.Slide10

Principle of Economy of MechanismSecurity mechanisms should be as simple as possible.Fewer errors; less checking and testingBad 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.Slide11

Principle of Complete MediationAll accesses to objectsshould be checked to ensure that they are allowed.Unfortunately, most OS will check the access right when the object was “open”ed, 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 issued, the kernel will still allow the client process to read.Slide12

Principle of Open DesignThe security of a mechanism should not depend on the secrecy of its design or implementation.Attacks such as disassembly and analysis, dumpster-diving for source code.To Avoid this we use cryptograph software, algorithms. Should be open for scrutiny by the communitySlide13

Principle of Separation of PrivilegeA system should not grant permission based on a single condition.Access to objects should depend on more than one condition being satisfiedSeparation of duty principle. example: Berkeley Unix allows a user to change to root if The user knows root password and user is in the wheel group .Slide14

Principle of Least Common MechanismMinimize the amount of mechanism common to more than one user and depended on by all users Every shared mechanism is a potential information pathMechanisms used to access resources should not be shared.Virtual machine/memory concept follows this.How to restrict the attackers’ access to the segment of Internet connected to a web site?Purdue SYN intermediary system.Secure Collective Defense Project.Slide15

Principle of Psychological AcceptabilitySecurity mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. User interface must be easy to use, so that users routinely and automatically apply the mechanisms correctly. Otherwise, they will be bypassed Security mechanisms should not add to difficulty of accessing resourceExample SSH. This does not allow access after 3 tries.Slide16

Thank you !Questions ?