Post on 12-Oct-2020
transcript
Trusted Linux Overview
Doc ShankarIBM Linux Technology Center, Austin
dshankar@us.ibm.com
5/18/2006 Doc Shankar 1
Agenda• Linux Security Solution – What’s the big problem?• Open Source – Is it more secure?• Attacks – How does one get attacked?• Linux Security - What’s now?• Linux Security - What’s new?• Linux Security Certification - What’s going on?• SELinux - How does this raise trust?• Protection Profiles - How do we measure security?• Trusted Linux - Where are we?• Summary - Can I trust Linux? 5/18/2006 Doc Shankar 2
Linux Security OptionsLSM VPN IPSECNessus Physical AccessDAC Bastille Open SSH/SSLOpen SSL SELinux
Password
KerberosCAPP/EAL4+
CertificateopenCryptoki
AppArmor
Open LDAP
H/W CryptoMAC
LIDSTrouSerS
eCryptfs
Trusted Computing
noexec stackPIE
Smart Card MLSPAMToken
Hook VerificationPKI
HardeningSnortTCP Wrapper iptablesTripwire
RSBACIPsec ClamAVAstaro
5/18/2006 Doc Shankar 3
Enterprise Security Problem
5/18/2006 Doc Shankar 4
S/390®AS/400®UNIX
NT
Core Network
SecurityManagement
CertificateAuthority
Firewall
Customers
Mission-Critical Servers
SuppliersDistributors
Perimeter Network
Access Network
Mobile EmployeesBusiness Partners
PC Security
ActiveContent
VPN Single Sign-on
BackupRestore
Intrusion Detection
SecurityAuditing
E-MailFiltering
Web Servers
Proxy-ServerWorkload
Management
Internet Access
PC Anti-Virus
MerchantServer
Open Source Security Solutions*
• Core Network● Single Sign On
• OpenLDAP● Authentication
• MIT Kerberos• Heimdal
● Web Server• SSL + Apache
● File/Print Sharing• Samba, NFS
● Certificate Authority• CertCA
● Database• SSL + PostgreSQL• MySQL
• Hardware Encryption• OpenCryptoki
Access Network● VPN
• IPSec● Anti-virus
• ClamAV● Web browser
• Firefox, Konqueror● Email client
• Evolution, Thunderbird, Mutt
● Communication• OpenSSH, OpenSSL
● Hardening• Bastille
● Data Integrity• Tripwire, AIDE
Perimeter Network● Intrusion Detection
• Snort, LIDS● Security Auditing
• GNessus● Email Filtering
• SpamAssassin● Firewall
• IPTables● Proxy
• Squid
* hardly a comprehensive list
5/18/2006 Doc Shankar 5
Enterprise Security Concerns
• Increasing Vulnerabilities• Virus Attacks• Insufficient Physical Security• Asset/Data Protection• Protecting the Privacy of Customer Data• Intrusions• DDoS• Patch Management• Internal Threats (Privileged Users)
5/18/2006 Doc Shankar 6
What’s Different About Linux Security?• Source code availability
– Most programmers take extra precautions– Community inspection/review– Community audit
• Patch speed– One example – Network Time Demon(ntpd)– Open source distributors released workaround/fixes within hours– Other vendors took days
• Community participation– Lot of interest from research community– Hard for one vendor to do this– Large/talented community has spanned interesting projects
• Cryptography comparison– Crypto is hard to do right – the only way is to keep open– The only way to tell good crypto from bad crypto is to have it examined by experts– Open source crypto algorithms are strong – e.g, DES, AES– Open crypto is not only better – it’s cheaper (AES is free)
• Comparison to secure protocols– (Same points as above)– Open design is better (SSL, IPSEC, TLS, S.MIME, SET,…)
5/18/2006 Doc Shankar 7
Is Open Source More Secure?• Simply publishing code does not mean people will
examine it for security flaws.– There are many Open Source libraries that no one has ever heard
of, and no one has ever evaluated.• Bad guys have access to code.• So, while Open Source is a good thing, it is NOT a
guarantee for security.– On the other hand, Linux has been looked at by a lot of very good
security engineers.• End user empowerment
– Autonomy in resolving security issues• Diversity inoculates against class breaks• Linux offers the rock-solid security tradition of Unix
Advantages are there – one must take advantage of them!
5/18/2006 Doc Shankar 8
Attack Categories• Spamming• Malicious Programs
– Trojans– Virus– Worms– Rootkits– Botnets
• DoS/DDoS• People
– Social Engineering– Weak passwords– Sloppy Admins.
• Unsafe Programs• Misconfigured Programs• Buggy Programs
– Buffer Overflows– Parsing Errors– Formatting Errors– Bad input to cgi bin
• Eavesdropping• IP Spoofing• Phishing• Pharming
5/18/2006 Doc Shankar 9
Linux Security – What’s now?• Base Security Features (PAM, Permission bits, ACLs, SELinux, AppArmor)• Network Security Features (iptables, OpenSSL, OpenSSH, IPSec, Labeled IPSec) • Achieved CAPP/EAL4+ certification• LSM hooks in 2.6 kernel (BSD Secure Levels, BSD Jail, TPE, DigSig)• SELinux in 2.6 kernel (Type Enforcement, Confinement, Targeted Policy)• AppArmor• Trusted Computing (TPM driver in 2.6 kernel, TSS & TPM-tools open sourced)• Lots of good free security software
– Snort, ClamAV, OpenSSH, OpenSSL, Tripwire, AIDE, nmap, GnuPG, and many more• Lots of good paid (commercial) software
– Tivoli, CA, Symantec• Main distributions concerned and handling security well
– Red Hat, Novell SUSE, Mandriva, etc• Secure distributions exist
– Trustix, Astaro, Openwall
5/18/2006 Doc Shankar 10
Linux Security – What’s new?• MLS/Linux• LSPP Compliance• Vulnerability Mitigation• Audit Capability• OpenSSL FIPS 140-2 Level 1• EAL5 (Mandriva)• zSeries HW Instructions• OSDL Initiatives
– DCL– CGL– DTL
• SELinux Adoption– Targeted policy default in
RHEL4– Policy Development
Methodology/Tools - Virgil– Performance– Across all eServer
• AppArmor– Available in SLE9 SP3
• Trusted Computing– Infrastructure Open Sourced– OpenTC
• Encrypted File System
5/18/2006 Doc Shankar 11
Linux Security Initiatives• Security Certification*
– Common Criteria– EAL2+ achieved*– CAPP/EAL3+ achieved*– CAPP/EAL4+ achieved*– Working LSPP/EAL4+*
• Crypto*– OpenCryptoki*– HW crypto acceleration*– FIPS 140-2**
• Trusted Computing* – TCG's TPM/TSS Implementation*
• Networking Security**– OpenSSL**– OpenSSH– IPSec**
• Base Security**– LSM**– Audit *– Kerberos– PKI
• Applications Security**– Encrypted File System*– Firewall– Antivirus– IDS**– Security Scanners– Position Independent Executables– Exec Shield
• Mandatory Security**– SELinux**– MLS**
• Secure Configuration**– Bastille**
• Vulnerability reduction/reporting**• Secure Programming**
– BogoSec• Verification Tools*
– Vali*– Gokyo*– UT tool**
* IBM Leading ** IBM Participating
5/18/2006 Doc Shankar 12
Linux and Common Criteria• Until 2003, many people believed that Linux would not be
able to get CC certified• Now, three years later, no other operating system has got
more Common Criteria certificates than Linux®– Two distributions (Novell SUSE and Red Hat)– Two different kernel versions (2.4 and 2.6)– Many different hardware platforms
• IBM® Pentium, XEON, and Opteron systems• IBM pSeries®, iSeries™, and zSeries® systems• HP Pentium, XEON, and Itanium systems• SGI Itanium systems
– Two certifying agencies (BSI & NIAP)– Assurance levels up to EAL4 augmented by ALC_FLR.3
5/18/2006 Doc Shankar 13
Evaluation Achievements/RoadmapProduct Hardware Kernel PP Assurance
LevelEvaluator Certifying
BodyApplication Date
Certification Date
SLES 8 xSeries® 335 2.4 ST EAL 2+ atsec BSI 02/03 08/03
SLES 8 SP3
xSeries 335, pSeries® 630, iSeries™ 825, zSeries® 900, eServer™ 325
2.4 CAPP EAL3+ atsec BSI 07/03 01/04
RHEL 3 Dell PowerEdge 6650 (AS)HP Proliant ML 570 (AS)Dell PowerEdge 2650 (ES)HP Proliant ML 570 (ES)Dell Precision 650 (WS)HP d350 (WS)
2.4 ST EAL2+ Syntegra CESG 02/03 02/04
RHEL 3UP3
Range of HP Pentium, Xeon and Itanium based systems
2.4 CAPP EAL3+ atsec BSI 04/04 09/04
SLES 9 SP2
SGI Altix 350SGI Altix 3700
2.6 CAPP EAL3+ atsec BSI 10/04 10/05
RHEL 4 Unisys ES7000 2.6 CAPP EAL4+ SAIC NIAP 12/04
SLES 8 SP3
xSeries 345, 365, 445 & eServer 326 2.4 CAPP EAL3+ atsec BSI 07/05 09/05
RHEL 3 Unisys ES7000 2.4 CAPP EAL3+ SAIC NIAP 12/04
RHEL 4 UP2
Range of HP Pentium, Xeon and Itanium based systems
2.6 CAPP EAL3+ atsec NIAP 10/05
RHEL3 UP2
xSeries 335 AS/WS, pSeries 630 ASiSeries 825 AS, zSeries 990 AS, eServer 325 AS
2.4 CAPP EAL3+ atsec BSI 03/04 07/04
SLES 8SP3
Range of HP Pentium, Xeon and Itanium based systems
2.4 CAPP EAL3+ atsec BSI 04/04 09/04
5/18/2006 Doc Shankar 14
Evaluation Achievements/RoadmapProduct Hardware Kernel PP Assurance
LevelEvaluator Certifying
BodyApplication Date
Certification Date
SLES 9 xSeries model x335 machine type 8676pSeries model 520 machine type 9111(LPAR SF220_049)iSeries model 520 machine type (9406)(OS/400® V5R3 LPAR )zSeries 990, eServer 325
2.6 CAPP EAL4+ atsec BSI 03/04 03/05
RHEL4 UP1
xSeries model x336 machine type 8837 (AS/WS)pSeries model 550 machine type 9124 with pSeries LPAR (AS only)iSeries model 550 machine type 9406 with OS/400 v5R3 LPAR (AS only)zSeries z/VM 5.1 Logical Partition (AS only)eServer model 326 based on the AMD 64 (Opteron) processor machine type 8848 (AS only)
2.6 CAPP EAL4+ atsec NIAP 02/05 02/06
RHEL5 xSeries model x346 machine type xxxx & model HS20 Blade (AS/WS)zSeries z/VM 5.1 Logical Partition – includes z800, z890, z990, z9 (AS only)eServer model 327 based on the AMD 64 (Opteron) processor machine type xxxx & model LS 20 Blade (AS only)
2.6 CAPP LSPP RBAC
EAL4+ atsec NIAP 09/05 03/07
5/18/2006 Doc Shankar 15
The Problem: Inadequate OS Security
• OS protection mechanisms are foundational.• General purpose OSes lack adequate security mechanisms.
– No protection against flawed or malicious applications.– Key missing feature: Mandatory Access Control (MAC)
• “Trusted” OSes had a form of MAC but:– were not mainstream– used a fixed, limited MAC model (BLP/Biba)
5/18/2006 Doc Shankar 16
5/18/2006 Doc Shankar 17
DAC - Concepts• Traditional UNIX owner-group-other access control model
and, optionally, ACLs• Two roles: superuser and ordinary user• Access to objects at owner’s discretion• Access mode can be modified by the owner or programs
running on behalf of the owner• Enforcing mechanism and rules hard-coded in the kernel
5/18/2006 Doc Shankar 18
MAC - Concepts• Derived from separation required by military environments• Administrator (and not the owner) has full control over
allowed access• Programs running on behalf of a user are constrained by
the administrator controlled security policy• Rules can be hard-coded in the kernel or configurable
5/18/2006 Doc Shankar 19
DAC vs MAC• Newer concept, hard to
grasp• Program privileges under
the control of security policy
• Trusted program privileges also under the control of security policy
• Easier to implement the principle of least privilege
• Familiar, easy to understand
• Program executes with privileges of the user
• Trusted programs often run with superuser privileges.
• Superuser privileges harder to breakup
5/18/2006 Doc Shankar 20
TE - Concepts
• Subjects belong to domains and objects have types• Domains and types are equivalence classes for processes
and resources respectively• Flexible and configurable policy implements MAC rules
that mediate access between all domains and all types
5/18/2006 Doc Shankar 21
SELinux TE• Both domains and types are implemented as types. Subject
types are sometimes referred to as domains • Security policy specifying MAC rules is configurable and
can be changed dynamically• MAC rules are specified for subject domains, object types
and object classes• Orthogonal to DAC, cannot allow what DAC has denied• Default is to deny everything. Only allowed operations are
those explicitly listed in rules of the security policy
5/18/2006 Doc Shankar 22
RBAC - Concepts• Domains are assigned to processes where as roles are
assigned to users.• Roles allow users access to domains• Roles are part of the subject and the object security
contexts• Roles do not directly get involved in access decisions;
access decisions are made based on subject domain
5/18/2006 Doc Shankar 23
TE – Access control example• Users Bob, Alice, Jack and Jill are part of a software development
project• Upon login they are placed in domain proj_member_t• Project files are of type proj_files_t• The security policy allows subjects in proj_member_t domain read
access to files of type proj_files_t
proj_member_t proj_files_tread
5/18/2006 Doc Shankar 24
TE/RBAC – Access control example
• Alice, Bob and Jill are developers, Jack writes design documents, and Alice is also the project lead
• Changing roles puts users in appropriate domains, for example, changing role to developer_r puts the user in domain proj_devel_t
proj_member_tproj_files_t proj_docs_t
proj_doc_t
proj_devel_t proj_lead_t
read
Write
read
writere
adread
write
read
read
write
5/18/2006 Doc Shankar 25
SELinux – Background• Motivation
– MAC—Information separation and self-protection– Separate security enforcing mechanism from security policy—
security server, policy, object managers• Brief History
– Created by NSA through series of research projects in the 1990s– Based on the Flask architecture developed by NSA, SCC, and
University of Utah• Current Status
– Available with standard Linux kernel– Implemented as Linux Security Module– User level packages available with many Linux distribution
5/18/2006 Doc Shankar 26
SELinux – Components• Kernel
– LSM module– available from Linux 2.6 stable series
• User space– Support utilities, libraries and configuration files– Patched Linux system utilities– Source available from NSA, source and binaries available from
different Linux distributions• Policy
– Security policy rules– Source available from NSA, source and binary available from
different Linux distributions
5/18/2006 Doc Shankar 27
SELinux Operation
5/18/2006 Doc Shankar 28
CAPP Overview• CAPP is based on C2 class of the “Department of Defense
Trusted Computer Systems Evaluation Criteria” (DoD5200.28) coloquially known as the “Orange Book”
• CAPP requires the OS implement DAC• 5 Categories of Functional Requirements
– Security Audit– User Data Protection– Identification & Authentication– Security Management– Protection of the TSF
• Requires EAL3
5/18/2006 Doc Shankar 29
LSPP Overview• LSPP is based on B1 class of the “Department of Defense
Trusted Computer Systems Evaluation Criteria” (DoD5200.28) coloquially known as the “Orange Book”
• LSPP requires the OS implement MAC• 5 Categories of Functional Requirements
– Security Audit (includes labeling, import/export of data)– User Data Protection (includes MAC/MLS)– Identification & Authentication (includes Security Levels)– Security Management (includes MAC policy controls)– Protection of the TSF (very similar to CAPP)
• Requires EAL3
5/18/2006 Doc Shankar 30
MLOSPP Overview• MLOSPP is based on “B2” class of the “Department of Defense
Trusted Computer Systems Evaluation Criteria” (DoD 5200.28) coloquially known as the “Orange Book”
• MLOSPP requires the OS implement MAC, MIC & Crypto• 9 Categories of Functional Requirements
– Security Audit (includes MAC, MIC, import/export of data)– Cryptographic Support (FIPS 140-2+)– User Data Protection (includes MAC/MIC/MLS)– Identification & Authentication (includes Security & Integrity Levels)– Security Management (includes MAC & MIC policy controls)– Protection of the TSF (includes TOE data transfer, Replay, Recovery, etc.)– Resource Utilization (Quotas for Disk, Memory & Processor)– TOE Access (Location, Concurrent sessions, Session Locking, etc.)– Trusted Path (Secure Attention key)
• Requires EAL4+ (4 EAL5 & 1 EAL6 requirement)5/18/2006 Doc Shankar 31
Towards LSPP Compliance• A true open source effort - challenging• IBM sponsors a weekly teleconference
– 40 participants from 9 organizations on the invitation• IBM, Red Hat, NSA, @sec, HP, TCS, Tresys, OSDL, and PSU +
various individuals– All development takes place on open mailing lists
• Development goes upstream and is collected in rawhide– Fedora Rawhide provides daily builds for xSeries and pSeries.– Red Hat hosts test kernels for features pending kernel maintainer
acceptance.• Schedule
– In Evaluation (09/05)– Development Complete (03/06)– Certification Complete (03/07)
5/18/2006 Doc Shankar 32
Towards LSPP Compliance (Contd.)• Major Enhancements
– Kernel• SELinux MLS Support• IPsec labelled networking• Audit augmentation• VFS polyinstantiation
– User Space• MLS Policy using reference policy• Enhanced user management• Audit filtering• Browsing augmentation• Device allocation• Labelled print• Multilevel network services• Multilevel cron
5/18/2006 Doc Shankar 33
Towards LSPP Compliance (Contd.)• Work remaining
– Complete MLS development– Get it upstream– Ensure MLS work is incorporated into RHEL5– Augment exiting test suite– Enhance design documentation
• Functional Specification• High Level Design• Low Level Design
– Run tests and produce documentation– Undergo evaluation by lab.– Obtain certificate from NIAP– Open source documentation
5/18/2006 Doc Shankar 34
Conclusion
• Linux has much to offer in terms of security• Linux has a bright future ahead• IBM is committed to elevating Linux as a
secure operating system of choice in today’s business environment
5/18/2006 Doc Shankar 35
Legal StatementThis work represents the view of the authors and does not necessarily
represent the view of IBM.
SUSE and its logo are registered trademarks of Novell.
IBM, IBM logo, AIX, AS/400, eServer, xSeries, iSeries, pSeries, zSeries, are registered trademarks of International Business Machines Corporation in the United States, other countries, or both.
Linux is a registered trademark of Linus Torvalds in the US, other countries or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
5/18/2006 Doc Shankar 36