Trusted Linux Overview - public.dhe.ibm.compublic.dhe.ibm.com/software/dw/library/os-ltc-security/LWE-Boston-0… · Trusted Linux Overview Doc Shankar IBM Linux Technology Center

Trusted Linux Overview

Doc ShankarIBM Linux Technology Center, Austin

[email protected]

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


Enterprise Security Problem


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


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)


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,…)


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!


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


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


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


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


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


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


SLES 9 SP2

SGI Altix 350SGI Altix 3700


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


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


SLES 8SP3




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


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


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)



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


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


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


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


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


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


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


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


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


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


SELinux Operation


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


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


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)


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


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


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


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.


Documents

Trusted Linux Overview - public.dhe.ibm.compublic.dhe.ibm.com/software/dw/library/os-ltc-security/LWE-Boston-0… · Trusted Linux Overview Doc Shankar IBM Linux Technology Center