
bb55da563009b35a1f18623e55847fe9.ppt
- Количество слайдов: 30
Operating System vs. Network Security Butler Lampson Microsoft Outline – What security is about – Operating systems security – Network security – How they fit together 1
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. 2
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. 3
Dangers Vandalism or sabotage that – damages information – disrupts service Theft of money Theft of information Loss of privacy Secrecy, integrity, and availability 4
Vulnerabilities Bad (buggy or hostile) programs Bad (careless or hostile) people giving instructions to good programs Bad guy tapping or interfering with communications 5
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 6
The Access Control Model Guards control access to valued resources. Principal Do operation Reference monitor Object Source Request Guard Resource 7
Mechanisms Authenticating principals - Mainly people, but also machines, programs Authorizing access. - Usually for groups of principals Auditing Trusted computing base 8
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 9
Why We Don’t Have “Real” Security People don’t buy it – Danger is small, so people buy features instead Secure 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. 10
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 11
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 12
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 13
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 14
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 15
Principals Authentication: Who sent a message? Authorization: Who is trusted? Principal — abstraction of "who": – People – Machines – Services – Groups Lampson, Gray SN 12672948, Jumbo microsoft. com, Exchange UW-CS, MS-Employees 16
What Principals Do Principal says statement – Lampson says “read /MSR/Lampson/foo” – Microsoft-CA says “Lampson's key is #7438” 17
Secure Channel Says things directly C says s Has known possible receivers secrecy possible senders integrity Examples – Within a node: operating system (pipes, etc. ) – Between nodes: » Secure wire difficult to implement » Network fantasy for most networks » Encryption practical 18
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 » Server-1 » Key #7438 Þ MSR-NFS Þ Lampson Handoff rule: If A says B Þ A then B Þ A – Reasonable if A is competent and accessible. 19
Secure Channels via Encryption The channel is defined by the key: – If only A knows K– 1, then K Þ A. K says s is a message which K can decrypt. 20
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. 21
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 – Kmicrosoft says Kbwl Þ Kmicrosoft / Lampson – These certificates are public Path names can start from anywhere – Kmicrosoft / Lampson / friends – Klampson / friends 22
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: – Kca says Kws Þ Kca / WS – Kca says Kbwl Þ Kca / Lampson Anyone can use these certificates 23
Checking Access Given a request Q says read O an ACL P may read/write O P Þread/write O Check that Q speaks for P Q Þ P rights are enough read/write read hence Q Þ P Þread/write O Q Þread/write O 24
What about OS? (1) Put network principals on OS ACLs (2) Let network principal speak for local one – Rivest@lcs. mit. edu Þ Redmondrivest – 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 25
Groups and Group Credentials A group is a principal; its members speak for it – Lampson – Rashid –. . . Þ MSR Proving group membership: Use certificates. – Kmsr says Lampson Þ Kmsr / MSR These certificates are public too 26
Authenticating Systems A machine can store its own secret key A program can be authenticated by a digest: – Kca says formally “If I has digest X then I is program P” XÞP A system can speak for another system: – Kca says NÞP The first certificate makes N want to run I The second certificate lets N convince others that N is authorized to run P 27
Auditing Checking access: – Given a request Q says read O an ACL P may read/write O – Check that Q speaks for P QÞP rights suffice read/write read Auditing – Each step is justified by » a signed statement (certificate), or » a rule 28
Implement: Tools and Assurance Services — tools for implementation – Authentication Who said it? – Authorization Who is trusted? – Auditing What happened? Trusted computing base – Keep it small and simple. – Validate each component carefully. 29
References Why “real” security is hard – www. cl. cam. ac. uk/users/rja 14 Distributed system security – Lampson et al. TOCS 10, 4 (Nov. 1992) – Wobber et al. TOCS 12, 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 30
bb55da563009b35a1f18623e55847fe9.ppt