So far ... Faculty of Computer Science Institute for System Architecture, Operating Systems Group • Basics • Device Drivers • Real time • Naming Secure Systems • Resource Management Stefan Kalkowski • Virtualization / Legacy Container • Secure Systems Dresden, 2008-01-08 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 2 von 39 Outline • Secure Systems: ● Detailed example: Mikro-SINA ● Definitions ● Security policies Mikro-SINA ● Bastei's stacked policies ● Overlay window management ● Demo TU Dresden, 2008-01-08 MOS - Secure Systems Slide 3 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 4 von 39 Secure Internet Network Architecture SINA Box • VPN based security architecture by 'Bundes- • Minimized & hardened Linux amt für Sicherheit in der Informationstechnik' • IPSec and PKI • Intrusion detection & response • Complex real world scenario TU Dresden, 2008-01-08 MOS - Secure Systems Slide 5 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 6 von 39
Linux complexity Project Mikro-SINA • Linux is complex! • Goals: ● Reduce Trusted Computing Base of VPN • SLOC for kernel 2.6.18 gateway ● All: 4.983.723 ● Enable high level evaluation (e.g.: Common ● Architecture specific: 817.880 Criteria) ● x86 specific: 55.463 • Objectives: ● Driver code: 2.365.256 ● Confidentiality and integrity of sensitive ● Common: 1.800.587 network data inside the VPN • Running kernel > 2 millions lines of code • Exploit microkernel features • Minimized & hardened version > 500.000 LOC TU Dresden, 2008-01-08 MOS - Secure Systems Slide 7 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 8 von 39 IPSec – the heart of VPN security Easy approach • IPSec is a protocol suite for securing the • Use paravirtualized L4Linux as a tool Internet protocol • Identify the security relevant parts in the • Authentication header insecure application and separate them ● Guarantees integrity Application • 'Viaduct' is used for authentication, key and authentication management and en- and decryption TCP/UDP • Encapsulating Security L 4 Linux L 4 Linux Payload IP ● Also confidentiality TCP/IP IPSec TCP/IP „Viaduct“ • Two different modes IPSec IPSec ● Tunnel vs. transport Data Link Layer Fiasco Fiasco TU Dresden, 2008-01-08 MOS - Secure Systems Slide 9 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 10 von 39 Viaduct in details Fragmentation of IP packets • IP packets must be passed to the Viaduct • Encrypted IP packets get fragmented ● Use TUN/TAP driver in Linux to tunnel IP ● Problem for decryption • IP packets have to be unfragmented before they are passed to the Viaduct L 4 Linux TCP/IP μ-SINA μ-SINA Viaduct Gateway Gateway IP router IP router L4Linux Viaduct L4Linux Viaduct eth0 l4tun0 Fiasco TU Dresden, 2008-01-08 MOS - Secure Systems Slide 11 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 12 von 39
Let Linux do the dirty work ... What about confidentiality? • Register new transport protocol • L4Linux is untrusted ● but handles encrypted and unencrypted data • IP stack will unfragment IP packets • Use a second L4Linux instance ● Each L4Linux instance drives its own ethernet L 4 Linux card exclusively AH/ESP TCP/IP Viaduct Internet LAN Viaduct L 4 Linux L 4 Linux eth0 l4tun0 eth0 eth1 Fiasco Fiasco TU Dresden, 2008-01-08 MOS - Secure Systems Slide 13 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 14 von 39 Mikro-SINA so far Mikro-SINA: Multi Level Security • 'Outer' L4Linux instance handles encrypted • Different security levels for data from different data only organizational levels • 'Inner' L4Linux instance handles unencrypted • Use an own L4Linux instance for each level, data and cannot communicate to the other that handle the unencrypted data instance or the 'outgoing' network device L 4 Linux Internet Viaduct LAN L 4 Linux L 4 Linux L 4 Linux Viaduct L 4 Linux L 4 Linux eth0 eth1 eth0 Fiasco Fiasco TU Dresden, 2008-01-08 MOS - Secure Systems Slide 15 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 16 von 39 Reduce untrusted code size Techniques • Do we need two L4Linux instances for a VPN • Fine grained isolation Microkernel feature gateway? Linux user level, process management, Enables implementation of principle of least scheduling, file systems etc. are not necessary privilege • Use FLIPS (Flexible IP Stack): standalone • Minimize complexity of TCB for security TCP/IP stack relevant code Split applications in security relevant and nonrelevant parts Viaduct Use trusted wrappers (e.g.: Viaduct) FLIPS FLIPS Minimize common code (microkernel approach) eth0 eth1 • Usage of legacy code Fiasco TU Dresden, 2008-01-08 MOS - Secure Systems Slide 17 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 18 von 39
Nizza - security architecture • Beyond Mikro-SINA: greater vision Nizza Terms & Models Common secure platform TU Dresden, 2008-01-08 MOS - Secure Systems Slide 19 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 20 von 39 Secure system Policy and Mechanism Secure System * : Security Policy: A secure system is a system that starts in an A security policy is a statement of what is, and authorized state and cannot enter an what is not allowed. e.g.: SELinux policy, pagetable, /etc/passwd unauthorized state. Security Policy * : Security Mechanism: A security policy is a statement that partitions A security mechanism is a method, tool, or the states of the system into a set of procedure for enforcing a security policy authorized, or secure, states and a set of e.g.: Capabilities, paging hardware unauthorized, or nonsecure, states. * Matt Bishop: Computer Security – Art and Science TU Dresden, 2008-01-08 MOS - Secure Systems Slide 21 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 22 von 39 Formal security model: Bell-LaPadula Formal security model: Bell-LaPadula • Subjects and objects have a security label , • Example: Label L 1 : (Topsecret, {National}) consisting of a security level and category set dominates L 2 (Secret, {}) • A security label dominates another one, if its • Simple Security Condition: S can read O if S security level is greater or equal than the dominates O (no reads up) other one and its category set is a superset of • *-Property: S can write to O if and only if O the other one dominates S (no writes down) Top Secret {National,Foreign} Secret {National} {Foreign} Confidential {} Unclassified TU Dresden, 2008-01-08 MOS - Secure Systems Slide 23 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 24 von 39
Bell-LaPadula summary More flexible security models • Information flow policy, that preserves • Type Enforcement Subjects and objects have types confidentiality Types can be compounded to other types • Very simple model, proof of model's security Explicit rules state what types can access properties is also trivial (read, write) what other types • No integrity concerns in the model (use Biba) • Very general model • Problem: information flows only in one • In general: its more hard to prove specific direction security properties in such a policy A lot of underlying system software (e.g. device drivers) has to be used by all different • SELinux is an example for TE in practice security levels Mostly these parts are excluded from the model TU Dresden, 2008-01-08 MOS - Secure Systems Slide 25 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 26 von 39 SELinux Decompose security policies • Developed by the NSA • Szenario: Content Management System + typical web services • Based on Linux Security Modules (LSM) TCP/IP User User Web • Linux functionality leads to complex security Document Passwd SSL Stack Alice Bob Getty Store Auth Auth policy • Standard (NSA) policy Content Ethernet Intel 100 TPM 1000 Card Pro System over 300 domains TCP/IP Mailserver Webserver DNS ~ 50.000 rules Stack PCI Host LPC ATA Driver Controller Controller Tools might help to keep the overview Audit DMZ • Problem: monolithic kernel leads to monolithic Device Manager reference monitor with one big policy inside Init TU Dresden, 2008-01-08 MOS - Secure Systems Slide 27 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 28 von 39 Decompose security policies Use Bastei sessions • Application specific policy stack • In Bastei every task dominates its children with respect to sessions outside the child's • Diverse security policy types can be combined own subtree TCP/IP User User Web Document Passwd SSL Stack Alice Bob Getty Store Auth Auth • Eases up multilateral security Grand- – Every organization unit can Child integrate its own policy Ethernet Intel 100 TE + TPM Roles 1000 Card Pro dominates first policy TCP/IP decision Mailserver Webserver DNS Stack Child 1 Child 2 ATA PCI Host LPC Controller Controller Driver dominates Audit iptables second policy just ACM decision do it! Init ACM TU Dresden, 2008-01-08 MOS - Secure Systems Slide 29 von 39 TU Dresden, 2008-01-08 MOS - Secure Systems Slide 30 von 39
Recommend
More recommend
