Chapter 14: ProtectionChapter 14: ProtectionObjectivesBackgroundGoals of ProtectionPolicy and Implementation - 1Policy and Implementation - 2Principles of ProtectionPrinciples of Protection - 2Domain of ProtectionDomain StructureDomain Structure – generic sampleStatic and Dynamic AssociationsSlide 14DomainsCommentDomain Implementation (UNIX)Slide 18Access MatrixSlide 20Implementation of Access MatrixSlide 22Use of Access Matrix (Cont.)Access Matrix With Domains as ObjectsUse of Access MatrixAccess Matrix with Copy RightsAccess Matrix With Owner RightsDomain ChangesSlide 29Slide 30End of Chapter 14.1Chapter 14: ProtectionChapter 14: Protection14.2Silberschatz, Galvin and Gagne ©2005Operating System ConceptsChapter 14: ProtectionChapter 14: ProtectionChapter 14.1Goals of Protection Principles of ProtectionDomain of Protection Access Matrix Chapter 14.2Implementation of Access Matrix Access ControlRevocation of Access Rights Capability-Based Systems Language-Based Protection14.3Silberschatz, Galvin and Gagne ©2005Operating System ConceptsObjectivesObjectivesDiscuss the goals and principles of protection in a modern computer systemExplain how protection domains combined with an access matrix are used to specify the resources a process may accessExamine language-based protection systems14.4Silberschatz, Galvin and Gagne ©2005Operating System ConceptsBackgroundBackgroundProtection and Security are related yet very different topics.We will devote a chapter to each.Protection requires two things: A Policy – what it is we want, and Implementation mechanisms – how we are going to do it.Protection is a measure of confidence that the integrity of a system and its data will be preserved.Security assurance is a much broader topic and we will cover it next chapter.One may view Protection as some kind of mechanism for controlling access of programs, processes, or users to resources defined by a computer system – perhaps system resources; perhaps user resources.The mechanism for implementing these controls must be specified. And there must also be a means of enforcement and not simply policy.14.5Silberschatz, Galvin and Gagne ©2005Operating System ConceptsGoals of ProtectionGoals of ProtectionWe know that operating systems consist of large collections of objects, hardware and softwareAll users of such a computer system share these same resources.Clearly, we need to protect these shared resources from intentional or accidental activities which may prove to be disastrous.Since all these resources are shared, we definitely need policies to govern and control appropriate access.Specifically, policies need to define authorized and unauthorized access.14.6Silberschatz, Galvin and Gagne ©2005Operating System ConceptsPolicy and Implementation - 1Policy and Implementation - 1Policies may be fixed in the design of the computing system Other policies may be developed by management of the computing system.Still other policies may be implemented by users themselves to protect their own files and programs. Thus a protection system must include the ability to enforce a number of different policies.Operating system designers can implement protection mechanisms as integral parts of the OS (a protection kernel perhaps).Application develops may also develop protection mechanism and in some cases these desires are supported by their choice of programming language.While these will clearly differ in scope and extent, both are needed.We now define an object as a unique name that can be accessed through a well-defined set of operations.So, the protection problem is to ensure that each object is accessed correctly and only by those processes allowed to do so.14.7Silberschatz, Galvin and Gagne ©2005Operating System ConceptsPolicy and Implementation - 2Policy and Implementation - 2In this chapter, we will emphasize what an operating system can/should provide.Using these facilities, an application developer may then select some of his/her own protection approaches, as mentioned.Note that having mechanisms – ‘how’ something will be done, differs markedly from policies, which address ‘what’ will be done.Policies can change from time to time. Conceivably, policy changes may result in changes to underlying mechanisms.This is always the way things are done:The ‘what’ followed by the ‘how.’Clearly related, but vastly different!14.8Silberschatz, Galvin and Gagne ©2005Operating System ConceptsPrinciples of ProtectionPrinciples of ProtectionThe criterion that is used to guide design and implementation issues for protection is the principle of least privilege.Basically, this principle says that ‘one’ should have enough privileges to do what one needs to do but nothing more!One of the advantages of this approach is that if a system, program, user, etc. fails, the results of this failure should not propagate into other areas – or at least cause ‘minimal’ damage to others. As a user, if my process fails due to an attempt, say, to execute privileged instructions or access areas not allowed, the results should be localized to this process and this user – nothing else!At the user level, users are given permission / privileges users need and users are given access to those commands that a user needs. That’s it!Computers, running under the principle of least privilege, may be limited to running only certain devices, being able to access only specific remote services, etc, and may be constrained to these devices or services at othr times.14.9Silberschatz, Galvin and Gagne ©2005Operating System ConceptsPrinciples of Protection - 2While such a philosophy might appear noble and ‘should work for the benefit of all, at least in principle (no pun intended), this principle is implemented in significantly different ways to vastly different degrees as found in very different operating systems.Let’s now look at the Domain of Protection.14.10Silberschatz, Galvin and Gagne ©2005Operating System ConceptsDomain of ProtectionIn order to attempt to implement a protection scheme, let’s first look at what we are protecting.First of all, we have hardware objects – CPU, memory segments, printers, disks, etc. We have software objects – file, programs, software switches, …Some measures that may be implemented on