Linux Security
with SUSE® LINUX Enterprise Server 9 (SLES9)

Roman Drahtmüller

Security Architect

Novell/SUSE

Overview

Overview about security work at SUSE

The Common Criteria Certificate: Facts and data about the impact of CC-CAPP/EAL4+

Confinement technology for Linux

Future outlook

Security@suse.com

Simplistic Face of Security Work

Features

Bugs

Assurance

Novell/SUSE Security Team

Security certification

Monitoring of security information channels

Maintain contacts to organizations and individuals

Select and configure software securely

Ongoing work:

Develop security tools and applications

Source code audits

Announce fix/update/patch availability

Provide solutions for security breaches in software packages (updates)

Assurance

Novell/SUSE Security Team

Security certification

Monitoring of security information channels

Maintain contacts to organizations and individuals

Select and configure software securely

Ongoing work:

Develop security tools and applications

Source code audits

Announce fix/update/patch availability

Provide solutions for security breaches in software packages (updates)

Assurance

Proactive

Reactive

Common Criteria Evaluations

Distributor's role

Communication b/w Customers in Government, Industry, Consumer, IHV/ISV Partners, Organizations, OSS Developers and the Community

Mediator for conflicting interests

Adding value for the customer to lower TCO and ease deployment and maintenance

Overview:
Linux Development Process

Challenge:

OSS development teams have different configuration management and submission/acceptance processes and associated to the CM

Development processes are not verifiable for compliance with requirements from/for security

Missing centralized review of code and changes to it

Missing consistent Quality Assurance

Overview:
Linux Development Process

Solution:

mapping of development processes and CM:

Novell / SUSE

KDE

Openssl

Kernel

Glibc

GCC

CERT

Individuals

Distributors,

IHVs,

ISVs

Development related, regular bug handling

Security related, vulnerability handling

SUSE Linux Development Process

Open Source
Community

Common Code Base

AutoBuild

Quality Assurance
and Testing

3,000+ Packages

million
Lines of Code

~6,000+ Patches

thousands
Lines of Code

x86

Intel 64

AMD64

POWER

S/390

zSeries

Automated System identifies incompatibilities

Automated
Regression

Manual
Regression

Feature Test

Novell
SuperLab

Fixes

Product lifetime:
The processes involved

Code/Feature

Community Contacts

Package/Solution

Q+A

Installable Product

Delivery and Operation

Flaw Remidiation

Packaging Process

Autobuild (CM)

Approval Process

Bugtracking

Stable Interfaces

Enterprise Class

Product

Lifecycle

Management

Customer

Support

Maintenance

Novell / SUSE

Community: OSS Teams, IHVs, ISVs, ...

Certifications

Configuration Management:
Autobuild

Centralized package, product and patch building

and maintenance engine

Transitive building of packages to ensure consistency and compatibility

Very high performance and scalability with minimal human interaction

Protection of integrity

Reproducible package building engine

Peer review at package check-in

Approval steps for update path to the customer

Autobuild Process and infrastructure capacity: Some data

10 servers, 250+ build clients

7 code bases

(up to) 9 architectures

3800 binary packages in 2600 source packages

Rebuild time for SLES9/CODE9 codebase:

7 hours

Minimum time from knowing about a vulnerability until patch availability for customer (includes testing/QA):

1.5 hours

CAPP EAL2, EAL3+, EAL4+ evaluations

Sponsor

(IBM, HP, SGI)

Distributor

(Novell/SUSE LINUX AG)

Product

(SLES 8 (EAL2, 3+), SLES9 (EAL4+), multiple architectures)

Evaluation Facility

(atsec Information Security GmbH)

Certification Body

(BSI, Bundesamt für Sicherheit in der Informationstechnik, German Federal office for IT Security, CCMRA accr.)

Evaluation history

EAL2 start 02/2003, Certificate 07/2003

EAL3+ start 08/2003, Final ETR 12/2003, Certificate 01/2004

EAL3+ with HP start in 05/2004, Certificate in 11/2004

EAL4+ with IBM start in 03/2004, Evaluation completed successfully, Certificate pending

EAL3+ with SGI start on 01/2005, end expected Q2/2005

Confinement Technology

Confinement technology:
Why?

Complicated code

Humans make mistakes

Use of C and C++ - non-type-safe languages

No least privilege code execution principle applied!

Why application level security, platform hardening and confinement?

Confinement technology:
The problem...

Result: Security vulnerabilities allow attackers to circumvent ...

The application programmer's plan for the program execution path

Security policies, if not mandated by the OS

Heap- or stack overflows, caused by insufficient bounds checks or format string errors

Double free() errors in buffer management

Integer overflows, signedness and 64bit issues

Design flaws

...

Vulnerabilities

Confinement technology:
Remedy

Solution: Constrain the priviledges to access system resources on a per-application basis

Least privilege execution

The policy is mandatory and cannot be circumvented

Confinement technology:
Design requirements

Usability: Not all system experts must be able to use it

(Policy) verifiability: Admin must be able to verify the correctness of the policy

Focus on protected assets in system (integrity, privacy, availability, accountability, applied to the resources provided)

Transparency for the application: Obsoletes the need to adopt software for security enhancement technology

Simplicity: Complex design and/or configuration contradicts security

Confinement technology:
Result

The program's execution privileges are tied to not only the user's identity in the system, but also to the purpose of the application

Attackers exploiting a potential vulnerability of a protected application can't access other files any more

Eases the pressure to apply a security fix for a freshly known vulnerability (Vulnerable: Yes, Exploitable: No)

Confinement technology:
SELinux Support in Novell/SUSE Linux products

Problem:

Complexity

Missing transparency requires SELinux awareness changes in applications

SELinux Policy applied nearly equals code changes in applications

Stability and performance concerns

Missing maintainability and supportability for products in enterprise environment

Confinement technology:
SELinux Support in Novell/SUSE Linux products

Status:

Rudimentary support available in SLES9

No policy files supplied for applications

Opt-in to preserve full performance and stability: Default is off, SELinux needs to be activated by kernel commandline parameter

Maintenance and Support agreements are invalidated if SELinux is active

ISV and IHV certifications are invalidated if SELinux is active

Confinement technology:
SELinux Support in Novell/SUSE Linux products

Outlook:

Follow the development

SELinux is considered promising technology with potential

SELinux development will provide higher level languages to specify policies to improve usability

SELinux

Confinement technology Alternative:
AppArmor

AppArmor by Immunix, formerly known as SubDomain

Features:

Non-intrusive integration into the Linux kernel by LSM framework

Simple configuration/policy file format to allow for verifiable configuration and customization of the confinement/hardening subsystem

Easy integration into Novell/SUSE products by provided YaST2 systems management software module (certified YES product!)

Learning mode allows for even easier creation of application policy

Confinement technology Alternative:
AppArmor

Features (continued)

Transparency: Applications are not aware of being run in hardened environment

Does not conflict with Novell/SUSE maintenance, support and ISV/IHV certification programs

Comes with prebuilt profiles

Runs on all filesystems supported by Novell/SUSE products

Partners with Novell to ensure best value

Strategy/Long Term Outlook

Strategy

Integrity Protection/Mandatory policies

Deploy Novell Identity Management Solutions on the Linux platform

Provide MLS (Multi-Layer Security) policy support

Virtualization and Security:

Trusted Computing, Xen ...

These gray lines show the margins that need to be adhered too. If your slide content extends beyond the margins you may need to move to a full screen slide layout.

Most importantly keep the area under the logo clear

Yellow

Palette

Green

Palette

Blue

Palette

Gray

Palette

Misc

R 252

G 194

B 79

R 225

G 213

B 75

R 182

G 201

B 207

R 186

G 189

B 182

R 237

G 238

B 236

R 224

G 0

B 0

R 107

G 108

B 105

R 100

G 132

B 164

R 157

G 176

B 41

R 232

G 128

B 0

R 201

G 86

B 22

R 115

G 126

B 31

R 77

G 68

B 102

R 46

G 52

B 54

R 204

G 0

B 0

R 188

G 225

B 141

R 0

G 149

B 48

R 0

G 98

B 90

SUSE

Palette

Corporate color palette and margins

2004-01-28T12:03:58