More on Access Control
Upcoming SlideShare
Loading in...5

More on Access Control






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

More on Access Control More on Access Control Presentation Transcript

  • INLS 566 September 18, 2007 More on Access Control
  • Housekeeping  Book Review due today (midnight) – Web: send me URL, username, password – Email: send me attachment  Password attack: – Let Google do your password guessing   Any questions about material so far?  Interesting security news? (5 min)
  • Access Basics Identification – On whose behalf are we acting? Authentication – Are we sufficiently sure of this? Authorization – What they may, and may not do
  • Authorization  Usually need at least a way to prevent users from accidentally changing system configuration  File permissions is very simple example, based only on identity  Many other models (e.g., MAC)
  • Pop Quiz  UNC requires any device attached to the campus Ethernet network to have its MAC address associated with an ONYEN. Is this: – An identification policy? – An authentication policy? – An authorization or access control policy? – Some other kind of policy?
  • Authority & Privilege  Authority (aka Authorization) – Set of all things you‟re allowed to do  All your read/write/etc. permissions  All programs you‟re allowed to run  All resources you‟re allowed to consume  Etc. …  Privilege – Special handling of high risk operations  Administration  System internals  Sensitive programs
  • Related UNIX Ideas  If the setUID / setGID attribute is set on a program file, that program runs with the specified user/group ID – If setUID root, runs with all privileges – If setUID / setGID non-root, can use the files accessible by that user/group ID  E.g., „mail‟ program typically setGID mail  Your mailbox typically allows r/w by group mail  The „mail‟ program can write to your mailbox  chroot – sandbox (hard to administer)  Mount w/ restrictions (r/o, no setUID)
  • Windows™ vs. UNIX  Windows “user rights” – via Windows groups (different from UNIX groups) – User – Power user (obselete as of Vista?) – Administrator  UNIX “normal user” (except UID = 0) – User‟s file permissions – Plus group‟s file permissions  UNIX root user (UID = 0) – All privileges (almost)
  • Privilege as Risk  Privilege attacks – High privilege = high value target – Privilege escalation  Unprivileged user attacks system process  Privilege defenses – High privilege => more protection – Minimize use of Privilege  Principle of Least Privilege
  • Least Privilege  Static model – Run with fewest privileges possible  E.g., user mail instead of user root  Dynamic model – Drop all privilege at start of program – Assert privilege only when necessary – Drop privilege immediately afterward – Continue until privilege needed again – (E.g., switch to root & back to other)
  • User Account Control(Vista) Pic thanks to Alex Fox  A form of dynamic Least Privilege: – Asks permission – Asserts privilege (if you say yes) – Does the sensitive task – Drops privilege (until next time)
  • Major Access Control Models  Discretionary access control (DAC) – owner sets access  Mandatoryaccess control (MAC) – Admin sets access (user can not change it)
  • Discretionary Access Control  Owner may change permissions – we‟re familiar with this model from using Windows and UNIX: – Windows Properties -> Security – UNIX chmod, chgrp , and chown
  • Mandatory Access Control (MAC)  Literally: administrator (not the user) controls access rules for every object  Conventional usage: – Originally intended for military secrets – Bell - La Padula access control model – Admin controls Bell - La Padula access – There may be additional controls, some or all of which may be discretionary
  • Bell - La Padula Model  Abstraction of secret, top secret, etc. – Lower level information may be read by higher level user, but not vice versa – Lower level information may be written to higher level object, but not vice versa  Assumes mandatory access control – (Doesn‟t make sense if user can change)  Details can be a bit more complex – Categories in addition to levels (lattice)
  • Non-Military MAC  Administrator controls access rules – E.g., parental controls  Need not use Bell - La Padula model – E.g., Security Enhanced Linux  Applicable to business requirements? – Investment banking (insider info) – Health care (HIPAA) – Etc.
  • Why Talk About This? A security policy specifies what should and should not happen  The security mechanisms of each system make it happen (or not)  Knowing how the tools work may influence design of your policies (or vice versa, but expensive)
  • Suggested Reading  Schneier: – ch. 11-12 (pp. 147-180)  Dhillon: – ch. 5 (pp. 64-93)  McClure: – ch. 7 (pp. 352-405) – ch. 9 (pp. 464-485)