Open Source Development Labs

richnessokahumpkaΔιακομιστές

9 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

141 εμφανίσεις

Open Source

Development Labs

Carrier Grade Linux
Security Requirements
Definition

Version 3.1

(
Working

Draft Version


1
8

April

2005)



Prepared by the Carrier Grade Linux
Specifications Subgroup






Open Source Development Labs, Inc.

127
25

SW Millikan W
ay, Suite 400

Beaverton, OR 97005

USA

Phone: +1
-
503
-
626
-
2455




Carrier Grade Linux Security Requirements Definition Version 3.1 Public Draft

Page
2


Carrier Grade Linux Security Requirements Definition Version 3.1 Public Draft

Page
3

Copyright (c) 200
5

by The Open Source Development Labs, Inc. This material may be
distributed only subject to the terms and conditions set forth in the Open Publication
License, v1.0 or la
ter (the latest version is available at

http://www.opencontent.org/opl.shtml
).
Distribution of substantively modified versions of
this document is prohibited without the explicit permission of the copy
right holder.

Other company, product or service names may be the trademarks of others.

Linux is a Registered Trademark of Linus Torvalds.


Contributors
to

the
Security
Requirements Definition

include
(in alphabetic order)
:


* Matt Anderson (HP)

* Joseph Cih
ula

(Intel)

* Gé Weijers

Chris Wright
(OSDL)


*

S
pecification editor


Comments on the contents of this document should be sent to
cgl_discussion@osdl.org


Carrier Grade Linux Security Requirements Definition Version 3.1 Public Draft

Page
4



References

................................
................................
................................
...........................
5

1

Introduction

................................
................................
................................
.....................
6

2

Requirements Definitions

................................
................................
...............................
6

Security Requirements

................................
................................
................................
......
7

SEC 1.0 Access Control

................................
................................
..............

9

SEC 1.1 Generic Kernel Security Modules

................................
................

9

SEC 1.2 Process Containment using a Chroot
-
type Mechanism

................

9

SEC 1.3 Process Containment using a MAC based Mechanism

................

9

SEC 1.3 Process Containment using a MAC based Mechanism

................

9

SEC 1.4 Buffer Overflow Protection

................................
..........................

9

SEC 1.5 Ac
cess Control List Support for File Systems
..............................

9

SEC 2.0 Authentication

................................
................................
..............

9

SEC 2.1 Generic Authentication Modules

................................
..................

9

SEC 2.2 Password Integrity Checking

................................
......................

10

SEC 3.0 Auditing

................................
................................
......................

10

SEC 3.1 Log Integrity
and Origin Authentication

................................
....

10

SEC 3.2 Secure Transport of Log Information

................................
.........

10

SEC 3.3 Periodic Automated Log Analysis

................................
..............

10

SEC 3.4 Real Time Automated Log Analysis

................................
..........

10

SEC 4.0 Network Confidentiality and Integrity

................................
.......

10

SEC 4.1 IPSec for IPv4 and IPv6

................................
.............................

10

SEC 4.2 Support for IKE for IPv4 and IPv6

................................
.............

10

SEC 4.3 PK_KEY Support

................................
................................
.......

10

SEC 5.0 File Integrity Checking

................................
...............................

10

SEC 6.0 PKI and SSL Support

................................
................................
.

10

SEC 6.1 PKI Support for Applications

................................
.....................

10

SEC 6.2 SSL/TLS Support for Applications

................................
............

10

SEC 6.3 PKI Certificate Authority (CA)

................................
..................

10

SEC 7.0 Resource Management

................................
...............................

10

SEC 7.1 Memory Limits

................................
................................
...........

10

SEC 7.2 Fi
le System Quotas

................................
................................
.....

10

SEC 7.2 File System Quotas

................................
................................
.....

10

SEC 7.2 File System Quotas

................................
................................
.....

10

SEC 7.2 File System Quotas

......................

Error! Bookmark not defined.

SEC 8.0 Trusted Platform Module (TMP) Support

................................
..

10

3

Security Roadmap

................................
................................
................................
.........
11

Appendices

................................
................................
................................
........................
12

References

Background information useful to readers of this document can be found in the following
places:

Open Source Development Labs (OSDL) home page:
http://www.osdl.org

The Carrier Grade Linux web page on the OSDL Web site:
http://www.osdl.org/projects/cgl

The OSDL “Requirements Definition, Version 1.1”
:

http://www.osdl.org/docs/cgl_requirements_definition_11.pdf


The OSDL “Requirements Definition, Version
2
.
0

:

http://www.osdl.org/docs/carrier_grade_linux_requirements_definition___version_20
.pdf

CGL Requirements Definition V2.0

Version 0.28




6
/
31

1

Introduction

Past OSDL Carrier Grade Linux technical documents have contained all requirements in a single
document. For OSDL CGL v3.
1

draft relea
ses, we are releasing them as more granular sections,
roughly split on functional boundaries. This document contains the
security

section
, the anticipated set
of sections to be released are in this table.

1.

APIs/Specifications/Standards (aka, “Standards”)


牥晥牥湣e猠瑯⁵獥晵氠fn搠
湥ce獳sry⁥x楳i楮i⁳瑡湤 牤猠r湤⁩湴e牦ace⁳ ec楦楣a瑩潮猬⁥⹧⸬⁐体f堬uf䕔cⰠI瑣t



Availability


畳u晵氠a湤n湥ce獳sry⁦畮 瑩潮o汩ty⁦潲o
獩湧汥潤e

a癡楬a扩b楴y a湤n
牥c潶ory.



Clustering


畳u晵氠f湤ece獳sry⁣潭灯湥湴猠o漠扵楬搠
a⁣汵獴e牥搠獥琠潦t
楮摩癩摵慬⁳y獴e浳⸠⁋my 瑡t来琠t猠s汵獴e物rg⁦潲⁨ g栠hva楬a扩b楴yⰠI汴桯hg栠汯慤
-
balancing and performance are secondary aims. There is recognition that “one
size fits all” is not achievable, so not all features will always be used to
ge瑨e爮



Hardware


畳e晵氠f湤ece獳sry⁨ 牤睡re
-
獰sc楦楣⁳異灯i琬⁷桥re⁩ ⁡晦ec瑳⁴桥
ex灥c瑥搠tar物r爠潰e牡瑩ng⁥湶楲潮ne湴n



Performance
-

useful and necessary features contributory to adequate performance
of a system, e.g., real
-
time capabilities, and
also base OS components for
supporting performance tools (but not the tools).

6.

Security
-

useful and necessary features for building secure systems. There is
recognition that “one size fits all” is not achievable, so not all features will always
扥⁵獥搠瑯
ge瑨敲.



Serviceability


畳e晵氠fn搠湥ce獳sry⁦ a瑵牥猠景爠re牶楣楮g⁡湤慩湴慩湩n朠g
sy獴敭Ⱐs湤nc潶orage映 潯汳⁴桡琠獵灰潲琠獥牶楣ea扩b楴y.

周q獥⁳ c瑩潮猠o牥⁢ 楮g 摥癥汯灥搠楮⁰lra汬e氠慮l⁶ 物潵猠摲a晴猠潦 eac栠睩汬⁢ ⁲ 汥lse搠潮d
楮摥灥湤n湴⁳捨n
摵de献

2

Requirements

Definitions

The availability

requirements define capabilities that are related to single

system availability. These
requirements apply to the carrier grade Linux operating system environment.

This document

presents both CGL requirement
s and CGL roadmap material.

Requirements are defined
as necessary for a CGL system.

Roadmap items are provided to highlight possible future

requirements.

Each requirement is

described by two header fields and one descriptive text

field.

Header fields

ID

-

Unique identification code associated with a requirement

Name

-

Short/simple description of the requirement

Text fields

Description

-

Detailed description of the requirement

CGL Requirements Definition V2.0

Version 0.28




7
/
31

Security
Requirements


Security requirements should flow from a set of defined se
curity objectives for CGL systems. These
objectives should, in turn, be derived from the intersection of the set of assumptions that we are making
about these systems, their use, and their environment; the security policies that such system should
adhere
to; and the expected threats and vulnerabilities that such systems will be exposed to. Thus
,

the
security requirements
will be firmly rooted in sound security practices rather than arbitrarily chosen by
the specification authors.


This practice and the te
rminology borrows heavily from [CSPP
-
OS03], an
example Common Criteria profile for COTS5 operating systems.

A full explanation of these a
ss
umptions, policies, threats, and objectives, as well as the groundwork
upon which this process is based, can be found

in the appendix of this document. A brief explanation
of each of the objectives from the appendix is given below so that the reader can better understand the
origin of the requirements and their references to the objectives that each satisfies.

The term

“TOE”
, as
used in the naming of objectives, means Target Of Evaluation and is the terminology used for the
system of interest by the Common Criteria.

The following are the security objectives that are met by one or more of the requirements:

O.ACCESS
-
NON
-
T
ECHNICAL


The environment must provide
sufficient protection

against non
-
technical attacks by authenticated users for non
-
malicious purposes.

O.DETECT
-
SOPHISTICATED


The environment must provide the ability to detect sophisticated
attacks and the result
s of such attacks (e.g., corrupted system state).

O.ENTRY
-
NON
-
TECHNICAL: The environment must provide sufficient protection against non
-
technical attacks by other than authenticated users.

O.INFO
-
FLOW


The environment must ensure that any information flo
w control policies are enforced
-

(1) between system components and (2) at the system external interfaces.

O.PHYSICAL


Those responsible for the system must ensure that those parts of the system critical to
security policy are protected from physical atta
ck that might compromise IT security.

O.ACCESS
-
TOE


The system must provide public access and access by authenticated users to those
resources and actions for which they have been authorized.

O.ACCOUNT
-
TOE


The system must ensure, for actions under its c
ontrol or knowledge, that all users
can subsequently be held accountable for their security relevant actions. It is anticipated that
individual accountability might not be achieved for some actions.

O.AUTHORIZE
-
TOE



The
system

must provide the ability to

specify

and manage user and system
process access rights to individual

processing resources and data elements under its control,
supporting the

organization’s security policy for access control.

O.AVAILABLE
-
TOE


The system must protect itself from unsoph
isticated denial
-
of
-
service attacks.

O.BYPASS
-
TOE


The system must prevent errant or non
-
malicious, authorized software or users
from bypassing or circumventing security policy enforcement. NOTE: This objective is limited
to ‘non
-
malicious’ because CSPP
-
OS controls are not expected to be sufficient mitigation for
the greater negative impact that ‘malicious’ implies.

CGL Requirements Definition V2.0

Version 0.28




8
/
31

O.DETECT
-
TOE


The system must enable the detection of specific insecurities.

O.ENTRY
-
TOE


The system must prevent logical entry to itself u
sing unsophisticated, technical
methods, by persons without authority for such access.

O.KNOWN
-
TOE


The system must ensure that, for all actions under its control and except for a well
-
defined set of allowed actions, all users are identified and authentic
ated before being granted
access.

O.OBSERVE
-
TOE


The system must ensure that its security status is not misrepresented to the
administrator or user. This is a combination of prevent and detect.

O.RECOVER
-
TOE


The system must provide for recovery to a sec
ure state following a system
failure, discontinuity of service, or detection of an insecurity.

O.RESOURCES


The system must protect itself from user or system errors that result in shared
resource exhaustion.

O.APPLICATION
-
TOOLS


The system must provide
a reasonable, up
-
to
-
date set of security tools
and libraries for use by applications.

O.ACCESS
-
MALICIOUS


S
ystem
and environmental
controls are required to sufficiently mitigate
the threat of malicious actions by authenticated users.

O.DETECT
-
SYSTEM


The

system, in conjunction with other IT in the system, must enable the
detection of system insecurities.

O.NETWORK


The system must be able to meet its security objectives in a distributed environment.

O.ENTRY
-
SOPHISTICATED


The system and environment mus
t sufficiently mitigate the threat of
an individual (other than an authenticated user) gaining unauthorized access via sophisticated,
technical attack.

O.CONTAINMENT


The system and environment must provide the ability to constrain the effect of a
securit
y failure of an application to that application.

The following security objectives are not met by any requirements:

O.RECOVER
-
TOE, O.RECOVER
-
SYSTEM


Fail
-
secure is not something that OSDL CGL can
provide.

O.COMPLY


There are many regulations that might a
pply to OSDL CGL. It is not the responsibility
of this specification to enumerate requirements to conform to this myriad of regulations.

O.DUE
-
CARE


It is the responsibility of the administrative personnel to properly secure and maintain
a system.

O.MANA
GE


It is the responsibility of administrative personnel to properly secure and maintain a
system. This includes periodic audits of system configuration (not log analysis). However, no
such software is being required by OSDL CGL.

O.OPERATE


Mostly this

is the responsibility of administrative personnel. Secure default
configuration
settings
will not be listed in this specification.

CGL Requirements Definition V2.0

Version 0.28




9
/
31

O.DENIAL
-
SOPHISTICATED


OSDL CGL is not directly able to mitigate most denial of service
attacks, as mitigating them would

require redesign of protocols and interfaces.

Requirements are generally arranged according to priority. However, if a requirement summary is
followed by sub
-
requirements with different priorities, the requirement summary and sub
-
requirements
are placed a
t the priority level of the highest priority sub
-
requirement.














ID

Name

SEC.1.0

V2.0:
-

Access Control

Description:

OSDL CGL specifies that carrier grade Linux shall provide access control
mechanism support beyond the
mechanisms commonly supported on Posix/SUSv2/SUSv3
compliant systems.

Objectives Satisfied:


O.ACCESS
-
NON
-
TECHNICAL, O.INFO
-
FLOW, O.ACCESS
-
TOE,
O.AUTHORIZE
-
TOE, O.AVAILABLE
-
TOE, O.BYPASS
-
TOE, O.ENTRY
-
SOPHISTICATED,
O.CONTAINMENT

ID

Name

SEC.1.1

V2.0:
A
CC.1.0

Dynamic Kernel
Security Module

Mechanism

Description:

OSDL CGL specifies that carrier grade Linux shall support an interface that allows
the addition of new access control policy implementations
to the kernel without requiring patching
or recompilation. This support must allow for the dynamic loading of such policy implementations.
The mechanism must govern all of the kernel objects. Note that this requirement does not specify
any particular pol
icies.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC References:

Linux Security Module: http://lsm.immunix.org/

ID

Name

SEC.1.2

V2.0:
-

Process Containment using a Chroot
-
type Mechanism

Description:
OSDL CGL specifies that carrier grade Linux shall provide

support for constraining
the privileges and access to system resources of a process independently of the user account
under which the process runs by limiting a process’ access to
a subset of the file system
hierarchy. This limits the effects of a security compromise of a process (such as a buffer overflow
exploit). Note that the traditional ‘chroot’ mechanism can be circumvented by processes that run
as ‘root’.

Objectives Satisfie
d:

O.CONTAINMENT

PoC References:

BSD Jail: http://sourceforge.net/projects/linuxjail/

ID

Name

SEC.1.3

V2.0:
-

Process Containment using
a MAC
-
based Mechanism

Description:
OSDL CGL spe
cifies that carrier grade Linux shall provide

support for constraining
the privileges and access to system resources of a process independently of the user account
under which the process runs, using a Mandatory Access Control mechanism. This limits the
e
ffects of a security compromise of a process (such as a buffer overflow exploit) even if it running
as root

Objectives Satisfied:

O.CONTAINMENT

PoC References:

LIDS: http://www.lids.org/

SubDomain: http://www.immunix.org/subdomain.html

Security
-
Enhanced L
inux: http://www.nsa.gov/selinux

Domain and Type Enforcement (DTE) for Linux: http://www.cs.wm.edu/~hallyn/dte/

Distributed Security Infrastructure (DSI): http://www.sourceforge.net/projects/disec/

GRSecurity: http://www.grsecurity.net/

ID

Name

SEC.1.3.
1

V2.0:
-

MAC
-
based Policy Administration Tools

Description:
OSDL CGL specifies that carrier grade Linux shall provide tools for the
administration of MAC
-
based access control policies.
These tools should facilitate the creation,
maintenance, and management of policies. The tools should provide both commandline and
graphical interfaces.

Objectives Satisfied:

O.CONTAINMENT,
O.APPLICATION
-
TOOLS

PoC References:

Tresys:

http://www.tresys.com/selinux/selinux_policy_tools.html

SELinux Analysis Tools (SLAT)
, Polgen:

http://www.mitre.org/tech/selinux/

ID

Name

SEC.1.4

V2.0:

ACC.3.0

Buffer Overflow Protection

Description:
OSDL CGL specifies that carrier grade Linux shall provide

at least one mechanism
to protect against the exploitation of software bugs that exploit the lack of boundary checking in
many programs and give a
n attacker some access to a task’s address space by writing outside of
buffer bounds.

Objectives Satisfied:

O.ENTRY, O.ENTRY
-
SOPHISTICATED

PoC References:

PaX kernel Patch: http://pageexec.virtualave.net/

gcc extensions: http://www.trl.ibm.com/projects/s
ecurity/ssp/

exec
-
shield:
http://people.redhat.com/mingo/exec
-
shield/

Ingo Molnar’s NX patch:

http://people.redhat.com/mingo/nx
-
patches/QuickStart
-
NX.txt

ID

Name

SEC.1.5

V2.0:

ACC.4.0

Access Control List Support for File Systems

Description:
OSDL CGL specifies that carrier grade Linux shall provide

access control list (ACL)
capabilities on file systems that allow the specification of access rights for multiple users and
groups.

Note that

some restrictions may apply when ACLs are used with network file systems and backup
software.

Objectives Satisfied:

O.CONTAINMENT

PoC References:

ACL support is in 2.6 and above kernels for many file systems.

Linux ACLs project: http://oss.software.ibm.c
om/developerworks/patch/?group_id=35

SGI XFS patches:
http://oss.sgi.com/projects/xfs/

Patches for several kernels and file systems: http://acl.bestbits.at/

ID

Name

SEC.2.0

V2.0:
-

Authentication

Description:

OSDL C
GL specifies that Carrier Grade Linux shall provide secure authentication
and the ability to apply new authentication mechanisms.

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED, O.ENTRY
-
NON
-
TECHNICAL, O.ENTRY
-
TOE, O.KNOWN
-
TOE, O.ACCESS
-
MALICIOUS, O.ENTRY
-
SO
PHISTICATED

ID

Name

SEC.2.1

V2.0:
-

Generic Authentication Modules

Description:

OSDL CGL specifies that carrier grade Linux shall support a mechanism for
implementing new authentication mechanisms a
t the OS level. This support must allow for the
dynamic loading of such implementations. Note that this requirement does not specify any
particular authentication mechanisms.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC References:

Pluggable Authentica
tion Module (PAM):

http://www.kernel.org/pub/linux/libs/pam/

http://pam.sf.net

CGL Requirements Definition V2.0

Version 0.28




10
/
31

























ID

Name

SEC.2.2

V2.0:
AUT.1.0

Password Integrity Checking

Description:
OSDL CGL specifies that carrier grade Linux shall pro
vide tools to check passwords
to ensure they cannot be easily cracked. These tools shall support at least the DES cipher text
format and allow the user to specify rules for rejecting passwords.

Objectives Satisfied:

None

PoC References:

Pluggable Authenti
cation Module (PAM):

http://www.kernel.org/pub/linux/libs/pam/

http://pam.sf.net

is a prerequisite for the two PAM module projects below.

pam_passwdqc PAM module: http://www.openwall.com/passwdqc/

pam_cracklib PAM module:

http://www.kernel.org/pub/linux/li
bs/pam/

http://pam.sf.net

John the Ripper: http://www.openwall.com/john/

Software does not appear to be licensed, except that it is free, but donations are
allowed.

Crack
:
ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack

ID

Name

SEC.3.0

V2.0:
-

Auditing

Description:

OSDL CGL specifies that carrier grade Linux shall provide auditing mechanisms that
flag security
-
relevant events, alert a system administrator in real time, are hard to circumvent and
collect sufficient

information to act as a deterrent to insiders and an aid for forensics.

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED, O.ACCOUNT
-
TOE, O.DETECT
-
TOE,
O.OBSERVE
-
TOE, O.DETECT
-
SYSTEM

ID

Name

SEC.3.1

V2.0:
AUD.1.0

Log Integrity and Origin Authentication

Description:

OSDL CGL specifies that carrier grade Linux shall provide a mechanism to check
log files to ensure they have not been tampered with, even by (most) insiders (message integrity).
In add
ition, OSDL CGL specifies that carrier grade Linux shall provide a mechanism to verify the
source of a log message (origin authentication), and its timeliness (replay protection).

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED, O.ACCOUNT
-
TOE, O.DETECT
-
TOE,
O.OBSERVE
-
TOE, O.DETECT
-
SYSTEM

PoC References:

SDSC Secure Syslog: http://security.sdsc.edu/software/sdsc
-
syslog

Secure Auditing for Linux: http://secureaudit.sourceforge.net/

Modular Syslog (Msyslog): http://sourceforge.net/projects/msyslog

ID

Name

SE
C.3.2

V2.0:
AUD.2.0

Secure Transport of Log Information

Description:

OSDL CGL specifies that carrier grade Linux shall provide secure transport of log
information over a network to the log files. Th
e transport mechanism shall ensure that the
information remains confidential, cannot be tampered with, is not a replay of an earlier log
message, and originated at the source it claims to originate from.

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED, O.ACC
OUNT
-
TOE, O.DETECT
-
TOE,
O.OBSERVE
-
TOE, O.DETECT
-
SYSTEM

PoC References:

syslog
-
ng

+ stunnel
:
http://www.balabit.com/downloads/syslog
-
ng/


http://www.stunnel.org/

ID

Name

SEC.3.3

V2.0:
AUD
.3.0

Periodic Automated Log Analysis

Description:

OSDL CGL specifies that carrier grade Linux shall provide a mechanism for
periodically and automatically analyzing log files. This mechanism shall be ab
le to generate
reports if any suspicious or unrecognized log is detected.

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED, O.ACCOUNT
-
TOE, O.DETECT
-
TOE,
O.OBSERVE
-
TOE, O.DETECT
-
SYSTEM

PoC References:

Swatch: http://swatch.sourceforge.net/

Logwatch: http://www
.logwatch.org/

LogDog: http://caspian.dotconf.net/menu/Software/LogDog/

ID

Name

SEC.3.4

V2.0:
AUD.3.0

Real Time Automated Log Analysis

Description:

OSDL CGL specifies that carrier grade Linux shall
provide a mechanism for
automatically analyzing security relevant log information in real time. This mechanism shall be
able to generate alarms if criteria set by the system administrator are met.

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED, O.ACCOUNT
-
TO
E, O.DETECT
-
TOE,
O.OBSERVE
-
TOE, O.DETECT
-
SYSTEM

PoC References:

Prelude Hybrid IDS: http://www.prelude
-
ids.org/

ID

Name

SEC.4.0

V2.0:
-

Network Confidentiality and Integrity

Description:

OSDL C
GL specifies that carrier grade Linux shall provide mechanisms to provide
integrity and confidentiality of network transmissions to and from the system.

Objectives Satisfied:

O.NETWORK, O.ENTRY
-
SOPHISTICATED

ID

Name

SEC.4.1

V2.0:
CON.1.0

IP
s
ec for IPv4

and IPv6

Description:

OSDL CGL specifies that carrier grade Linux shall provide IPsec support to provide
network level confidentiality and integrity for IPv4 and IPv6. The implementation shall conform to
RFC 2
401, 2402, 2406 and any relevant algorithm. Specific RFCs, for example RFC 2451. Please
note that this requirement refers to ESP/AH, not to key management, which is addressed in a
separate requirement.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC Referen
ces:

IPSec is supported in Linux kernel 2.5.49 and higher.

OpenS/WAN: http://www.openswan.org/
ID

Name

SEC.4.2

V2.0:
CON.2.0

Support for IKE for IPv4 and IPv6

Description:

OSDL CGL specifies that carrier grade Linux shall provide an Internet Key
E
xchange (IKE) daemon to perform standards
-
based key exchange for IP
s
ec. The daemon shall
conform to RFC 2409. This key exchange mechanism will permit different im
plementations and
platforms to interoperate and is critical in many situations to securely perform IP
s
ec.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC References:

The Linux 2.5.49 and higher implementations work with KAME IKE daemon.

Open
S/WAN
:
http://ww
w.openswan.org/

racoon:
http://ipsec
-
tools.sourceforge.net/

ID

Name

SEC.4.3

V2.0:
CON.5.0

PF_KEY Support

Description:

OSDL CGL specifies that carrier grade Linux shall provide PF_KEY support (RFC
2367) for key manag
ement for the IPsec module and the IKE daemon. For full IPsec support,
PF_KEY must be extended to support IPsec specific features. As explicit standards for PF_KEY
policy and extensions have not been established, it is recommended that the extensions used
by
KAME in the NetBSD implementation be used for CGL.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC References:

The Linux 2.5.49 and higher implementations work with KAME IKE daemon, which
supports PF_KEY.

libipsec:

http://ipsec
-
tools.sourceforge.net/

ID

Name

SEC.5.0

V2.0:
CON.3.0

File Integrity Checking

Description:

OSDL CGL specifies that carrier grade Linux shall provide a mechanism to enable a
periodic checking of the integrity of files at user
-
level.
Files to be checked are both binary files,
which should not change after installation, and text files, such as configuration files, which may
change.

The implementation may involve adding a digital signature to the binary files.

File integrity checks shall

be able to be scheduled at any time of the day. The checking
mechanism shall be able to send alarms to security authorities when inconsistencies, such as
invalid signatures, are detected.

Objectives Satisfied:

O.DETECT
-
SOPHISTICATED

PoC References:

Trip
wire: http://www.tripwire.org and http://sourceforge.net/projects/tripwire

RPM Package Manager (RPM): http://www.rpm.org/

Advanced Intrusion Detection Environment (AIDE): http://www.cs.tut.fi/~rammer/aide.html

ID

Name

SEC.6.0

V2.0:
-

PKI and SSL Support

Description:

OSDL CGL specifies that carrier grade Linux shall provide Public Key Infrastructure
(PKI) and Secure Socket Layer (SSL) support.

Objectives S
atisfied:

O.APPLICATION
-
TOOLS

ID

Name

SEC.6.1

V2.0:
-

PKI Support for Applications

Description:

OSDL CGL specifies that carrier grade Linux shall provide basic PKI support, which
shall conform to the I
ETF PKIX standards, specifically RFC 2527, 3279 & 3280. Support for
processing Certification Revocation Lists (CRLs) is required, although a specified delivery
mechanism is not specified. HTTP/FTP (RFC 2585) is recommended at a minimum.

Objectives Satisfie
d:

O.APPLICATION
-
TOOLS

PoC References:

OpenSSL
:

http://www.openssl.org/

ID

Name

SEC.6.2

V2.0:
-

SSL/TLS Support for Applications

Description:

OSDL CGL specifies that carrier grade Linux shall provi
de basic SSL/TLS support,
which shall conform to the legacy SSL and IETF TLS standards.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC References:

OpenSSL
:

http://www.openssl.org/

ID

Name

SEC.6.3

V2.0:
CON.11.0

PKI Certificate Authority (CA)

Description:

OSDL CGL specifies that carrier grade Linux shall provide a basic PKI CA, which
shall conform to the IETF PKIX standards, specifically RFC 2527, 3279 & 3280. Support for the
management of Certificatio
n Revocation Lists (CRLs) is required. Certificate
Management/Request protocols are not a requirement.

Objectives Satisfied:

O.APPLICATION
-
TOOLS

PoC References:

OpenSSL
:

http://www.openssl.org/ plus one of:

OpenCA project: http://sourceforge.net/projects/
openca/

pyCA: http://www.pyca.de/

TinyCA (http://tinyca.sm
-
zone.net/

ID

Name

SEC.7.0

V2.0:
-

Resource Management

Description:

OSDL CGL specifies that carrier grade Linux shall provide support for limiting the
re
source usage of a user and processes.

Objectives Satisfied:

O.RESOURCES

ID

Name

SEC.7.1

V2.0:
-

Memory Limits

Description:

OSDL CGL specifies that carrier grade Linux shall provide support for per
-
process
limits

for
the use of system memory.

Objectives Satisfied:

O.RESOURCES

PoC References:

Linux kernels support limiting the amount of memory a process can allocate.

ID

Name

SEC.7.2

V2.0:
-

File System Quotas

Description:

OSD
L CGL specifies that carrier grade Linux shall provide support for per
-
user
quotas

for all supported file systems.

Objectives Satisfied:

O.RESOURCES

PoC References:

Linux kernels 2.0 and above support disk quotas.

ID

Name

SEC.7.3

V2.0:
-

Process Quotas

Description:

OSDL CGL specifies that carrier grade Linux shall provide support for per
-
user
quotas

on the number of processes which can be created.

Objectives Satisfied:

O.RESOURCES

PoC References:

Linux kernels 2
.
4

and above support process quotas.

ID

Name

SEC.7.4

V2.0:
-

Execution Quotas

Description:

OSDL CGL specifies that carrier grade Linux shall provide support for per
-
user
CPU
execution

quotas.

Objectives Satisfie
d:

O.RESOURCES

PoC References:

Linux kernels 2.
4

and above support execution.

ID

Name

SEC.8.0

V2.0:
-

Trusted Platform Module (TPM) Support

Description:

OSDL CGL specifies that, if and only
if it is installed and executing on a TPM
enabled platform, carrier grade Linux shall provide OS support for the TPM hardware, as defined
in TCG TPM Specifications. See HWM.2.0.

A TPM will provide physical security for the keys that it protects as well as

for data that it seals to
the platform.

Objectives Satisfied:

O.PHYSICAL

PoC References:

See HWM.2.0

CGL Requirements Definition V2.0

Version 0.28




11
/
31

3

Security Roadmap

This section attempts to capture promising technology directions in security. The

items listed here are
not current requirements, but

are considered to be desirable future

features.


<To be decided later>

CGL Requirements Definition V2.0

Version 0.28




12
/
31

Appendices


1.

Security Analysis


2

Introduction

This document is an attempt to help the discussion within the OSDL CGL technical work group about
security tools and facilities for the Lin
ux OS. A number of tools and facilities have been proposed and
incorporated in the CGL 2.01 specification. The intent of this document is to review the threats facing
CG applications, and help the discussion about what is needed to make Linux more resilien
t to attacks,
and help mitigate the security threats and associated business risks of fielding systems based on Linux.

3

Understanding the Problem

The telecommunications environment is very different from a general purpose computing environment.
This has ser
ious implications for the threat model we are going to use. The most salient differences are:



CGL systems do not have many user accounts, and these accounts do not reflect individual users.



CGL systems are configured through custom user interfaces, not tho
ugh shell access, which is often
unavailable.

One of the assumptions we are going to make about the environment is that administrators are trusted
and competent. This eases the requirement on the underlying Linux platform.

The major threat to the telco env
ironment is therefore unauthorized access to management and control
interfaces by outsiders. These outsiders can gain access by subverting the operating system or one of
the applications it is running. In the context of the CGL specifications we do of cour
se not have any
control over the applications manufacturers include on their products, but we can push for the inclusion
of tools and facilities that make the mitigation of these risks easier. This is what we're trying to do in
this document.

4

Selecting Sec
urity Tools

How should we go about selecting security tools and extensions to be included in the Linux kernel
and/or in Linux distributions? In section 2 we provided some justification for limiting this analysis to
threats that can be mitigated by the oper
ating system. The OSDL Security SIG has chosen to follow a
process that will create a security document closely related to Common Criteria Protection Profiles:

1.

identify the assumptions we are making about CGL systems, their use and their environment

2.

draft
a set of security policies we believe CGL systems need to adhere to

3.

identify the common threats and vulnerabilities CGL systems are exposed to

4.

derive a set of functional specifications that CGL systems should ideally implement

CGL Requirements Definition V2.0

Version 0.28




13
/
31

5.

try to come up with a coheren
t set of tools and extensions that implement the functional
specifications, using as many community resources as feasible.

Before we dive into this process in any detail we would like to try to list a few general principles we
should adhere to when selecti
ng our tools and extensions in step 5:

Relevance:
the tools must be relevant, i.e. implement the functional specification.

Correctness of Implementation:
our tools must faithfully implement the security model they're based
on.

Simplicity:
our tools should
be simple to deploy. Some tools have too many features, and some
libraries have overly complicated interfaces, which lead to errors in their application. Complexity is
the enemy of security, so we should try to stay away from it. Common uses should be easy

to
handle, and defaults should be sensible.

Robustness:
our tools should be hard to misconfigure, fail in secure ways, and produce useful error
messages when things go wrong.

Orthogonality:
it should ideally be possible to use our tools individually and i
n various combinations
when it makes sense, without conflicts or huge overlaps in functionality.

Interface Stability:
changes and additions to the Linux APIs should be done with backward
compatibility for both source code and binary code in mind.

Provision

of Defense
-
in
-
Depth:
if one security mechanism fails, another one may save they day. An
example of this is using a host
-
based (embedded) firewall to protect against unwanted access to a
service that was inadvertently enabled, or to protect against failure

of a perimeter firewall.

Designed for Testing: the availability of test suites for unit testing etc. would be highly
desireable
.

These principles should be obvious, but any Linux distribution contains many violations against them,
which can drive up the
TCO
1

of a system quite rapidly.

Before we dive into the somewhat formal and dry process of listing assumptions and policies and start
to introduce requirement we will go into telecommunications security in a bit more detail by looking at
the ITU
-
T X.805 sp
ecification.

5

ITU
-
T Recommendation X.805 Et. Al.

The ITU
2

has published many standards that are relevant to the security of telecommunications
systems. In some ways this makes our work easier, because we can defer to these standards for a lot of
the telecom
munications
-
specific security requirements, and limit ourselves to those issues related to the
security of the underlying operating system, in this case Linux.

We specifically defer to these standards for those components that are application
-
specific and
are not
considered part of an operating system. The CGL specification does for instance require support for
SSL/TSL and X.509 certificates, but we do not have to include these in our analysis because their use is
governed by existing ITU standards. It's im
material to our analysis whether an NEP decides to use an



1
Total Cost of Ownership

2
International Telecommunications Union

CGL Requirements Definition V2.0

Version 0.28




14
/
31

SSL implementation such as OpenSSL or one developed in
-
house. We will therefore concentrate on the
analysis of basic OS security functionality.

5.1

The X.805 security framework

X.805 defines security in

terms of two major concepts, layers and planes. The three layers are:



the infrastructure layer (security of routers, switches, servers, communications links, etc.)



the services layer (security of services offered to the customer, such as leased lines, e
-
m
ail, SMS)



the application layer (security of customer applications using services)

The planes are



the management plane (security of OAM&P
3
)



the control plane (security of signaling, i.e. Session creation and modification)



the end
-
user plane (security of e
nd
-
user data flows)

Layers and planes intersect, forming a 3 by 3 matrix. Orthogonal to this X.805 defines eight security
dimensions:



Privacy and data confidentiality



Authentication



Integrity



Non
-
repudiation



Access Control



Communication



Availability

These
dimensions touch each of the cells of the layers/planes matrix.

For brevity's sake we refer to the definitions in [ITU03].

Many of the issues addresses by X.805 are not relevant to our analysis, because they are outside the
scope of an operating system. So
me of the threats are relevant, and the operating system can be
instrumental in mitigating these threats.

5.2

Risks, Threats, and Vulnerabilities

In the end all discussion of security revolves around risk. Risks are created when a security
vulnerability is com
bined with the threat of it being exploited. In the common buffer overflow attack
scenario we have a vulnerability (the lack of
input validation

in
the

software) and a threat (the
attacker

using software that exploits the vulnerability), which creates the
risk of a successful attack. The risk
can be mitigated in different ways: we can remove the vulnerability by fixing the software, or remove
the threat by making it impossible to launch the attack, for instance by making the system inaccessible
to

the
attac
ker
.




3
Operations, Administration, Maintenance and Provisioning (a common abbreviation in telco documents)

CGL Requirements Definition V2.0

Version 0.28




15
/
31

This example shows that risks do not necessarily have to be mitigated in software, but that the
environment in which a system is embedded can also mitigate them.
This is an important point because
currently it is nearly impossible to construct system
s that are invulnerable to attack.
. We will therefore
have to make certain assumptions about the environment in which software and systems are being used.

5.3

Do Not Trust Your Software

Anyone who uses e
-
mail regularly has received e
-
mails containing viruses,
or has been affected by
systems being attacked by network worms. The software we use is far from perfect, and the
exploitation of a vulnerability can have major consequences for the functioning of our systems.

If we accept the premise that our software wil
l contain vulnerabilities, and that it is impractical to find
and remove all of them before we put it to use we will have to look at methods for lowering the risks
related to those vulnerabilities. Some methods could be:



Do not expose the system running th
e software to insecure networks.
This can be practical for
certain limited purposes, for instance controlling a power plant. In the telco environment one
could segregate network traffic from different security planes, which would eliminate the threat
of ou
tsiders attacking software operating in the management and control plane.



Use programming languages and development tools that provide overflow detection
, such as
the
gcc

compiler using the ProPolice extension. Most stack buffer overflows will result in th
e
premature termination of a program, which transforms the risk of a successful buffer overflow
attack into the risk of a service not being available.



Run the software using limited privileges
. A common approach is the use of 'chroot' jails, a
method of re
stricting a program's access to a very limited part of the file system. Another
approach is the use of a security manager that decides whether an application is allowed to
perform certain operations. A common example is the manager used to restrict Java br
owser
applets, which are not supposed to be able to access most resources on the system.



Use a DMZ network to isolate systems likely to be compromised
. The application and the
system running it may still be compromised, but the problem is somewhat containe
d.

The conclusion is that the solution to many security problems will be a combination of the correct
application of OS facilities, and a correct design of the environment in which the systems will function.

5.4

Applications Touching Multiple Planes

A particul
ar thorny issue exists where applications need to touch multiple security planes. Many telco
services can be provisioned remotely by the end
-
user. Many ISPs that offer domain hosting allow the
creation of new mailboxes by the customer, and the author can r
oute calls to his 5
-
digit work extension
to any telephone number in the world, using just a few clicks on a web page. Facilities like these create
a new set of risks, for example:



unauthorized rerouting of e
-
mail and telephone calls by disgruntled spouses
or unscrupulous
competitors



exploitation of vulnerabilities in software to 'jump' from one security plane to another, which can
lead to many types of risks

CGL Requirements Definition V2.0

Version 0.28




16
/
31

Mitigating these risks will require some forethought:



the users of these systems need to be properly

authenticated and authorized



information traveling between planes should pass though narrowly defined interfaces that protect
against unauthorized access to the control and management planes from the end
-
user plane. A
security failure in an exposed part o
f the system should not result in failure of the system as a whole.

Facilities that implement the second requirement in particular are not very widely spread. Possible
implementations could be:



running software on multiple hosts, with very limited connecti
vity between them.



running multiple processes on the same host, using operating system facilities to contain each
process in its own security domain.

This brings us to one of the most important questions for CG applications: how do we contain
processes tha
t can turn hostile?

5.5

Privilege Minimization and Fine
-
Grained Access Controls

Unix
-
like systems such as Linux share a few common security facilities:



discretionary access control using user IDs, group IDs, and file system privileges.



containment of processes

in 'jails', restricting access to a small part of the file system.

Some Unix
-
like systems provide additional facilities which can be useful under certain circumstances,
such as:



Access Control Lists: some access control policies are difficult to implement

with the classical Unix
access control mechanism. ACLs provide a more powerful mechanism to describe access rules. The
lack of users on typical CG equipment makes ACLs not overly useful.



Role Based Access Control: users of the system can be assigned 'role
s', which grant privileges to
resources. The role 'help desk' for example could include privileges to change passwords for non
-
administrative users. RBAC is most useful if there are many instances of the role, i.e. there are many
users with similar privile
ges. This is not commonly the case for CG systems.

It is questionable whether ACLs and RBAC (or other forms of Mandatory Access Control) are really
useful in the context of CGL. The following issues have to be dealt with:



system privileges in classical uni
x
-
like systems are of the all
-
or
-
nothing kind. The privilege to
access 'privileged' network ports cannot be separated from the privilege to override file system
access controls, access devices, and many other privileges. Many programs have to retain privil
eges
they do not need because of the lack of fine
-
grained privileges. The Linux kernel partially
implements the draft Posix.1e capabilities, but it is not integrated into file systems.



most access control mechanisms do nothing to restrict a process' access

to network resources.
Access control for network resources is very important, because it is necessary to limit access to
networks carrying control and management traffic to certain trusted processes only.



the all
-
or
-
none nature of the access control mecha
nism for TCP and UDP ports is too crude. It
should be possible to grant access to individual ports and IP addresses.

To mitigate risks precipitated by software design or implementation errors we will require a much more
fine
-
grained control over system pri
vileges. The common way to handle programs that need certain
CGL Requirements Definition V2.0

Version 0.28




17
/
31

privileges is to give them full privileges at start
-
up time and let the program drop all the privileges they
don't need. This causes a few problems: the privileges that need to be dropped are not

necessarily the
same on all unix
-
type systems, and there's a proliferation of privilege
-
manipulation code on the system.
It would be much better to approach this from the other side, and provide tools that allow the designer
or administrator to start soft
ware with the minimal set of privileges required.

Another issue is that Linux systems do not have a sufficiently fine
-
grained privilege model. It is for
instance impossible to restrict the use of a specific IP address and/or port range to a limited number
of
processes
4
. Ideally it should be possible to allow a specific process to bind to port 80 (WWW) on a
single interface. (As an aside: MLS implementations can be used to prohibit processes from accessing
network interfaces they do not need to access. This
does not address the port issue, though)

6

Security Environment

The following sections borrow heavily from [CSPP
-
OS03], an example Common Criteria profile for
COTS
5

operating systems. This document seems to be a good starting point because our intent is to
f
unctionally enhance a COTS platform (Linux).

6.1

Security Assumptions

In this section we identify our assumptions about the operating system (TOE or Target Of Evaluation in
Common Criteria jargon), and about its environment.

6.1.1

Security Assumptions
-

TOE


Name

As
sumption

Discussion

A.COTS

The TOE is constructed from near
-
term achievable off the shelf Linux
technology

This follows from the charter of
OSDL.

A.MALICIOUS
-
INSIDER

The TOE is not expected to be able
to sufficiently mitigate the risks
resulting from the

malicious abuse
of authorized privileges.

In CGL environments the primary
threats are network
-
based attacks,
so the focus is on this type of threat
(for now)

A.SOPHISTICATED
-
ATTACK

The TOE is expected to be able to
mitigate risks resulting from the
appl
ication of moderately
sophisticated attack methods
6

Especially Internet
-
facing CGL
applications are subject to network
-
based attacks, and should be more
resistant to attacks than general
-
purpose systems




4
The 'netfilter' firewall can filter t
raffic on userid, but it does not limit a rogue process from binding to a port.

5
Commercial Off The Shelf

6
Unlike the COTS draft CC profile .

CGL Requirements Definition V2.0

Version 0.28




18
/
31

Name

As
sumption

Discussion

A.APPLICATION
-
HOSTILE

The IT systems, of which the T
OE
is a part, is used to provide a limited
set of applications to an untrusted
network (not to provide shell access
to users at different trust levels)

We are moving away from general
-
purpose computing to application
servers in hostile environments.

6.1.2

Secur
ity Assumptions


Environment

Name

Assumption

Discussion

A.ADMIN

The security features of the TOE
are competently administered on an
on
-
going basis

It is essential that security
administration is both competent
and ongoing.

A.ADMIN
-
ONLY

Authenticated acc
ess to the TOE is
only provided to those charged with
maintaining the TOE and the
applications it provides.

CGL are not targeting general
-
purpose computing.

A.USER
-
NEED

Authenticated users (i.e.
administrators) recognize the need
for a secure IT environme
nt

This is likely to be the case in the
restricted environments of CGL,
because access is restricted to those
maintaining applications.

A.USER
-
TRUST

Authenticated users (i.e.
administrators) are generally trusted
to perform discretionary actions in
acco
rdance with security policies

This is likely to be the case in the
restricted environments of CGL
because access is restricted to those
maintaining applications.

A.NET
-
SEGREGATION

Network connections in the
management, control and end
-
user
planes are ade
quately segregated,
either by the use of physically
separate networks, or by the use of
cryptographic methods for
authentication, integrity verification
and data confidentiality.

The end user should not be able to
gain access to either the control or
manag
ement plane. The control
plane is sometimes accessible to 3
rd

parties, so it needs to be separate
from the management plane.

A.CLUSTER
-
SEGREGATION

If the TOE is part of a cluster the
intra
-
cluster communications
should be adequately segregated
from any ot
her traffic, either by
physical separation or by the use of
cryptographic methods for
authentication, integrity verification
and data confidentiality.

If this traffic is tampered with the
results are likely to be extremely
disruptive. A separate interconne
ct
is preferable.

CGL Requirements Definition V2.0

Version 0.28




19
/
31

Name

Assumption

Discussion

A.PROCESS
-
UNTRUSTED

Processes running on the TOE
cannot always be trusted to perform
their duties as designed, and may
(for instance after a security failure)
attempt to access resources it is not
meant to access.

It is often impossible
to run legacy
code in restricted environments
such as chroot jails. The TOE
should support a safe way to run
this type of code in such a way that
program bugs or vulnerability
exploits only have limited
consequences.





7

Organizational Security Policies

Name

Policy

Discussion

P.ACCESS

Access rights to specific data
objects are determined by object
attributes assigned to that object,
user identity, user attributes, and
environmental conditions as defined
by the security policy

Linux supports organizationa
l
policies that grant or deny access to
objects using rules driven by
attributes of the user (such as user
identity), attributes of the object
(such as permission bits), type of
access (such as read or write), and
environmental conditions (such as
time
-
of
-
day).

P.ACCOUNT

Users must be held accountable for
security
-
relevant actions

Linux should support organizational
policies requiring that users are held
accountable for their actions,
facilitating after
-
the
-
fact
investigations and providing some
deterrence

to improper actions

P.COMPLY

The implementation and use of the
organization's IT systems must
comply with all applicable laws,
regulations, and contractual
agreements imposed on the
organization.

The organization will meet all
requirements imposed upon i
t from
the outside; for example:
government regulations, national
and local laws, and contractual
agreements.

P.DUE
-
CARE

The organizations IT systems must
be implemented and operated in a
manner that represents due care and
diligence with respect to the r
isks to
the organization

It is important that the level of
security afforded by the IT system
be in accordance with what is
considered adequate within the
business or government sector in
which the organization is placed.

CGL Requirements Definition V2.0

Version 0.28




20
/
31

Name

Policy

Discussion

P.INFO
-
FLOW

Information flow betw
een IT
components must be in accordance
with established information flow
policies.

This document includes information
flow control as this is needed in
many environments. While this
might not be implemented by
mechanisms within the Linux TOE,
the IT syste
m, of which the TOE is
a part, will likely have to meet this
policy.

P.KNOWN

Except for well
-
defined set of
allowed operations, users of the
TOE must be identified and
authenticated before TOE access is
granted.

Beyond a well
-
defined set of
actions such a
s read access to a
public web
-
server, there is a finite
community of known, authenticated
users who are authenticated before
being allowed access.

P.NETWORK

The organization's IT security
policy must be maintained in the
environment of distributed systems

interconnected via insecure
networking.

Since Linux systems will likely be
connected to untrusted networks,
this policy statement will have a
significant impact on this
document's requirement definition.

P.PHYSICAL

The processing resources of the
TOE tha
t must be physically
protected in order to ensure that
security objectives are met will be
located within controlled access
facilities that mitigate unauthorized,
physical access.

A TOE will not be able to meet its
security requirements unless at least
a m
inimum degree of physical
security is provided.

P.SURVIVE

The IT system, in conjunction with
its environment, must be resilient to
insecurity, resisting the insecurity
and/or providing a means to detect
an insecurity and recover from it.

Linux systems wil
l provide a
measure of their resilience through
functionality and assurances that
resist, detect, and recover from
insecurities.


For sophisticated attacks, a large
portion of this resilience is provided
by the TOE environment.

CGL Requirements Definition V2.0

Version 0.28




21
/
31

Name

Policy

Discussion

P.TRAINING

Authenticated us
er of the system
must be adequately trained,
enabling them to (1) effectively
implement organizational security
policies with respect to their
discretionary actions and (2)
support the need for non
-
discretionary controls implemented
to enforce these polici
es.

Once granted legitimate access,
authenticated users are expected to
use IT resources and information
only in accordance with the
organizational security policy. In
order for this to be possible, these
users must be adequately trained
both to understand

the purpose and
need for security controls and to be
able to make secure decisions with
respect to their discretionary
actions.

P.USAGE

The organization's IT resources
must be used only for authorized
purposes.

Linux systems must, in conjunction
with its

environment, ensure that
the organization's information
technology is not used for
unauthorized purposes.

P.CONTAINMENT

The TOE must be able to mitigate
the risks of common threats to the
integrity of applications and data
caused by security
-
relevant er
rors
in applications.

Linux systems should limit the
damage done by buffer overflows
etc., likely through privilege
minimization, buffer overflow
detection, and process containment
mechanisms such as jails.

P.PRIVILEGE
-
MIN

The TOE must be able to run
ap
plications with a minimally
necessary set of privileges.

Linux systems should allow
granting of privileges on a need
-
only basis. The nothing
-
or
-
everything model of 'root' privileges
is not acceptable.

P.NET
-
SEGREGATION

The TOE must be configured to
provi
de adequate segregation
between the management, control
and end
-
user planes, using separate
networks, cryptographic methods,
or both.

X.805

P.CLUSTER
-
SEGREGATION

If the TOE is part of a cluster the
intra
-
cluster traffic must be
adequately segregated from
any
other traffic.

X.805

CGL Requirements Definition V2.0

Version 0.28




22
/
31

Name

Policy

Discussion

P.PROCESS
-
NET
-
SEGREGATION

The TOE must allow the
configuration of access controls on
network resources in such a way
that a process' network access can
be restricted to the minimum subset
necessary.

X.805, see discussion in sectio
n
5.5

P.PROCESS
-
FILE
-
SEGRAGATION

The TOE must allow the
configuration of access controls on
files in such a way that the process
can only access the minimum
subset of files necessary.

Limits the impact of the subversion
of a process

through buffer
overflow attacks, insertion attacks
and others.

P.TRACEABLE
-
TOE

The TOE should log sufficient
information for security
-
relevant
events, including the user or
process ID responsible for the
event.

Needed for forensics and log file
analysis.


8

Security Threats

This section borrows from a published example Common Criteria protection profile. The Security SIG
felt that is was not productive to reinvent the wheel, and so we are going to refer to threats by the
identifiers used in [CSPP
-
OS03].

Ac
cording to [CSPP
-
OS03] the following threats do not have to be addressed by the system (called
TOE
7
). We believe that given some of the intended uses of this document we do need to address these
two threats where possible.

T.DENIAL
-
SOPHISTICATED:

Sophistic
ated DoS attacks. Threats include common network attacks
such as:



SYN flooding



IP fragmentation attacks

T.ENTRY
-
SOPHISTICATED: Sophisticated technical attacks by unauthenticated users, such
as:



Buffer overflow attacks



Brute force or dictionary attacks on p
assword



Network sniffing attacks



Man
-
in
-
The
-
Middle attacks




7
Target of Evaluation

CGL Requirements Definition V2.0

Version 0.28




23
/
31



Session hijacking


The next set of threats must be addressed by the TOE.

T.ACCESS
-
TOE: an authorized user may gain non
-
malicious access to a resource or information
controlled by the TOE. Such atta
cks include:



Exploitation of misconfigured access permissions



Exploitation of system errors



Simple exploitation of vulnerabilities

T.AUDIT
-
CONFIDENTIALITY
-
TOE: Disclosure of security event records to unauthorized
users or processes. This can be caused by:



Misconfigured access permissions for log files



Easily exploitable SUID programs

T.AUDIT
-
CORRUPTED
-
TOE: Unauthorized modification or destruction of security event
records. This can be caused by:



Misconfigured access permissions for log files



Easily exploita
ble SUID programs

T.CRASH
-
TOE: Compromise of secure state when system crashes. i.e. the system does not fail
securely. Cause:



Bad design.

T.DENIAL
-
TOE: (Unsophisticated) Denial
-
of
-
Service attacks. Examples include:



Creating enough Telnet or SSH sessions to

lock out other users.



Flood ping a system.

T.OBSERVE
-
TOE:
Security compromise going undetected, for example:



The installation of a 'root kit'
8

goes undetected.



A buffer overflow and the following security compromise goes undetected.



Auditing is not config
ured to store all relevant security events

T.RECORD
-
EVENT
-
TOE: Security
-
relevant events going unrecorded, which can be caused by:



overloading the 'syslog' process, which is often trivial.



large quantities of log events that 'rotate' files containing a secu
rity
-
relevant event out of
existence.

T.RESOURCES: Exhaustion of system resources, which can be caused by:



failing to configure the system resource limits for number of processes, memory etc.




8
A root kit is a set of programs that compromise security and usually hide their own existen
ce.

CGL Requirements Definition V2.0

Version 0.28




24
/
31



underpowered systems

T.TOE
-
CORRUPTED: The security of the TOE is

intentionally corrupted, enabling future
attack. This can include:



back doors left by programmers



intentional misconfiguration of security
-
relevant systems (e.g. through the use of inauthentic
install media)


According to [CSPP
-
OS03] the following set of
threats does not have to be addressed by the OS (TOE)
alone. The environment should also play a role in addressing these vulnerabilities:

T.ACCESS
-
MALICIOUS: User gains unauthorized access for malicious purposes.

T.ADMIN
-
ERROR: Security is lessened or comp
romised due to administration error.

T.CRASH
-
SYSTEM: The security of the system as a whole (TOE and environment) is
compromised by a system crash.

T.INSTALL: The system is installed in a way that compromises security. Possible causes:

The system installer
offers bad defaults

The system installer implicitly enables exploitable services

Default configurations are set up to minimize support cost for the vendor, not to minimize security
risks

T.OPERATE: The system is managed in a way that compromises security.
Possible causes:



Staff not sufficiently trained



IT department is underfunded



System is not designed to fail safely when misconfigured



Passwords of system accounts are not changed from their defaults

T.SYSTEM
-
CORRUPTED:

The security of the system as a whole

(not just the TOE) is intentionally
corrupted to prepare for a future attack.

T.PHYSICAL
: the security of the system is undermined through methods that require physical access
to the system.

9

Security Objectives

9.1

Environmental Security Objectives

Environmen
tal Security Objective

Corresponding Threat or Policy

CGL Requirements Definition V2.0

Version 0.28




25
/
31

Environmen
tal Security Objective

Corresponding Threat or Policy

O.ACCESS
-
NON
-
TECHNICAL:
The TOE environment must
provide sufficient protection against non
-
technical attacks by
authenticated users for non
-
malicious purposes. This will be
accomplished primarily via p
revention with a goal of high
effectiveness. Personnel security and user training and awareness will
provide a major part of achieving this objective.

P.TRAINING

O.ACCESS
-
Non
-
TOE:
The IT other than the TOE must provide
public access and access by authenti
cated users to the resources and
actions for which they have been authorized and over which the TOE
does not exercise control. The focus is on prevention with a high degree
of effectiveness.

P.ACCESS

O.ACCOUNT
-
Non
-
TOE:
The IT other than the TOE must ensur
e,
for actions under its control or knowledge, that all users can
subsequently be held accountable for their security relevant actions.
This is expected with a high degree of effectiveness.

P.ACCOUNT

T.TRACEABLE
-
Non
-
TOE

T.RECORD
-
EVENT
-
Non
-
TOE

T.AUDIT
-
CORRU
PTED
-
Non
-
TOE

T.AUDIT
-
CONFIDENTIALITY
-
Non
-
TOE

O.AUTHORIZE
-
Non
-
TOE:
The IT other than the TOE must
provide the ability to specify and manage user and system process
access rights to individual processing resources and data elements under
its control, suppor
ting the organization’s security policy for access
control. This is expected with a high degree of effectiveness.

NOTE: This includes initializing, specifying and managing (1) object
security attributes, (2) active entity identity and security attributes,
and
(3) security relevant environmental conditions.

P.ACCESS

O.AVAILABLE
-
Non
-
TOE:
The IT other than the TOE must
protect itself from unsophisticated, denial
-
of
-
service attacks. This is a
combination of prevention and detection and recover with a high degr
ee
of effectiveness.

P.SURVIVE

T.DENIAL
-
Non
-
TOE

O.BYPASS
-
Non
-
TOE:
For access not controlled by the TOE, IT
other than the TOE must prevent errant or non
-
malicious, authorized
software or users from bypassing or circumventing security policy
enforcement. Th
is will be accomplished with high effectiveness.

NOTE: This objective is limited to ‘non
-
malicious’ because IT controls
in the notional CSPP system are not expected to provide sufficient
mitigation for the greater negative impact that ‘malicious’ implies.

T.ACCESS
-
Non
-
TOE


O.DETECT
-
SOPHISTICATED:
The TOE environment must
provide the ability to detect sophisticated attacks and the results of such
attacks (e.g., corrupted system state). The goal is for moderate
effectiveness.

P.SURVIVE

T.SYSTEM
-
CORRUPTED

CGL Requirements Definition V2.0

Version 0.28




26
/
31

Environmen
tal Security Objective

Corresponding Threat or Policy

O.E
NTRY
-
NON
-
TECHNICAL:

The TOE environment must
provide sufficient protection against non
-
technical attacks by other than
authenticated users. This will be accomplished primarily via prevention
with a goal of high effectiveness. User training and awareness wi
ll
provide a major part of achieving this objective.

P.TRAINING

O.ENTRY
-
NON
-
TOE:
For resources not controlled by the TOE, IT
other than the TOE must prevent logical entry using unsophisticated,
technical methods, by persons without authority for such acce
ss. This is
clearly a prevent focus and is to be achieved with a high degree of
effectiveness.

P.USAGE

T.ENTRY
-
Non
-
TOE

O.INFO
-
FLOW:
The TOE environment must ensure that any
information flow control policies are enforced
-

(1) between system
components and

(2) at the system external interfaces. This will be
accomplished by preventing unauthorized flows with high
effectiveness.

P.INFO
-
FLOW

O.KNOWN
-
Non
-
TOE:
The IT other than the TOE must ensure that,
for all actions under its control and except for a well
-
de
fined set of
allowed actions, all users are identified and authenticated before being
granted access. This is expected with a high degree of effectiveness.

P.KNOWN

O.OBSERVE
-
NON
-
TOE:
The IT other than the TOE must ensure
that its security status is not mi
srepresented to the administrator or user.
This is a combination of prevent and detect and, considering the
potentially large number of possible failure modes, is to be achieved
with a moderate, verses high, degree of effectiveness.

T.OBSERVE
-
Non
-
TOE

O.PH
YSICAL:
Those responsible for the TOE must ensure that those
parts of the TOE critical to security policy are protected from physical
attack that might compromise IT security. This will be accomplished
primarily via prevention with a goal of high effective
ness.

P.PHYSICAL

T.PHYSICAL

9.2

TOE Security Objectives

TOE Security Objective

Corresponding Threat or Policy

O.ACCESS
-
TOE:
The TOE must provide public access and access by
authenticated users to those TOE resources and actions for which they
have been autho
rized. This will be accomplished with high
effectiveness.

P.ACCESS

O.ACCOUNT
-
TOE
: The TOE must ensure, for actions under its
control or knowledge, that all TOE users can subsequently be held
accountable for their security relevant actions. This will be do
ne with
moderate effectiveness, in that it is anticipated that individual
accountability might not be achieved for some actions.

P.ACCOUNT

T.TRACEABLE
-
TOE

T.RECORD
-
EVENT
-
TOE

T.AUDIT
-
CORRUPTED
-
TOE

T.AUDIT
-
CONFIDENTIALITYTOE

CGL Requirements Definition V2.0

Version 0.28




27
/
31

TOE Security Objective

Corresponding Threat or Policy

O.AUTHORIZE
-
TOE:
The TOE must pr
ovide the ability to specify
and manage user and system process access rights to individual
processing resources and data elements under its control, supporting the
organization’s security policy for access control. This will be
accomplished with high effe
ctiveness.

P.ACCESS

O.AVAILABLE
-
TOE:
The TOE must protect itself from
unsophisticated, denial
-
of
-
service attacks. This will include a
combination of protection and detection with high effectiveness.

P.SURVIVE

T.DENIAL
-
TOE

O.BYPASS
-
TOE:
The TOE must preve
nt errant or non
-
malicious, authorized software or users from bypassing or
circumventing TOE security policy enforcement. This will be
accomplished with high effectiveness.

NOTE: This objective is limited to ‘non
-
malicious’ because CSPP
-
OS
controls are not

expected to be sufficient mitigation for the greater
negative impact that ‘malicious’ implies.

T.ACCESS
-
TOE

O.DETECT
-
TOE:
The TOE must enable the detection of TOE
specific insecurities. The goal is high effectiveness for lower grade
attacks.

P.SURVIVE

T.
TOE
-
CORRUPTED

O.ENTRY
-
TOE:
The TOE must prevent logical entry to the TOE
using unsophisticated, technical methods, by persons without authority
for such access. This will be accomplished with high effectiveness.

P.USAGE

T.ENTRY
-
TOE

O.KNOWN
-
TOE:
The TOE m
ust ensure that, for all actions under its
control and except for a well
-
defined set of allowed actions, all users
are identified and authenticated before being granted access. This will
be accomplished with high effectiveness.

P.KNOWN

O.OBSERVE
-
TOE
: The
TOE must ensure that its security status is not
misrepresented to the administrator or user. This is a combination of
prevent and detect and, considering the potentially large number of
possible failure modes, is to be achieved with a moderate, verses high
,
degree of effectiveness.

T.OBSERVE
-
TOE

O.RECOVER
-
TOE:
The TOE must provide for recovery to a secure
state following a system failure, discontinuity of service, or detection of
an insecurity. This will be accomplished with a high effectiveness for
specif
ied failures and a low effectiveness for failures in general.

P.SURVIVE

T.CRASH
-
TOE

O.RESOURCES:
The TOE must protect itself from user or system
errors that result in shared resource exhaustion. This will be
accomplished via protection with high effective
ness.

P.SURVIVE

T.RESOURCES

O.APPLICATION
-
TOOLS:

The TOE must provide a reasonable, up
-
to
-
date set of security tools and libraries for use by applications
.


P.DUE
-
CARE

T.INSTALL

T.OPERATE

9.3

Joint Security Objectives

CGL Requirements Definition V2.0

Version 0.28




28
/
31

Joint Security Objective

Corresponding T
hreat or Policy

O.ACCESS
-
MALICIOUS:

The TOE controls will help in achieving
this objective, but will not be sufficient. Additional, environmental
controls are required to sufficiently mitigate the threat of malicious
actions by authenticated users. This
will be accomplished by focusing
on deterrence, detection, and response with a goal of moderate
effectiveness.

T.ACCESS
-
MALICIOUS

O.COMPLY:
The TOE environment, in conjunction with controls
implemented by the TOE, must support full compliance with applica
ble
laws, regulations, and contractual agreements. This will be
accomplished via some technical controls, yet with a focus on
nontechnical controls to achieve this objective with high effectiveness.

P.COMPLY

O.DETECT
-
SYSTEM:
The TOE, in conjunction with o
ther IT in the
system, must enable the detection of system insecurities. The goal is
high effectiveness for lower grade attacks.

P.SURVIVE

T.SYSTEM
-
CORRUPTED

O.DUE
-
CARE:
The TOE environment, in conjunction with the TOE
itself, must be implemented and oper
ated in a manner that clearly
demonstrates due
-
care and diligence with respect to IT
-
related risks to
the organization. This will be accomplished via a combination of
technical and non
-
technical controls to achieve this objective with high
effectiveness.

P
.DUE
-
CARE

O.MANAGE
: Those responsible for the system (in conjunction with
mechanisms provided by the TOE) must ensure that it is managed and
administered in a manner that maintains IT security. This will be
accomplished with moderate effectiveness.

T.ADMI
N
-
ERROR

O.NETWORK:
The system must be able to meet its security
objectives in a distributed environment. This will be
accomplished with high effectiveness.

Note: One mechanism that could help in addressing this objective is
trusted path. However, COTS ope
rating systems do not typically
provide a trusted path between user and system and hence CSPP
-
OS
does not require that the TOE provide it. Instead, when the TOE does
not provide a trusted path, the protection that would have been provided
by a trusted path

is addressed by a combination of environmental
controls such as add
-
on IT packages, non
-
technical controls (physical,
procedural, personnel), and risk acceptance.

P.NETWORK

O.OPERATE

: Those responsible for the system (in conjunction with
mechanisms prov
ided by the TOE) must ensure that the system is
delivered, installed, and operated in a manner which maintains IT
security. This will be accomplished with moderate effectiveness.

T.INSTALL

T.OPERATE

P.TRAINING

CGL Requirements Definition V2.0

Version 0.28




29
/
31

Joint Security Objective

Corresponding T
hreat or Policy

O.RECOVER
-
SYSTEM:

The system must provide fo
r recovery to a
secure state following a system failure, discontinuity of service, or
detection of an insecurity. This will be accomplished with some
prevention and a majority of detect and respond, with high effectiveness
for specified failures. For gener
al failure, this will be accomplished with
low effectiveness.

P.SURVIVE

T.CRASH
-
SYSTEM

O.ENTRY
-
SOPHISTICATED:

The TOE and the environment
must sufficiently mitigate the threat of an individual (other than an
authenticated user) gaining unauthorized access

via sophisticated,
technical attack. This will be accomplished by focusing on prevention,
detection and response with a goal of high effectiveness

T.ENTRY
-
SOPHISTICATED

O.DENIAL
-
SOPHISTICATED:
The TOE and the environment
must maintain system availability

in the face of sophisticated denial
-
of
-
service attacks. The focus is on prevention, detection and response with
a goal of high effectiveness.

P.SURVIVE

T.DENIAL
-
SOPHISTICATED

O.DETECT
-
SOPHISTICATED:
The TOE and the environment
must provide the ability to

detect sophisticated attacks and the results of
such attacks (e.g., corrupted system state). The goal is for high
effectiveness.

P.SURVIVE

T.SYSTEM
-
CORRUPTED

O.CONTAINMENT:
The TOE and the environment must
provide the ability to constrain the effect of a

security failure of
an application to that application.

P.CONTAINMENT

P.PRIVILEGE
-
MIN

P.SURVIVE

T.SYSTEM
-
CORRUPTED

CGL Requirements Definition V2.0

Version 0.28




30
/
31

10

Bibliography
ITU03: ITU
-
T, Security in Telecommunications and Information Technology, 2003

CSPP
-
OS03: Gary Stoneburner, COTS Security Pro
tection Profile
-

O
perating Systems (CSPP
-
OS),
200
CGL Requirements Definition V2.0

Version 0.28




31
/
31