Operating system vs network security l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

Operating System vs. Network Security PowerPoint PPT Presentation


  • 139 Views
  • Updated On :
  • Presentation posted in: General

Operating System vs. Network Security. Butler Lampson Microsoft. Outline What security is about Operating systems security Network security How they fit together. Security: The Goal. People believe that computers are as secure as real world systems, and it’s true. This is hard because:

Download Presentation

Operating System vs. Network Security

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Operating system vs network security l.jpg

Operating System vs. Network Security

Butler Lampson

Microsoft

  • Outline

    • What security is about

    • Operating systems security

    • Network security

    • How they fit together


Security the goal l.jpg

Security: The Goal

  • People believe that computers are as secure as real world systems, and it’s true.

  • This is hard because:

    • People don’t trust new things.

    • Computers can do a lot of damage fast.

    • There are many places for things to go wrong.

    • Anonymous attacks are easy across a network.


Real world security l.jpg

Real-World Security

  • It’s about value, locks, and police.

    • Good enough locks that bad guys don’t break in very often.

    • Good enough police and courts that bad guys that do break in get caught and punished often enough.

    • As little interference with daily life as possible, consistent with these two points.


Dangers l.jpg

Dangers

  • Vandalism or sabotage that

    • damages information

    • disrupts service

      Theft of money

      Theft of information

      Loss of privacy

      Secrecy, integrity, and availability


Vulnerabilities l.jpg

Vulnerabilities

  • Bad (buggy or hostile) programs

  • Bad (careless or hostile) people giving instructions to good programs

  • Bad guy tapping or interfering with communications


Defensive strategies l.jpg

Defensive strategies

  • Keep everybody out

    • Isolation

  • Keep the bad guy out

    • Code signing, firewalls

  • Let him in, but keep him from doing damage

    • Sandboxing, access control

  • Catch him and prosecute him

    • Auditing, police


The access control model l.jpg

The Access Control Model

  • Guards control access to valued resources.

Do

Reference

Object

Principal

operation

monitor

Request

Guard

Source

Resource


Mechanisms l.jpg

Mechanisms

Authenticating principals

  • Mainly people, but also machines, programs

    Authorizing access.

  • Usually for groups of principals

    Auditing

  • Trusted computing base


  • Levels of security l.jpg

    Levels of Security

    • Network, with a firewall

    • Operating system, with sandboxing

      • Basic OS (such as NT)

      • Higher-level OS (such as Java)

    • Application that checks authorization directly

    • All need authentication


    Why we don t have real security l.jpg

    Why We Don’t Have “Real” Security

    • People don’t buy it

      • Danger is small, so people buy features insteadSecure systems do less because they’re older

      • Security is a pain

        • It has to be configured correctly

        • Users have to authenticate themselves

    • Systems are complicated, so they have bugs.


    Operating system security l.jpg

    Operating System Security

    • Assume secure channel from user

    • Authenticate user by local password

    • Map user to her SID + group SIDs

      • Local database for group memberships

    • Access control by ACL on each resource

      • OS kernel is usually the reference monitor

      • Any RPC target can read SIDs of its caller

    • ACLs are lists of SIDs

      • A program has SIDs of its logged in user


    Nt domain security l.jpg

    NT Domain Security

    • Just like OS except for authentication

    • OS does RPC to domain for authentication

      • Secure channel to domain

      • Just do RPC(user, password) to get user’s SIDs

    • Domain may do RPC to foreign domain

      • Pairwise trust and pairkwise secure channels

      • SIDs include domain ID


    Distributed systems are different l.jpg

    Distributed Systems Are Different

    • Big

    • Heterogeneous and autonomous parts

      • In equipment

      • In management

    • Fault tolerant

      • Partly broken but still working

    • All these make authentication harder


    Web server security today l.jpg

    Web Server Security Today

    • Simplified from single OS

      • (Establish secure channel with SSL)

      • Authenticate user by local password

        • (or by local certificate)

      • Usually ACL only on right to enter

      • Map user to her private state


    Web browser security today l.jpg

    Web Browser Security Today

    • Authenticate server by DNS lookup (?)

      • (Authenticate server by SSL + certificate)

    • Authenticate programs by signature

      • Good programs run as user

      • Bad programs rejected, or totally sandboxed


    Principals l.jpg

    Principals

    • Authentication:Who sent a message?

    • Authorization:Who is trusted?

    • Principal — abstraction of "who":

      • PeopleLampson, Gray

      • MachinesSN12672948, Jumbo

      • Servicesmicrosoft.com, Exchange

      • GroupsUW-CS, MS-Employees


    What principals do l.jpg

    What Principals Do

    • Principal says statement

      • Lampson says “read /MSR/Lampson/foo”

      • Microsoft-CA says “Lampson's key is #7438”


    Secure channel l.jpg

    Secure Channel

    • Says things directlyCsayss

    • Has knownpossible receiverssecrecy

    • possible sendersintegrity

    • Examples

      • Within a node: operating system (pipes, etc.)

      • Between nodes:

        • Secure wiredifficult to implement

        • Network fantasy for most networks

        • Encryptionpractical


    Speaks for l.jpg

    Speaks For

    • Principal A speaks for B: AÞ B

      • Meaning: if A says something, B says it too.

        • Thus A is stronger than B.

      • Examples

        • Lampson ÞMSR

        • Server-1 ÞMSR-NFS

        • Key #7438 ÞLampson

    • Handoff rule: If A says BÞA then BÞA

      • Reasonable if A is competent and accessible.


    Secure channels via encryption l.jpg

    Secure Channels via Encryption

    • The channel is defined by the key:

      • If only A knows K–1, then KÞA.

    • Ksayss is a message which K can decrypt.


    Authorization with acls l.jpg

    Authorization with ACLs

    • Access control lists (ACLs)

      • An object O has an ACL that says: principal P may access O.

        • Lampson may read and write O

        • MSR may append to O

    • ACLs must use names for principals

      • so that people can read them.


    Names and name spaces sdsi spki l.jpg

    Names and Name Spaces: SDSI/SPKI

    • A name is local to some name space

    • A name space is defined by a key

    • The key can bind names in its name space

      • KmicrosoftsaysKbwlÞKmicrosoft / Lampson

      • These certificates are public

    • Path names can start from anywhere

      • Kmicrosoft / Lampson / friends

      • Klampson / friends


    Authenticating a channel l.jpg

    Authenticating a Channel

    • Who can send on a channel?

      • CÞP; C is the channel, P the sender.

    • To get this, must trust some principal Kca that “owns” P.

    • Then Kca can authenticate channels from P:

      • KcasaysKwsÞKca / WS

      • KcasaysKbwlÞKca / Lampson

    • Anyone can use these certificates


    Checking access l.jpg

    Checking Access

    • Givena requestQsaysread Oan ACLP may read/write OPÞread/writeO

    • Check thatQ speaks for PQÞPrights are enoughread/writereadQÞP Þread/writeO

    • henceQÞread/writeO


    What about os l.jpg

    What about OS?

    • (1) Put network principals on OS ACLs

    • (2) Let network principal speak for local one

      • [email protected] Þ Redmond\rivest

      • Use network authentication

        • replacing domain authentication

      • Users and ACLs stay the same

    • (3) Assign SIDs to network principals

      • Do this automatically

      • Use network authentication as before


    Groups and group credentials l.jpg

    Groups and Group Credentials

    • A group is a principal; its members speak for it

      • LampsonÞ MSR

      • RashidÞ MSR

      • . . .

    • Proving group membership: Use certificates.

      • KmsrsaysLampson ÞKmsr / MSR

    • These certificates are public too


    Authenticating systems l.jpg

    Authenticating Systems

    • A machine can store its own secret key

    • A program can be authenticated by a digest:

      • Kcasays “If I has digest X then I is program P”formallyXÞP

    • A system can speak for another system:

      • KcasaysNÞP

    • The first certificate makes N want to run I

    • The second certificate lets N convince others that N is authorized to run P


    Auditing l.jpg

    Auditing

    • Checking access:

      • Givena requestQsaysread Oan ACLP may read/write O

      • Check thatQ speaks for PQÞPrights sufficeread/writeread

    • Auditing

      • Each step is justified by

        • a signed statement (certificate), or

        • a rule


    Implement tools and assurance l.jpg

    Implement: Tools and Assurance

    • Services — tools for implementation

      • AuthenticationWho said it?

      • AuthorizationWho is trusted?

      • Auditing What happened?

    • Trusted computing base

      • Keep it small and simple.

      • Validate each component carefully.


    References l.jpg

    References

    • Why “real” security is hard

      • www.cl.cam.ac.uk/users/rja14

    • Distributed system security

      • Lampson et al. TOCS10, 4 (Nov. 1992)

      • Wobber et al. TOCS12, 1 (Feb. 1994)

    • Simple Distributed Security Infrastructure (SDSI)

      • theory.lcs.mit.edu/~cis/sdsi.html

    • Simple Public Key Infrastructure (SPKI)

      • ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-structure-02.txt


  • Login