More on Access Control

343 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
343
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

More on Access Control

  1. 1. INLS 566 September 18, 2007 More on Access Control
  2. 2. 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)
  3. 3. Access Basics Identification – On whose behalf are we acting? Authentication – Are we sufficiently sure of this? Authorization – What they may, and may not do
  4. 4. 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)
  5. 5. 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?
  6. 6. 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
  7. 7. 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)
  8. 8. 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)
  9. 9. 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
  10. 10. 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)
  11. 11. 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)
  12. 12. Major Access Control Models  Discretionary access control (DAC) – owner sets access  Mandatoryaccess control (MAC) – Admin sets access (user can not change it)
  13. 13. 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
  14. 14. 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
  15. 15. 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)
  16. 16. 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.
  17. 17. 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)
  18. 18. 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)

×