Transcript Linux Virtual Server

Applying a Multi-level Security Mechanism
to a Network Address Translation Scheduler
Arthur McDonald
Computer Science Department
East Stroudsburg University
Outline






Introduction
Multi-Level Security Basics
Linux Virtual Servers
Proposed Algorithm
Implementation and Experiments
Results and Conclusions
Introduction





Recent Security Threats
Need to protect data on distributed systems
Linux Virtual Servers
Load Scheduling
Multi-Level Security
Multi-Level Security


Information with different sensitivities to be
stored on same system
Information is processed with users having
different security classes
–

Prevents users from accessing info for which they
are not cleared
Example on Next slide
MLS Example

Data assigned 4 security classes or levels:
–
–
–
–

Level 1 – CLASSIFIED access
Level 2 – SECRET access
Level 3 – UNCLASSIFIED access
Level 4 – No access
Clearances are hierarchical
MLS Properties – Access Control



Control what users can read, write or
execute files
System must also make decisions about
access control
Two types:
–
–
Discretionary Access Control (DAC)
Mandatory Access Control (MAC)
Discretionary Access Control


Restricts access based on the identity of the
user
Three basic types of access:
–
–
–
Read – User can open and view the data in
file/directory
Write – User can open and write data to the
file/directory
Execute – User can execute the file

Relevant only to executables
Discretionary Access Control


Owner makes access decisions
Typically three categories:
–
–
–
Self: Owner of the data
Group: A set of users on the system
Public: All users of the system
Mandatory Access Control



Used in systems with extremely sensitive
data
All objects (files, directories, etc…) and
subjects (users) are assigned a sensitivity
level.
Subject’s sensitivity level specifies objects it
has access to.
Mandatory Access Control

Two parts to label: Classification and a set of
categories
–
Classification is hierarchical

–
DOD uses Top Secret, Secret, Confidential and
Unclassified
Categories are non-hierarchical – represent areas
of information in the system

Subject with highest classification level may not mean
they are cleared to access all data
MLS Properties – Information Flow

Three Models:
–
–
–
Bell-LaPadula
Biba
Clark-Wilson
Bell-LaPadula Model





Linear model
User with security level b can READ objects
at level a iff a<=b
User at level b can write objects at level c iff
c>=b
Higher access can read from lower level and
lower access can write to higher levels
Insures data confidentiality
Bell LaPadula Model
Level d
Level c
Write access
only
Read-Write access
Level b
Level b
resources
Read access
only
Level a
Biba Model



Opposite of Bell-LaPadula
Users at level b can write to level a iff a<=b
and level b can read from level c iff c>=b
Insures data integrity
Biba Model
Level d
Level c
Read access
only
Read-Write access
Level b
Level b
resources
Write access
only
Level a
Clark Wilson Model



Similar to Biba, with one more constraint
Task is separated into duties
Ensures integrity rules are not disobeyed
Linux Virtual Servers



What is an LVS?
Why use them?
How is it done?
Linux Virtual Servers – What?



Cluster of computers connected by fast
network
Cluster “appears” to be a single machine
Service requests from incoming clients
–

HTTP, FTP, telnet, etc...
Minimum requirements
–
–
1 Director machine
2 or more Realservers
Linux Virtual Servers – What?
Client
Internet
Director
Network
Realserver 1
Realserver 2
Realserver N
Linux Virtual Servers – Why?


Need for fast, reliable servers
Three requirements:
–
–
–
Incremental Scalability
24x7 Availability
Cost-effectiveness
Linux Virtual Servers – Why?

“Old” way – single machine
–
–
Need to upgrade when load becomes too much
Add faster CPU, more RAM, other hardware…

–
Complex and expensive
New machine can also become overloaded
Linux Virtual Servers – Why?




LVS’ satisfy all the requirements
Scalability – Add/Remove machines to
cluster easily
Availability – Services are backed by multiple
machines – One goes down, not a problem
Cost effective – No “supercomputer” to
upgrade; simply add PCs
Linux Virtual Servers – How?

Network director and realservers together
–
–

Two IPs for director
–
–

Typically star topology network
Realservers are part of private network
Real IP: IP address for internal network
Virtual IP: Address that clients see
Services are assigned to the director, along
with port number and scheduling algorithm
Linux Virtual Servers – How?


Director waits for connections
Connection received:
–

Call scheduling function to determine what
realserver to forward data to
Three forwarding methods:
–
–
–
Direct Routing
IP Tunnelling
Network Address Translation
Linux Virtual Server – How?

Load Scheduling Algorithms
–
–
–
–
–
Round Robin
Weight Round Robin
Least Connection
Weighted Least Connection
Destination/Source Hash Scheduling
MLS Load Scheduling






Distribute load across realservers based on
security levels
Security level determined by client’s IP
address
Three security levels: A, B and No Access
Level A forwarded to Realserver 1
Level B forwarded to Realserver 2
No Access – Data is dropped
MLS Load Scheduling


Code developed based on LVS schdeuling
algorithms
Compiled directly into the kernel
–
Can also be compiled as a module
MLS Load Scheduling


Init, update and finished function
Two main functions:
–
–
ip_vs_mls_schedule
ip_vs_mls_get_security_level
MLS Load Scheduling

Problems:
–
–
File I/O in Kernel Space
Dotted decimal string to unsigned int conversion
of IP addresses
Implementation

Hardware:
–

Four Intel Pentium machines connected by hub
Software:
–
–
–
–
Director: Red Hat 7.0
Realserver 1: Red hat 7.0 kernel 2.2.16, Apache
Realserver 2: Mandrake 7.1, Apache
Client: Windows XP, Internet Explorer
Implementation

Installing LVS
–
–
–
–
–
–
Obtain “fresh” kernel from www.kernel.org
Patch kernel with the LVS code
Configure the kernel using xconfig
Compile and install modules
Compile kernel
Test the new kernel
Implementation

IPVSADM
–
–
–
Administration program for LVS
Used to set up service
Add realservers to LVS
Experiments

Attempt to connect to the realserver
–
–
–
Test Case 1 – Client IP address set to Level A
access
Test Case 2 – Client IP address set to Level B
access
Test Case 3 – Client IP address set to No Access
Future Work


Improve algorithm for scalability
Design an admin tool for easy
addition/deletion of client IP address/security
levels
Conclusions



Project is a good initial step in research
towards MLS in Linux Virtual Servers
More work needs to be done, especially in
the current global climate
Future looks bright for the LVS project