CMSC 414 Computer (and Network) Security by IFY9nc7Y

VIEWS: 4 PAGES: 34

									         CMSC 414
Computer and Network Security
         Lecture 17

         Jonathan Katz
Reading on course webpage
 Buffer overflows
 Will get to it in about 2 weeks, but start reading
  now
 Will be useful for HW3
System Security
“System security”
 Several meanings of “system security” here:
   – Security of the entirety of what is being protected
   – Operating-system security
   – Host security
System security -- components
 Policy (specification)
   – What security properties to focus on
   – What is and is not allowed
 Mechanism (implementation)
  – The mechanism enforces the policy
  – Includes procedural controls, not just technical ones
       • E.g., who may enter the room where backup tapes are stored
       • How new accounts are established
   – Prevention/detection/response/recovery
 Assurance (correctness)
   – Verifying that the mechanism implements the policy
Security policy
 Formal statement of rules and practices that
  specify what a system or organization will protect,
  and how it will do so


 Useful to also specify threat model
Mechanisms for enforcing policy
 The precision of a mechanism measures how
  closely the mechanism matches the policy
   – E.g., an overly restrictive mechanism may prevent
     things that are allowed by the policy
 Hard (in general) to develop a “maximally-
  precise” mechanism for an arbitrary given policy
 Impossible (in general) to determine whether a
  given mechanism implements a given policy
 Made worse by the fact that policy is often
  specified informally to begin with
Assurance/evaluation
 The degree of confidence in the ability to carry out
  the policy
 Encompasses both design and implementation


 Evaluation
   – Examining computer/system with respect to certain
     criteria
   – Testing, formal analysis
Security Principles
General principles
 Seminal article by Saltzer and Schroeder (1975)
   – Linked from the course homepage
 Eight principles underlying design and
  implementation of security mechanisms
 These are guidelines, not hard and fast rules
 Not exhaustive
Principle 1
 “Principle of least privilege”
   – A subject should be given only the privileges it needs to
     accomplish its task
       • E.g., only allow access to information it needs
       • E.g., only allow necessary communication
   – The function of a subject (not its identity) should
     determine this
       • I.e., if a subject needs some privileges to complete a specific
         task, it should relinquish those privileges upon completion
       • If reduced privileges are sufficient for a given task, the subject
         should request only those privileges
In practice…
 There is a limit to how much granularity a system
  can handle
 Systems are often not designed with the necessary
  granularity
   – E.g., “append” may not be distinct from “write”
   – E.g., in UNIX, nothing between user and root
      • Anyone who can make backup files can also delete those files
Principle 2
 “Principle of Fail-Safe Defaults”
   – Unless a subject is given explicit access to an object, it
     should be denied access
       • I.e., the default is no access
   – More generally, in case of ambiguity the system should
     default to the more restrictive case
Principle 3
 “Economy of Mechanism”
   – Security mechanisms should be as simple as possible…
   – This applies to both the policy and the mechanism!
   – Less chance of error
   – Can simplify assurance process
 Offering too much functionality can be dangerous
  – E.g., finger protocol: cap how much information can be
    returned, or allow an arbitrary amount?
       • DoS attack by returning an infinite stream of characters
   – E.g., macros in Excel, Word
   – E.g., postscript can execute arbitrary code
Principle 4
 “Principle of Complete Mediation”
   – All accesses to objects should be checked to ensure
     they are allowed
   – OS should mediate any request to read an object ---
     even on the second such request by the same subject!
       • Don’t cache authorization results
       • Don’t rely on authentication/authorization performed by
         another module
   – Time-of-check-to-time-of-use flaws…
 Good examples: re-authentication (on websites, or
  systems) when performing sensitive tasks
Insecure example…
 In UNIX, when a process tries to read a file, the
  system checks access rights
   – If allowed, it gives the process a file descriptor
   – File descriptor is presented to OS for access
 If permissions are subsequently revoked, the
  process still has a valid file descriptor!
   – Insufficient mediation
Principle 5
 “Open Design”
   – No “security through obscurity”
   – Security of a system should not depend on the secrecy
     of its implementation
       • Of course, secret keys do not violate this principle!
Principle 6
 “Separation of Privilege”
   – (As much as is feasible…) a system should not grant
     permission based on a single condition
   – E.g., require more than one sys admin to issue a critical
     command, or more than one teller to issue an ATM card
Principle 7
 “Principle of Least Common Mechanism”
   – Minimize mechanisms depended upon by all users
      • Minimize effect of a security flaw!
   – Shared mechanisms are a potential information path,
     and so may be used to compromise security
   – Shared mechanisms also expose the system to potential
     DoS attacks
Principle 8
 “Psychological Acceptability”
   – Security mechanisms should not make access to the
     resource more difficult
   – If mechanisms are too cumbersome, they will be
     circumvented!
   – Even if they are used, they may be used incorrectly
Access control
Multi-user vs. single-user systems
 Two kinds of multi-user systems
   – Explicit awareness of other users (think unix file
     systems)
   – Users unaware of each other (think cloud computing)
   – In either case, users’ files and applications must be
     protected from illegal access by other users


 Single-user system
   – Desktop PC
   – Still don’t want one application to illegally access data /
     memory belonging to another application
Multi-user vs. single-user systems
 ‘Classical’ computing was on a multi-user system
  (time-sharing systems)
 Gradual shift to single-user systems (home PCs),
  though multi-user systems were still used in
  business, govt.
 More recently, momentum is going back to multi-
  user systems (cloud computing)
Access control
 Determining who has access to specific files, or
  other system resources



               request   reference allow/deny
     subject              monitor             object
Authentication vs. authorization
 Authentication
  – Determining the identity of a user
  – May also involve verification of IP address, machine,
    time, etc…
  – Determine whether a user is allowed to access the
    system at all
  – Used for audit, not just authorization
  – We have already covered authentication protocols
 Authorization (access control)
  – Assuming identity of user is known, determine whether
    some specific action is allowed
Design considerations
 Where to implement access control?


                     Applications
                  Services/middleware
           (DBMS*, object reference broker)
                           OS
            (file/memory management, I/O)
                         Kernel
         (mediates access to processor/memory)
                         Hardware

             *Database   management system
Design considerations
 Access control generally must be implemented in
  several layers
 For example:
   – In the OS, access control done at the granularity of
     files. But consider a (single file containing a) grades
     spreadsheet: the application will have to ensure that
     each student can only read their own grade (while the
     instructor can read and write everything)
Some terminology
 Protected entities: “objects” O
 Active objects: “subjects” S (i.e., users/processes)
  – Note that subjects can also be objects
  – Typically, each subject associated with some
    principal/owner
 Subjects/objects can be:
   – Users
   – Files
   – Processes
   – System resources (servers, printers, etc.)
Access control matrix
 Matrix indexed by all subjects and objects
  – Characterizes rights of each subject with respect to each
    object
 Formally: set of objects O and subjects S, set of
  possible rights
 Matrix A with subjects labeling the rows and
  objects labeling the columns
   – The entry (s, o) contains the rights for s on o
   – Examples: read/write/execute/etc.
Example
                                   Objects

                    File 1   File 2    File 3    …    File n

           User 1   {r,w}    {w}                      {r,w}

           User 2   {w}      {w}       {r,w}
Subjects
           User 3                               {r}   {w}

           …

           User k   {r}      {r}       {r,w}    {r}   {w}
Access control matrix
 The access control matrix provides a useful way to
  think about the rights in the system
 It can also be a way to implement access control


                request   reference allow/deny
      subject              monitor             object
More complex access control
 In general, “rights” may be functions
   – “Actual” rights depend on the system state
   – Equivalently, may depend on system history


 Rights can form hierarchies
  – E.g., right X implies right Y
Granularity
 Granularity is an issue at the level of subjects,
  objects, and rights
 In theory, arbitrary level of granularity, e.g.,
   – Subjects: functions within processes
   – Objects: characters within files
   – Rights: write, append, increment-only, …
 In practice, a decision must be made as to the level
  of granularity that will be supported
Granularity
 Trade-off is obvious:
   – Fine-grained access control gives “better security”
      • Least privilege
   – Coarse-grained access control more efficient

								
To top