Open Source Roadmap: Realtime Enterprise Linux and Security Solutions

1
Open Source Roadmap Realtime Enterprise Linux
and Security Solutions

• Agenda
• 800-915 Realtime Enterprise Linux
• 915-930 Break
• 930-1045 Open Source Security Solutions
• 1045-1100 QA and Closing

2
Red Hat Enterprise MRG Realtime Tim
Burke Senior Director Emerging Technologies
3
Agenda

• What? - MRG product objectives
• Who? - Target use cases
• Performance results
• How? - Implementation strategy
• Then what? - support, maintenance, hardware
  certification
• Messaging Grid components

4
Red Hat Enterprise MRG

• High performance distributed computing platform
  that extends Red Hat's Linux Automation Strategy
  with new levels of performance, scale,
  utilization, flexibility, and qualities of
  service
• Transparently schedule any computing task across
  local grids, remote grids, cloud infrastructure
  such as Amazon EC2, and idle desktop workstations
• Enable applications to run with the lowest and
  deterministic latency
• Send durable messages with two orders of
  magnitude higher throughput
• New product that integrates Messaging, Realtime,
  and Grid

5
MRG Messaging, Realtime, Grid

• Integrated platform for high performance
  distributed computing
• Messaging
• High speed, interoperable, open standard
  messaging middleware
• 500,000 messages/sec per storage LUN
• Realtime
• Predictability, low-latency, quality of service
  Linux kernel
• Grid
• Scheduler high performance computing (HPC) for
  distributed workloads, cycle stealing
• Managing large pools of computers tasks
• The 3 components are complimentary, but can be
  used independently

6
MRG Realtime Target Market

• Target hardware
• Commodity high volume x86, x86-64 computers
  (Intel AMD)
• Typically 1U-4U rackmount or blades
• 512MB mem
• Not targeting embedded, small footprint devices
• Systems certified based on market pull
• Target use case
• Distributed client/server compute models
• High speed networking computation
• Not targeting database / fileserver
• Workload requirements for consistent, predictable
  application response times

7
(No Transcript)
8
MRG Realtime product objectives

• Determinism ability to schedule high priority
  tasks predictably and consistently
• Priority ensure that highest priority
  applications are not blocked by low priority
• Quality Of Service (QoS) trustworthy,
  consistent response times
• Proven results
• Context switch latency under 25 µs. 99.9999
  under 20 µs (from interrupt to commencing running
  new process)
• Average of 38 improvement over stock RHEL5
• Timer event precision enhanced to µs level,
  rather than ms

9
Why determinism matters

• When close enough isn't good enough
• Financial Services time is money
• First response wins competitive bids
• Legal requirements for consistency
• Federal Sector command and control
• Rapid response to data inputs
• Trustworthy response times
• Telco/Network network packet handling
• Quality of service

10
MRG Realtime Illustrating determinism

Red Hat Confidential
11
Detail zoom-in of RHEL5 vs MRG Realtime

Red Hat Confidential
12
Typical sources of non-determinism

• Application priorities
• One application blocks another
• Or holds a contended resource (lock)
• Linux kernel
• When the Linux kernel is running, applications
  block
• The longer the kernel runs, the longer
  applications block
• Determinism bounded by longest running kernel
  codepath

High priority app runs
High priority app resumes
Interrupt
Kernel interrupt handling scheduler
13
Realtime kernel determinism improvement strategy

• Measure identify long-running kernel codepaths
• Improve algorithms for more concurrency
• Run as little as possible non-preemptable
• Defer processing to lower priority kernel threads

High priority app resumes completes
High priority app runs
Next high pri app runs
Interrupt
Lower pri int handler completes data transfer
Int handler blocking portion. Schedule lower
pri processing thread
14
Realtime Linux history

• Previously realtime products were niche,
  non-standard
• Requiring specialized operating system
• Requiring custom development environments
• Requiring porting / re-build support for
  applications
• Precludes most 3rd party ISV software
• Requiring deployment training to system
  administrators
• Previous attempts at submitting realtime
  capabilities in the mainstream Linux kernel tree
  failed
• Detrimental to other use cases (desktop,
  database/fileserver throughput)
• Patch-bombs
• Submitters lacked patience and community
  interaction skill

15
MRG Realtime Breakthroughs

• Red Hat engineers succeed at mainstream
  acceptance
• Methodical multi-year implementation
• Started with extensive rearchitecting enablers
• Incrementally added features beneficial to all
  use cases
• Iteratively worked to cooperatively build an
  inclusive realtime community
• MRG Realtime is COTS (Commercial Off The Shelf)
  operating system
• Standard RHEL5.1 OS
• Replacement kernel
• Provides full application compatibility
• No application recompilation required
• Integrated with distributed high speed messaging
  grid scheduler
• MRG Messaging, MRG Grid

16
MRG Product Composition
MRG Messaging
MRG Grid
IBM Real-time Java
Red Hat Enterprise Linux 5.1
3rd party applications
RHEL5.1 utilities (1000)
RHEL5.1 glibc runtime library
MRG Realtime replacement kernel
17
How? - Productization Strategy

• Follow proven Red Hat Enterprise Linux approach
• Upstream objective from day1
• Transparent, inclusive development
• Patience to do it right longterm incremental
  inclusion
• Select stabilization points
• Extensive internal external testing and
  hardening
• Benefits of this strategy
• Red Hat is uniquely positioned to support and
  continue to drive upstream focused enhancement
• Mainline upstream inclusion allows COTS
  advantages
• Supportability
• No need for custom dead-end releases lagging in
  time
• Allows usage of full release features ie,
  SELinux

18
How? - Demonstrated leadership in upstream
community development

• -rt patchset
• A working sandbox for a community of developers
  users
• The recognized Linux epicenter for RT active
  work-in-progress
• Comprehensive RT enablement, not just a quick
  VM/scheduler hack
• A growing collection of many features. Not just
  1 thing.
• Many of its features enabling cleanups are
  already upstream.
• Large patch set in core kernel codepaths
  (interruptss, scheduler, locks, etc).
• 120,000 lines at its height. As of 2.6.21 -
  shrinks to half
• Many more in 2.6.19 20. Other parts will go
  into .21, .22, ....
• Will take well over an additional year to
  mainstream all of it. Targeting full RHEL
  integration in subsequent major release, ie
  RHEL6.

19
How? - Community Project

• Upstream -rt developer participants and
  approximate contribution rate
• 45 - Ingo Molnar lead developer and overall
  upstream leader. Focus on scheduler, locking,
  interrupts. Red Hat fulltime employee
• 35 - Thomas Gleixner developer, primarily
  concentrating on timers. Contractor to Red Hat
• 10 - Steven Rostedt developer. Red Hat
  fulltime employee
• 10 - all other participants (IBM, Monta Vista,
  Timesys, Novell, etc)
• All efforts are ultimately shaped towards
  long-term mainstream inclusion
• Substantial additional Red Hat internal staffing
  for productization
• Testing test development
• Fixing
• Tool development system mgt performance
  monitoring
• Documentation and associated tools development.

20
Real-time kernel work upstream

• Priority inheritance futexes (PI-futex) (2.6.18)
• Generic IRQ layer (2.6.18)
• Core time re-write (2.6.18)
• Sleepable RCU (2.6.19)
• Latency Tracer (circa 2.6.18)
• High-resdynticks (2.6.21)
• CFS completely fair scheduler (2.6.22)
• Conversion of spin-locks to mutex (2.6.24)
• All Interrupt handling in threads (2.6.24)
• Full rt-preempt (2.6.25)

• Items 2.6.18 and prior are in RHEL5
• Work over the last 2 years. 90 Red Hat, 120,000
  lines
• Mostly maintained in -rt tree
• Over the last year, many patches have moved from
  -rt to mainline kernel
• BKL preemptable (2.6.8)
• Mutex patch (2.6.16)
• Semaphore-to-Mutex conversion (ongoing 85 done)
• Hrtimers subsystem (2.6.16)
• Robust futexes (2.6.17)
• Lock validator (2.6.18)

21
Upstream success Improve kernel lock
synchronization

• Improve granularity identify and correct
  contention points
• Mutex rather than semaphores
• Mutexes are lighter weight
• Lock validator
• Efficient runtime confirmation of lock ordering
• Can detect race conditions without actually
  hitting them
• Priority Inheritance (PI)
• Prevents low priority processes blocking higher
  priority. Problem scenario
• Low priority process takes lock
• High priority process needs lock, but must wait
• Long running medium priority process preempts low
  priority process
• Solution temporarily boost low pri process to
  allow completion
• Required for realtime java 1000's of threads

22
Upstream success timer precision interrupt
handling

• Timer enhancements
• Infrastructure cleanup factor common code,
  increase fields to represent nanosecond precision
• Timer precision utilize high resolution
  hardware timers at microsecond precision rather
  than approximate periodic time interrupt
  millisecond precision
• Generic timeof day cleanly accommodate diverse
  clock sources
• VDSO gettimeofday() - performance enhancement for
  millisecond accuracy
• Dynamic ticks power savings no need to to
  timer interrupt 1000 times per second on idle
  system transition to low power state (great for
  OLPC)
• Interrupt handling
• Generic IRQ mechanism infrastructure cleanup
  factor common code
• More fine-grained hardware interrupt control
• CFS Completely fair scheduler
• Provides fair interactive response times in
  almost all situations
• Includes modular scheduler framework realtime
  task scheduler first

23
How? - No application changes required

• All of the realtime enhancements are in the
  kernel under the hood from an application
  perspective.
• No application changes are required to benefit
  from realtime enhancements.
• Applications which are latency bottlenecked due
  to kernel scheduling and interrupt handling will
  see benefit.
• Latencies introduced entirely in userspace
  (sub-optimal application code, unbounded java
  garbage collection, etc) are not eliminated.
• Recompilation is not required (same gcc/glibc as
  standard RHEL5)
• Applications recompiled on RHEL5 benefit from pi
  mutex glibc implementation enhancements to avoid
  syscall overhead on uncontested locks.

24
How? - performance monitoring tools

• Existing standard RHEL5 based performance
  monitoring tools remain relevant
• Gdb, OProfile Frysk source level debuggers
  profiler
• SystemTap, kprobe kernel event tracing and
  dynamic data collection
• kexec/kdump standard kernel dump / savecore
  capabilities
• Latency Tracer new MRG Realtime feature
• Runtime trace capture of longest latency
  codepaths both kernel and application. Peak
  detector
• Selectable triggers for threshold tracing
• Detailed kernel profiles based on latency triggers

25
How? - Testing Strategy

• Internal external collaborative effort
• Internal
• Run through standard RHEL gauntlet.
• Incorporate additional latency/performance tests.
• Include debug variant lock validation, other
  sanity checks
• External
• Share code and leverage pre-existing -rt
  community
• Involve hardware partners and select customers in
  beta
• Leverage baseline kernel testing (ie 2.6.23) of
  non-rt kernel in Fedora
• Bound testing support to a finite set of
  targeted hardware (based on customer pull)

26
What? - Requirements expectations Support /
Maintenance / Compatibility

• Fully supported offering, extending the RHEL5
  capability set
• Sold separately from standard RHEL, different
  pricing model
• Ongoing maintenance. ie, not a 1-shot. Security
  errata, fixes and enhancements.
• Expecting ongoing feature enhancement, continued
  access to innovation.
• Itemization of tested / supported hardware per
  customer need
• Compatibility
• Fully application level compatible with RHEL5
• Kernel ABI different from RHEL5 and evolving at
  discrete milestones
• 3rd party kernel modules require rebuild and
  retest
• Professional service engagements also available

27
Then what? - maintenance

• Following the RHEL maintenance strategy that made
  Red Hat voted 1 IT value as voted by CIO Insight
• Bugfixes and security fixes will be provided
  regularly.
• The -rt patch set is rapidly evolving. Each
  upstream kernel has been incorporating selected
  portions. This will probably take well over a
  year to get the bulk of it in. Many fixes and
  feature enhancements will necessitate sizable
  change. Hence the traditional RHEL frozen code
  fork is not possible.
• Anticipating kernel rebasing in some updates.
  Frequency TBD
• Development / test builds with each upstream
  version ie 3 months
• Product update rebases less frequently ie 6
  months
• This makes ongoing maintenance enhancement much
  more upstream focused (vs typical static RHEL
  branch)

28
Then what? - Hardware certification

• Commodity high volume systems not custom
  realtime-only gear
• Different kernel from RHEL5, so RHEL5 certs don't
  equal RT cert
• RHEL5 cert is a prerequisite
• Additional cert tests in RT, ie latency
• Kernel rebasing in updates necessitates
  re-validating cert
• Certification implications
• Different certification branding designation, ie
  RT Tested
• Recognize it's a small identified set of HW we
  get in-house, into routine regression testing, to
  automatically perform re-validation with each
  rebase.
• Only test full systems, not individual drivers.
• Target certified platforms based on customer
  justification

29
Collaboratively developed realtime OS
messaging. Realtime java. The power of
community.
Financial Services Firms
Telco / NEBS
Federal
IBM realtime java
Red Hat AMQP Messaging
Red Hat - MRG Realtime
Linux Kernel Community
HP
Intel
AMD
IBM
30
How? - Realtime Java (RTSJ)

• Versions of Java which are more deterministic
  primarily by removing garbage collection
  unpredictability and inter-JVM communication
• MRG Realtime is the only Linux kernel having the
  prerequisites (ie, Priority Inheritance,
  preemption)
• Working closely w/ IBM
• IBM WebSphere Real Time
• Realtime spec conformant 200,000 rt thread
  capable
• Exclusive realtime garbage collector
• 1ms max GC pause time
• Uses at most 30 cpu in any 10ms window
• Deployed by US Navy
• DDG Destroyer program

31
What? - The broader pictureEnterprise realtime

• Most use cases are not isolated systems
• Commonly networked pipeline of systems
• TCP/IP, middleware, messaging
• 3rd party software

Clients
32
MRG Messaging

• Provides messaging that is up to 100-fold faster
  than before
• Spans fast messaging, reliable messaging,
  large-file messaging
• Implements AMQP, the industry's first open
  messaging standard, for unprecedented
  interoperability that is cross-language,
  cross-platform, multi-vendor, spans hardware and
  software, and extends down to the wire level
• Uses Linux-specific optimizations to achieve
  optimal performance on Red Hat Enterprise Linux
  and MRG Realtime
• Takes advantage of RHEL clustering, IO, kernel,
  and more
• Includes new high-performance AIO Journal for
  durable messaging
• Provides native infiniband support for transient
  messaging
• Runs on non-Linux platforms without the full
  performance and quality of service benefits that
  Red Hat Enterprise Linux provides

33
About AMQP

• AMQP is an open specification for messaging
• It is a complete specification if it doesnt
  contain all the information necessary to
  implement, we consider that a bug in the
  specification
• Anyone may use the AMQP specification to create
  useful implementations without being charged for
  the IP rights to do so
• AMQP aims to be technology and language-neutral
• Available in C, C, Java, JMS, .NET, C, Ruby,
  Python, etc.
• Requires IP, and can be used with TCP, UDP, SCTP,
  Infiniband, etc.
• Products complying with AMQP are inter-operable
• AMQP is a Wire-Level protocol based on the
  ubiquitous IP
• Wire-level compatibility means it can be embedded
  in the network
• Applications written to Product X will plug into
  servers running Product Y
• Red Hat is a founding member of the AMQP Working
  Group

34
MRG Grid

• Brings advantages of scale-out and flexible
  deployment to any application
• Delivers better asset utilization, allowing
  applications to to take advantage of all
  available computing resources
• Dynamically provisions additional peak capacity
  for Christmas Rush-like situations
• Executes across multiple platforms and in virtual
  machines
• Provides seamless and flexible High Throughput
  Computing (HTC) and High Performance Computing
  (HPC) across
• Local grids
• Remote grids
• Remote clouds (Amazon EC2)
• Cycle-stealing from desktop PCs

35
MRG Grid is based on Condor

• MRG Grid is based on the Condor Project created
  and hosted by the University of Wisconsin,
  Madison
• Red Hat and the University of Wisconsin have
  signed a strategic partnership around Condor
• University of Wisconsin makes Condor source code
  available under OSI-approved open source license
• Red Hat University of Wisconsin jointly fund
  and staff Condor development on-campus at the
  University of Wisconsin
• Red Hat and the University of Wisconsin's
  partnership will
• Add enhanced enterprise features, management, and
  supportability to Condor and MRG Grid
• Add High Throughput Computing capabilities to
  Linux

36
Red Hat Enterprise MRG Availability

• MRG Announcement Beta Launch December 2007
• Public beta
• MRG v1.0 Early 2008
• RHEL-only support for MRG Messaging broker
• MRG Grid Technology Preview
• MRG v1.1 Late 2008
• Multi-platform support for MRG Messaging
  Java-based broker
• AMQP support updated to newly available AMQP
  version (1.0)
• MRG Grid support available

37
Recaping RHEL Model Differences

• Smaller focused customer base, high touch
• More rapid access to kernel innovation
• Focused subset of hardware platforms supported
• x86, x86-64 only
• 3 or 6 month updates
• SLA balancing technology access vs assurance
• Certification smaller hw set, fewer kernel ISV
  participants
• Different pricing model, coupled with
  professional services

38
Summary Which RHEL is best for you?

• Standard RHEL4 5
• General purpose server, without strict
  performance SLAs
• Throughput intensive ie database (TPC-C/H),
  file serving, web / mail servers, HPC clusters
• No identified high priority processes - treated
  equally
• Tuning with cpu affinity and interrupt binding
  in RHEL45 provides required latency
• Cost sensitive
• Virtualization capabilities
• 3rd party kernel ISVs

• MRG Realtime
• Specialized server for deterministic low-latency
  performance SLA
• Specifically identified high priority processes
  requiring rapid scheduling in response to events
  ie recalculate of risk / trade based on new
  info
• Requirements for high precision in timing, ie
  gettimeofday()

39
Why is Red Hat the superior realtime platform?

• (compatibility) standard RHEL5 user space install
  no application changes
• (leadership) RH engineer is leading the
  upstream/mainstream realtime initiative
• (results) RH engineers have produced the vast
  majority of the implementation
• (technical expertise) realtime hits the most
  core/sensitive kernel areas
• (vision) realtime capabilities continue to evolve
• (product delivery support) its the RHEL guys
• (completeness) not just a kernel a complete
  realtime stack
• (partnerships) the only realtime java certified
  platform w/ IBM

40
Additional Information
http//redhat.com/mrg Detailed technical MRG
Realtime whitepaper http//www.redhat.com/f/pdf/m
rg/mrg_realtime_whitepaper.pdf
41
(No Transcript)
42
Open Source Security Solutions Kevin
Unthank Senior Product Manager Red Hat Identity
Management Products
43
Why do organizations care about security?

• 2. Risk reduction
• (To protect money, data, reputation)

• 1. Compliance
• (Because they have to)
• FIPS201
• HSPD-12
• SOX
• PCI
• HIPAA
• GLB

44
Open source software is a security innovation

• 1. Open source means more eyes on the code and
  therefore less security bugs
• 2. Open source means rapid response to any
  vulnerabilities

Time from a critical issue being known to the
public until the day that a fix is available via
RHN Red Hat Enterprise Linux 4, Feb 2005-Feb 2006
45
Open source software delivers security innovation

• 3. Security features
• NX emulation
• Address space randomization (ASLR)
• Position Independent Executables (PIE)
• Update signing
• Module signing
• Address space randomization for vDSO
• Restricted access to kernal memory
• Heap memory checks
• Fortify Source
• ELF Data Hardening
• Stack Smashing protection (Canary values)
• Pointer encryption
• Memory Protection
• CVE compatible
• OVAL compatible
• SELinux

• 4. SELinux
• Granular policy based control over a program's
  access to data and the kernal resources.
• Developed w/ NSA and open source community
• Transparent to applications and users
• RHEL 5 All system space locked down
• SELinux partner program
• EAL4/CAPP/LSPP/MLS

46
SELinux in detail
47
Common Criteria, MLS LSPP

• NIAP/Common Criteria
• Red Hat Enterprise Linux 4 EAL 4/CAPP (October
  2005)
• Red Hat Enterprise Linux 4 EAL4/LSPP (February
  2006)
• Red Hat Enterprise Linux 5 EAL4/CAPP/LSPP/RBAC
  (June 2007)

• Sensitivity Levels

• Categories
• Need to know

48
Red Hat Efforts

• NSS Provides FIPS 140-2 certified encryption

Red Hat Certificate System
49
NSS Architecture Diagram
S/MIME
SSL
Certificate library
Crypto device management
FIPS 140 validated S/W crypto
Hardware security module
Hardware crypto accelerator
Smart cards
50
Trusted Platform Module

• Planned for inclusion in next minor release of
  RHEL (5.2)
• What functionality would you like to see?
• What functionality would you use?

51
Linux Unified Key Setup (LUKS)

• New in RHEL 5
• Data-at-rest encryption
• FIPS 140-2 (using NSS)
• Works with device-mapper

52
Information Assurance Policies
53
Path to initial compliance

• Scripting
• Copious amounts of scripting
• GEN004000 (G633) This prevents non-root user
  from running tracerouteecho Locking down
  GEN004000chmod 700 /bin/traceroutechmod 700
  /bin/traceroute6echo GEN004000 Complete
• Times 100 or so
• justin_at_taco ks wc -l rhel5-desktop-baseline-1.7
  .cfg 1166 rhel-5-desktop-baseline-1.7.cfg

• Centralized config file version management
• RHN Satellite
• Other tools
• CFEngine
• CVS
• Subversion
• Third-party Utilities
• Bastille
• Security Blanket
• By hand
• Torture for x gt 1

54
NIST Standards-based work

• Security Content Automation Protocol (SCAP)
• Open Vulnerability and Assessment Language (OVAL)
• Red Hat currently utilizes OVAL
• ltdefinitionsgt ltdefinition
  id"ovalcom.redhat.rhsadef20070555"
  version"201" class"patch"gt ltmetadatagt
  lttitlegtRHSA-20070555 pam security, bug fix,
  and enhancement update (Moderate)lt/titlegt
  
• Extensible Configuration Checklist Description
  Format (XCCDF)
• Enumeration for configuration requirements
• DISA FSO committed to deploying STIG as XCCDF
• Others working with NIST
• Security policy becomes one file

55
Audit

• audictctl -a exit,always -S mknod -F success0

56
Why do organizations care about security?

• 3. Increase efficiency of IT
• (And therefore save costs)
• Many security solutions
• - Collect, centralize, and analyze data
• - Enable centralized management

• 4. Enable their business
• (And bring in new revenue streams)

Internet SSL ---------------
NAS
RADIUS
LDAP
NAS
RADIUS
x50
x50
x5
57
What does Red Hat Directory Server provide?

• Centrally store vital security data
• Identity
• Username, data, password, organization, groups
• Machine name, groupings
• Synch info with Microsoft Active Directory
• Policy
• Application Settings
• User Profiles
• Access Control Information
• Directory not a database
• Read optimized
• Organized around users, machines, and policy
• LDAP
• Manage this data
• GUI or command line

• Make security data highly available
• Replicate
• Authenticate users
• Widely supported OS access through NIS or PAM
  gateway
• Supports Kerberos via SASL
• Integrated support for X.509 certificates
• Can call out to databases, legacy systems via
  plug-in API
• Control access at a fine level
• Using external criteria like type of connection,
  day of week/time, hostname/IP
• Using groups (engineering) or roles
  (managers)

58
What does Red Hat Certificate System provide?

• Introduction
• System for managing certificates
• Create, provision, store, revoke
• Standards based
• Use public key cryptography
• Common Criteria Certification
• Authentication of users
• Replaces password
• Certificate put on smart card, USB
• Used to prove identity
• Integrated with RHEL
• Integrated with Windows

• Authentication of machines
• Machine has a certificate
• Uses it to prove identity to other machines
• Encryption
• Prevent wrong person from viewing
• Certificates used to create secure communication
  channel
• Certificates used to encrypt data
• Signatures
• Prevent anyone from tampering
• Certificate used to sign email

59
Smart Cards
60
Enterprise Linux 5 System Login

• Smart card login installed and available on every
  single instance of Red Hat Enterprise Linux 5
• Easily configurable with standard desktop GUI
• Advantages
• Multi factor authentication strong credentials
• System has to trust issuing authority
• System checks cert validity with OCSP server
• Drawbacks
• Disconnected operation
• Doesn't provide single sign-on

61
PKI and Kerberos Independently Successful

• PKI
• Smart card authentication
• Web services
• TLS, SSL
• Encryption
• Signing
• Data integrity
• Non Repudiation
• Asymmetric keys

• Kerberos
• System Login
• Secure Filesystem access
• NFSv4, CIFS
• Email server access
• Printing
• Symmetric keys

62
Kerberos PKINIT
Authentication Server
x509 Certificate
Encrypted Ticket Granting Ticket
Ticket Granting Server
Ticket Granting Ticket
Service Ticket
Service Ticket
Kerberized Service

• Enterprise Single Sign-on
• Strong authentication with strong credentials

63
Security Information Situation Today

• Many security and security management
  applications store and manage their own vital
  security information
• Identity
• Policy
• Audit
• Difficult to analyze across applications, so
  organizations can't
• Form a full picture of their security stance
• Comply with government regulations
• Protect themselves sufficiently
• Efficiently enable their operations
• Example Identity silos
• Example gt problem for Policy, Audit

64
What is needed?

• Vital security information (IPA) should be
• Open (You own it)
• Inter-operable
• Manageable
• Need a way to make it possible for vital security
  information
• Identity
• Policy
• Audit
• to enable the freedom and efficiency of next
  generation IT infrastructure

To enable this Maximize
freedom Maximize efficiency
65

• Project
• Open Source
• www.freeipa.org
• Started and contributed to by Red Hat
• Open to all
• IPA Identity, Policy, Audit

• Big vision
• Start with centralized user identity management
  for UNIX/Linux
• Add robust, shared sense of machine, service and
  data identity
• Provide centrally managed admin access control
  for UNIX/Linux
• Give ability to externalize policy and add to it
  easily
• Add centralized audit
• With this you can enable flexible
  cross-enterprise policy and rational audit

66

• IPAv1 (February target) will provide
• Single Sign on for users
• Tie together Directory and Kerberos
• User Kerberos ticket for SS) to UNIX/Linux,
  JBoss, other apps
• Centralized authentication point for IT
• Unite Directory, Kerberos, RADIUS servers, SAMBA
• From Apps, UNIX/Linux, VPNs, WLANs
• Easy for IT to set up, migrate to, and manage
• Simple IPA install
• Intuitive web interface, Command line
• Tools migrate from NIS
• Key Data replicated via Directory
• Process identity via a Kerberos principal

67

• IPAv2 (July target) will provide
• Identify and group machines, Vms, services
• Simplified service authentication and
  establishment of secure communication
• Machine identity via Kerberos, certificate
• Process identity via Kerberos principal
• Management of machine certificate
• Centrally managed access control
• Extensible policy framework
• Set policy of which users can access which apps
  on which machines
• Centrally managed scoped admin control
• Central audit database
• Centrally audit security event, logs, keystrokes
  (?), compliance with lockdown

68
Resources

• STIG Kickstart Script
• Civilian http//people.redhat.com/jnemmers/STIG/
  
• DoD http//ossg.disa.mil/mss/dodbastille/src/ks/
  
• DCID 6/3 PL3 Kickstart Script
• Email mstlaure_at_redhat.com
• SCAP
• http//nvd.nist.gov/scap.cfm
• Red Hat OVAL
• http//people.redhat.com/mjc/oval/
• NSS FIPS 140-2
• http//www.mozilla.org/projects/security/pki/nss/f
  ips/
• FreeIPA
• http//www.freeipa.org
• Government-focused security mailing list
• http//www.redhat.com/mailman/listinfo/gov-sec

69
(No Transcript)