Lecture2–MultilevelSecurity详解.pptVIP

Lecture 2 – Multilevel Security Security Computer Science Tripos part 2 Ross Anderson Context of Multilevel Security Hierarchy: Top Secret, Secret, Confidential, … Information mustn’t leak from High down to Low Enforcement must be independent of user actions! Perpetual problem: careless staff 1970s worry: operating system insecurity 1990s worry: virus at Low copies itself to High and starts signalling down (e.g. covert channel) Context of Multilevel Security (2) Nowadays: see our paper ‘The Snooping Dragon’ September 2008: Dalai Lama’s office realised there had been a security failure Initial break: targeted email with bad pdf Then: took over the mail server and spread it About 35 or their 50 PCs were infected Fix (Dharamsala): take ‘Secret’ stuff offline Fix (UKUSA agencies): use MLS mail guards and firewalls to prevent ‘Secret’ stuff getting out Formalising the Policy Bell-LaPadula (1973): simple security policy: no read up *-policy: no write down With these, one can prove that a system which starts in a secure state will remain in one Ideal: minimise the Trusted Computing Base (set of hardware, software and procedures that can break the security policy) so it’s verifiable 1970s idea: use a reference monitor Objections to BLP Some processes, such as memory management, need to read and write at all levels Fix: put them in the trusted computing base Consequence: once you put in all the stuff a real system needs (backup, recovery, comms, …) the TCB is no longer small enough to be easily verifiable Objections to BLP (2) John MacLean’s “System Z”: as BLP but lets users request temporary declassification of any file Fix: add tranquility principles Strong tranquility: labels never change Weak tranquility: they don’t change in such a way as to break the security policy Usual choice: weak tranquility using the “high watermark principle” – a process acquires the highest label of any resource it’s touched Problem: have to rewrite apps (e.g. license server) Covert Channels I