Transcript Securing Networked Systems

Trusted Operating Systems
Securing Networked Systems
Jeffrey W. Thompson
Argus Systems Group, Inc.
Introduction
Jeff Thompson
Software Evangelist and Visionary
Argus Systems Group, Inc.
• A technical discussion of platform security
• Using Argus’ PitBull .comPack trusted operating
system product suite as a reference
• Concepts are easily translatable to other TOS
systems.
Company Profile
• Argus Systems Group, Inc. is an
international provider of Internet security
software and engineering services providing
E-commerce systems security solutions
• Dedicated to providing security solutions
necessary to advance new ways of
conducting business over the Internet
Overview
•
•
•
•
Failings of Standard Operating Systems
Understanding Trusted Operating Systems
How TOS Addresses Failings
Applying TOS to Modern Architectures
Experts Agree. . .
“The threats posed by the modern
computing environment cannot be
addressed without secure operating systems.
Any security effort which ignores this fact
can only result in a ‘fortress built upon
sand’.”
Excerpted from: “The Inevitability of Failure:
The Flawed Assumption of Security in Modern
Computing Environments”,
US National Security Agency (NSA) Report,
1998
Failings of Standard Platforms
Understanding the Sand
• Super User/Root
• Discretionary Access Control
• Networking Is Not Tied To Security
Super User/Root
• Privileged access to the system is either on
or off.
• Only one user is considered to have this
“special” access
• Creates a common and single point of attack
Super User/Root Ramifications
• Buffer Overflow Attacks
• Misdirection of “root” programs
• Access to most system files (ok, all files)
Buffer Overflow Attacks
A buffer overflow attack places new programmatic code on a
a process’ stack, and causes the process to execute this code
when returning from a function. This code is executed with
the same rights as the running process, allowing the attacker
to force the program to perform nefarious tasks.
An attacker goes after…
• Setuid 0 programs
• Daemons running as root
• If you want to learn more attend to Greg Hoglund’s Advanced Buffer
Overflow Techniques talk at 4:30pm today.
Misdirection of “root” programs
A setuid 0 program that can be “tricked” into performing
unforeseen actions can be used to obtain permanent root
access to a system.
Examples:
Race conditions that allow file overwrites
Reads any file on system
Program allows setting of location of tmp file
All of these can easily lead to unauthorized root access
Discretionary Access Control
1 The owner of the file where the data is stored determines
who gets initial access to it.
2 A user with READ access can let other users have access to
the data, either by making a copy or by making a setuid
program that gives access.
3 A user with WRITE access can let other users have access
to the data by making a setuid program that gives access.
4 The owner of a file can’t stop other users who have access
from giving that access to others, and the owner cannot
know if the transfer has taken place.
DAC Ramifications
• A user that owns a file can modify it, irregardless
of the permissions on the file
• If you become root you have access to most
system files (as they are all owned by root) and an
easy path to gaining ongoing access to the system
• In order for an attacker to access a file, he simply
has to become the user that owns the file.
• Root access also gives you DAC override and
access to all files irregardless of permissions.
Networking is Not Tied To Security
User access to files and resources on a system is not related
in any way to how the user connects to the system.
Firewalls and network filtering determine what services a
remote connection can access, but provide no additional
security or policy once a user is connected to the system.
A user connected over the Internet has exactly the same
file access on a system as the same user logged in from
an internal connection, or a VPN connection.
Summing it All Up
Many services have
to run as root and are
vulnerable to attack.
Setuid programs are
major points of attack.
Setuid ‘0’ programs
Services running as root
User A
From Internal
User A
From Internet
User ‘A’ has the same access on the system no matter where he
comes from. User ‘A’ may be able to cause serious damage to
system depending on his access rights.
Compromise is only a matter of time.
All we can do is wait and watch.
Understanding TOS(Trusted Operating Systems)
•
•
•
•
•
•
Least Privilege
Authorizations
Mandatory Access Control
Network Labeling
Security Gate
CGI Daemon
Privilege Topics
• Definitions
• Process Privileges
• File System Privileges
• Privilege Inheritance
Privilege Definitions
Least Privilege
“The principle that requires that each subject be
granted the most restrictive set of privileges needed for
the performance of authorized tasks. The application
of this principle limits the damage that can result from
accident, error, or unauthorized use.”
Privilege Bracketing
The principle of enabling and disabling privileges
around the smallest section of code which require it.
Privileges
• Traditional UNIX has one privilege: root.
• Argus has divided the root privilege into many subprivileges, for example:
PV_FS_MOUNT
PV_DAC_R
• Argus includes new privileges, for example:
PV_MAC_W
PV_PV_PROC
Process Privileges
Three privilege sets are associated with each process:
Limiting
the maximum possible privilege set a
process can have during its lifetime
Maximum
the set of privileges over which a process
has control
Effective
the set of privileges used to override
system restrictions
Process Privileges (cont’d)
The following rules apply to process privilege sets:
–
A process may manipulate its effective privilege set
within the bounds set by its maximum privilege set.
–
A process’s effective privilege set (EPS) must
always be a subset of the process’s maximum
privilege set.
–
A process’s maximum privilege set (MPS) must
always be a subset of the process’s limiting privilege
set (LPS).
Process Privileges (cont’d)
Rules (cont’d):
–
A process may only lower its maximum privilege set,
never increasing it (except certain privileged
processes).
– A process may only lower its limiting privilege set,
never increasing it (no privilege will override this
restriction).
File System
Privileges
File System Privilege Information:
– Privilege information is stored in the
inode (index node) of each file on the
system..
– Privilege information is ignored for
directories Three privilege sets are
associated with each file:
•
innate
•
proxy
•
authorized
File System Privileges (cont’d)
Innate Privileges
Privileges a process is guaranteed to have in its maximum
privilege vector upon startup.
Proxy Privileges
Privileges that will be granted only if the process has them in
its maximum privilege set prior to executing the file (i.e.
privileges that the process will be allowed to “keep” across
the exec).
Authorized Privileges
Privileges that will be granted only if the user has at least one
of the authorizations in the Privileged Authorization Set of
the file.
Privilege Inheritance
• New processes are created via the fork()
system call.
• fork() copies all privileges from the
parent to the new child.
• Executable files (programs) are executed
via the exec() system call.
• exec() calculates the new process’s
privileges according to several rules based
on the privileges in the old process and
privileges on the executable file.
Privilege vs. Authorization
Privilege
An attribute of a process that allows the process to execute specific,
security-relevant code within the TCB.
Authorization
An attribute of a user ID that allows a process acting on behalf of the
user to execute specific, security-relevant code within the TCB.
Control via Authorization
User accounts have authorizations,
not privileges.
Authorizations are the key
to gain access to a program’s features.
Unauthorized Use of Programs
• When a user runs a program (creates a new process and
runs an executable file) that is privileged, that program
can check to see if the user is authorized to use the
program or the privileges.
• If the person running the program doesn’t have the
appropriate authorization, the program can:
1) exit with an error message
2) run with a reduced feature set (e.g., ls shows all
files if run by an ISSO, otherwise it shows only files
dominated by the lsing process)
3) disallow some functionality (e.g., the -c option on
cpio can only be used by the ISSO)
Privilege Authorizations
• An executable can have a set of privileges placed on it
that will only be put into the process’ maximum set if it
passes an authorization check.
• An executable can have two types of authorizations
placed on it
–
Access Authorizations
–
Privilege Authorizations
• Access Authorizations require a user to have the
authorization in order to run the executable.
• Privilege authorizations require a user to have the
authorization in order to have the authorized
privilege set put into the maximum set.
Authorizations and Roles
Three roles
ISSO
(Information Systems Security Officer)
SA
(System Administrator)
SO
(System Operator)
Other authorizations (not a complete list):
BOOT
SHUTDOWN
DOWNGRADE
UPGRADE
LOGIN
AUTH
ILMODIFY
SETSL
OUTSIDEACCRED
AUDIT
By convention, authorization names are capitalized.
MAC Definition
Mandatory Access Control:
“A means of restricting access to objects based on the
sensitivity (as represented by a label) of the information
contained in the objects and the formal authorization
(i.e., clearance) of subjects to access information of
such sensitivity.”
TCSEC, Glossary
MAC Explanation
1 The owner of a file cannot change the MAC settings of a
file unless he is authorized to do so.
2 The owner of a file cannot give another user access to the
file unless the user is already authorized to have access to
that class of data.
3 Copies of the file will automatically be protected at least as
well as the original file, no matter how the copy is created
and no matter what program or utility is used.
MAC Topics
• Definitions and Rules
• Sensitivity Labels
• Process Labels
• Object Labels
• Login Label
SL Components
An SL has a single hierarchical component (classification or
class).
Examples:
unclassified, classified, secret, top secret
public, sensitive, confidential, classified
An SL also has (optional) non-hierarchical components
(compartments or categories).
Examples:
financial, personnel, marketing, engineering
projectA, projectB, projectC
An SL is generally written with the class and compartments
separated by a colon.
Examples:
TS:A,B
S:A,B,C
TS
(no compartment)
SL Dominance
Classes can be treated like numbers, with a class being less
than, equal to, or greater than another.
Examples:
topsecret > secret > confidential > unclassified
A compartments set can be a subset of another, or it can be a
super set, or equal, or disjoint.
Examples:
{A,B} is a subset of {A,B,C}
{B,C} is a superset of both {B} and {C} (and the null
set)
{A,B} and {B,C} are disjoint
SL Dominance (cont’d)
A label (SL1) is said to dominate another label (SL2) if and
only if both of the following are true:
1) the class of SL1 is greater than or equal to the class of
SL2, and
2) the compartment set of SL1 is a superset of, or equals,
the compartment set of SL2
Examples: (TS > S > C)
TS:A,B dominates TS:B and S:A,B and S
S:A,B,C dominates S:A and S and C:A,B,C
Equality is a special case of dominance, that is, if two labels
dominate each other, they are equal.
For some labels, such as TS:A,B and S:C, neither label
dominates the other.
SL Dominance (cont’d)
The diagram below shows how SLs are related by dominance.
Each arrow points from one SL to an SL it dominates. If a
label dominates another, it is said to be “higher” than the
second, and the second is said to be “lower” than the first.
TS:A,B,C
TS:A,B
S:B,C
TS
S:B
S
SL Inheritance
• Every process and file on the system has an SL.
• When a process creates a file, the file is created with the SL of
the process.
• When a process creates a new process (with the fork system
call), the new process inherits the same SL.
• The system boots with a specific SL, which is inherited by all
other processes. Some of these processes, such as the login
process, can change their SLs.
• Each user account is assigned a default SL by the security
officer as the account is created. This default is what a user
will have as his session SL when he logs on.
SL Access Controls
• A process cannot open a file for read unless the SL of the
process dominates the SL of the file.
• A process cannot open a file for write unless the SL of the
process equals the SL of the file.
• Unless a process has the privilege needed to change an SL,
the process cannot change its own SL or the SL of any
process or file on the system.
• This form of access control is called Mandatory Access
Control (MAC).
• This means that if a process makes a copy of a file, the new
file will be at the SL of the process, which is equal to or
higher than the original file’s SL, so the security of the copy
is equal to or greater than the security of the original file.
Clearances and Max SLs
• Every process on the system has two extra SLs:
– Minimum Clearance
– Maximum Clearance
• These SLs are used only when the process attempts to
change its own SL or the SL or another object.
• Directories and devices can have a second SL:
– Maximum SL
• This SL is used for access control. A process can write to a
device or into a directory (create or delete files) if the
process SL is within the range of the device or directory’s
SLs instead of being restricted to being equal to the device or
directory's minimum SL.
MAC Rule Summary
Dominance
A label L1 is said to dominate label L2 if the hierarchical
component of L1 is greater than or equal to that of L2 and
if all compartments (categories) of L2 are contained in the
compartments of L1.
Information Flow
Information/data is allowed to flow between objects or
subjects only if the destination sensitivity label dominates
the source sensitivity label (“write up, read down” or “*property”).
Process Labels
Label information is stored in the proc structure of each
process on the system.
Three SLs are associated with each process:
Effective SL
Minimum Clearance
Maximum Clearance
The range of SLs from minimum clearance to maximum
clearance is called the “clearance range.”
Process Labels (cont’d)
The following rules apply to process SLs:
• A process effective SL must dominate the
process minimum clearance.
• A process effective SL must be dominated by the
process’s maximum clearance.
• Only a privileged process may change the
effective SL or minimum or maximum clearance
of a process.
Object Labels
Label information is stored in the inode (index
node) of each object on the system.
Two SLs are associated with each object:
Maximum SL
Minimum SL
(The maximum SL is only used for directories and
devices.)
Object Labels (cont’d)
The following rules apply to object SLs:
• An object minimum SL must be dominated by the object’s
maximum SL.
• Only a privileged process may change the SLs of an object.
Login Label
Each user is assigned a default login SL, a minimum
clearance (SL), and a maximum clearance (SL). (all stored in
/etc/security/clear).
At login, the user is assigned his default login SL unless an
SL is explicitly requested.
Example:
login: smith -e "othersl a b"
A user can only log in with an SL within his clearance range.
Network Labeling
• Network data is labeled based on interface,
host, and port
• A process/service cannot talk to external
hosts unless the data is dominated by the
process
• Outgoing data is checked against a range of
allowable date based on network rules
Network Security Rule
A table of network security rules is loaded into the networking
stack. The rules look like this:
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
tcp: 21- 24
TS ALL | CON A |
Network Security Rule
name
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
This is a host rule...
tcp: 21- 24
TS ALL | CON A |
Network Security Rule
name
mask
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
tcp: 21- 24
TS ALL | CON A |
…with a mask, so the rule applies to all hosts with a
192.0.0.xxx IP address.
Network Security Rule
name
mask
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
tcp: 21- 24
TS ALL | CON A |
The rule applies to both incoming and outgoing
packets.
Network Security Rule
name
mask
protocol
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
tcp: 21- 24
TS ALL | CON A |
The rule applies only to those 192.0.0.xxx packets with
TCP protocol.
Network Security Rule
name
mask
protocol
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
start port range
end port range
tcp: 21- 24
TS ALL | CON A |
The rule applies only to those 192.0.0.xxx packets with
TCP protocol and using ports 21-24.
Network Security Rule
name
mask
protocol
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO |
min SL
max SL
start port range
end port range
tcp: 21- 24
TS ALL | CON A |
All packets must be in this range.
They must also be in NI rule
range.
Network Security Rule
name
mask
protocol
192.0.0.14 /255.255.255.0 IN OUT
| IMPL_LO
|
min SL
max SL
default SL
start port range
end port range
tcp: 21- 24
TS ALL CON A
|
|
Set incoming packet SL to
CONFIDENTIAL A.
Securing Services
Interface
Host A
:80
Con Httpd
Interface
Default
Con Default
VPN
Interface
Host C
:3300
Con SQL
Interface
Default
Con Default
Interface
Httpd
Con Httpd
SQL
Con SQL
:80
Con Httpd
:3300
Con SQL
Interface
Default
Con Default
Host B
Outgoing Restrictions
Interface
:80
Con Httpd
Interface
Default
Con Default
Httpd
Con Httpd
CGI
Programs
The web server can communicate on its :80 due to the host rule.
CGI programs cannot make network connections back out as
They will run as “Con Httpd” and thus not dominate the
Incoming data rule of “Con Default”. A range can be put on the
interface to enforce restrictions on all outgoing packets as well.
Security Gateway
Security Gateway is a trusted program that:
– allows communication between two processes with
disjoint Sensitivity Labels
– allows only one-to-one communication
– is written by security experts
Security Gate
CGI
SL: Con CGI
SQL
SL: Con SQL
These applications cannot talk as they
are in disjoint compartments.
Security Gate
Privileged program that acts as a gateway for
communication between two applications.
CGI
SL: Con CGI
Security
Gate
SQL
SL: Con SQL
This only allows the programs to talk, but
doesn’t allow access to files or other
resources of these applications.
CGI Daemon
A secure CGI daemon that
– separates CGI functionality of a web server from the web
server itself
– provides a secure way to execute any CGI programs
– provides virtual partition between web server and CGI
programs
– provides a secure communication between web server and
CGI program
CGI Daemon
Confidential CGI
Confidential Web
httpd
SG
CGId
CGId runs in a separate
CGI
compartment, and has no
access to httpd compartmentalized Programs
files or its network access.
How TOS Addresses Failings
• Buffer Overflow Attacks
• Misdirection of “root” programs
• A user that owns a file can modify it, irregardless of the permissions on
the file
• If you become root you have access to most system files (as they are all
owned by root) and an easy path to gaining ongoing access to the
system
• User access to files and resources on a system is not related in any way
to how they connect to the system.
• Firewalls and network filtering determine what services a remote
connection can access, but provide no additional security or policy once
a user is connected to the system.
• A user connected over the Internet has exactly the same file access on a
system as the same user logged in from an internal connection, or a
VPN connection.
Buffer Overflow Attacks
• Least Privilege allows
– Programs run with minimal abilities
– Programs can drop privileges when they are no
longer needed
Buffer Overflow Attacks Example
Httpd
Bind to Privileged Port Privilege
Httpd can be run as normal user
with bind to privileged port privilege.
There is no need for it to be root now.
Httpd
No Privilege
Once httpd binds to its network port
it can drop its privilege as it is no
longer required.
In standard Unix httpd has complete access to the system
even though it really only needs the ability to bind to a
privileged port. Why?
A buffer overflow attack on this daemon now results in no
special privileges. Also if it were attacked when it had
privilege the attacker would only gain the bind privilege
Misdirection of “root” programs
• Least privilege reduces the damage caused.
Most attacks of this type rely upon specific abilities of the root
user for their success (such as complete file access). As most
programs do not need this ability, the number of attacks is reduced.
Also, a program can drop these special privileges when no longer
needed thus further reducing the code that could be targetted
for an attack.
Misdirection of “root” programs
Program Code
Main()…
More code
And more code
This program running as root
under standard Unix has
potential attack points
throughout its entire code
base.
Misdirection of “root” programs
Program Code
Main()…
Enable Privileges
Privileged code
Drop privileges
More code
And more code
This program running as any
user under a TOS has
potential attack points only
where privileges are active
thus greatly reducing attack
vulnerability.
A user that owns a file can modify it
• MAC can be used to restrict access to a file even if
a user is the owner.
User logged in as Root
but forced to SL of Confidential
Root has read access to system files but not write access
due to MAC protection. The user has no way of changing his
effective SL and thus can never gain write access.
System Files – Owned by Root
at Implementation_Low
Root has access to all files
Under a TOS, root is not a special user. The user must
privileges or authorizations that allow him access to a
privileged program in order to gain special abilities.
Implication: Programs running as root are really no
different than programs running as any other user.
Network Protection
Network rules can force a user to enter the system a
specific effective SL thus limiting their access.
These rules can cause a user to have different types of
access that are dependent on where he logs in from (even
through a VPN).
Implications:
System files can be MAC protected to never be modifiable by any
user coming from a public connection.
Administrative programs can be isolated so that they are only
executable by internally connected users.
Summing it All Up
Services can run as
different users, or
even as root. They
gain no special rights
because of this.
Setuid programs are now
running with least privilege.
Least Privilege Programs
Services running as root
User A
From Internet
User A
From Internal
User ‘A’ can be given restricted access if coming over the
Internet (even no access), while the same user coming in from
an internal connection can be given more access.
Applications are isolated from each other and the
system, limiting the damaged caused by a penetration.
Applying TOS to Modern Architectures
• Basic Web Server
• Root as a Guest Account
Defining Labels
• Hierarchical components:
– TOP_SECRET(TS), Confidential(CON),
Unclassified(U),
Implementation_Low(IMPL_LO)
• Compartments:
– WEB, A, MAIL
Basic Web Server
Files
Web content and CGI is stored at Unclassified WEB
Web Server configuration is stored at U WEB_CONF but could
be stored at U WEB if you would like the content creator to have
access to configuration files
Basic Web Server
Files
System files (configuration, libraries, and binaries) are all stored
at Implementation Low.
Basic Web Server
Web Server
The web server is run at CON WEB WEB_CONF, giving it read
access to all web content and its own configuration files. The
web server and any CGI programs it runs are unable to modify
the files due to MAC restrictions.
Basic Web Server
Network
The interface places all external connections to the web server at
CON WEB WEB_CONF allowing communications to take place
at that SL.
FTP and SSH connections are placed at U WEB allowing content
to be placed on the system. Clearly SSH is a better mechanism
for doing this!
Root as a Guest Account
System Files
SL: IMPL_LO
Read Only
SL: Con User
:23 SL: Con User
telnetd
NIC
:25, 110, 143
SL: Con Mail
Root Shell
Pop/Imap
SL: Con Mail
Sendmail
Mail Files
Can’t
Access
Each
Other
Root connects in at Con User and is unable to modify ANY
system files.
Root as a Guest Account
System Files
SL: IMPL_LO
Read Only
SL: Con User
:23 SL: Con User
telnetd
NIC
:25, 110, 143
SL: Con Mail
Root Shell
Pop/Imap
SL: Con Mail
Sendmail
Mail Files
Can’t
Access
Each
Other
The mail system is also completely isolated. Any breach
here, will not lead to a system compromise.
Commercial Trusted OS Platforms
• Argus PitBull .comPack
– Solaris 7 (Sparc & x86)
– Porting to:
• Solaris 8 (Sparc & x86)
• IBM AIX
• Linux (32bit and 64bit kernels)
• Hewlett Packard
– Virtual Vault (HP hardware)
The Argus Revolution
• Free PitBull Foundation Licenses for
Individual Non-Commercial Use
• http://www.argusrevolution.com/