Transcript Access Control and SELinux

Access Control
Overview of Access Control: Hardware, Operating
System, Middleware, Application, LAN, WAN.
OS Access Control and ACLs (Access Control Lists)
in more detail
Capabilities
Capabilities and Microsoft
SELinux - Security Enhanced Linux

Overview of Access Control
Purpose
The purpose of access control is to constrain which
principals (i.e. persons, processes and machines)
have access to which system resources. The latter
includes files which can be read, modified, and
removed, data which can be shared, programs
which can be run and network connections.
Access Control Overview and Context
Anderson ("Security Engineering", Wiley 2001
page 52) Describes 4 levels.
Hardware, Operating System, middleware and
application.
We could add the LAN and WAN as an extra 2. As
we work up the levels from hardware this gets more
complex.
Hardware access control 1
Anyone with physical access to the hardware is very
difficult to protect against if determined to compromise a
system. Those entering the TIC need to sign in at reception
or use a swipe card. Smile - you're on CCTV. The BCU
Perry Barr campus wasn't designed this way.
Some protection is possible through physical locks on
computers to prevent the case being removed, by
restricting the BIOS boot sequence to an internal hard disk
only and preventing BIOS changes using a password.
These protection measures all restrict usability and take
time to implement.
Hardware access control 2
CCTV cameras can be obscured, cutters can cut the cables used
to secure PCs. Expansion blanking covers can be levered out.
Motherboard batteries can then be shorted out for a few seconds
to reset BIOS passwords. Hard disks and memory chips can be
removed. Having to carry out physical damage deters most
attacks from those with physical access.
Losing usability might not be acceptable - e.g. preventing
students from studying using software which comes with its
own operating system on CD/USB. If hardware has to be
modified regularly, catalogueing keys and getting through locks
and replacing them wastes effort.
Operating System Access Control 1
As with all these layers, access control over the operating
system can't be better than that on the layer below - it can only
provide additional weaknesses. E.G. it doesn't matter if I forget
the root password when I can boot the system from a CDROM,
mount the hard disk and edit the password hash.
The OS provides many security mechanisms, through
restricting the memory and devices individual applications can
write to, providing (read write execute directory_traversal
other) permissions and other access control mechanisms e.g.
Access Control Lists and determining which processes can
listen and send on which network ports.
Operating System Access Control 2
Capabilities have been introduced into Linux to enable the system
administrator responsibilities traditionally exercised through the root
password to be delegated to a number of roles.
Traditionally this layer is where there has been much focus by security
engineers, resulting in an increasing elaboration of protection schemes
enforceable by the operating system. Running an operating system as
a guest virtual machine on top of a host OS could be considered in a
similar light to middleware, but with the greater level of access control
engineering present in an operating system ported to run in a VM
environment or running on hardware emulated by a modified OS or
VM aware hardware, we could consider the OS layer to be split into 2,
layers, host OS and guest OS.
Middleware Access Control
Middleware includes systems such as the Java, Javascript
or .Net programming language environment virtual
machines and SQL databases. MySQL and Oracle have
their own internal authentication and access control
systems.
Programming language restricted environments also
enforce controls over what software instructions can do.
The following C++ preprocessor statement which violates
an unenforced standard illustrates a limitation:
#define private public
Application Access Control 1
Garbage in results in garbage out (GIGO). Any
multiuser application whose designer doesn't want a
data rubbish dump needs to know who is supplying
input.
The application design can often usefully leverage
authentication information already provided by the
operating system, but may need to defend against
what the user can easily manipulate, e.g. by not
accepting environment variables as reliable
indicators of user identity.
Application Access Control 2
An example of an application specific access control might
be in a bookkeeping application which makes it impossible
for a transaction to be recorded against a single account
without a corresponding entry in another (double-entry
bookkeeping).
This layer is more complex than the previous ones put
together, but life for the application designer can be
simplified by reusing protections provided by the operating
system or by making reasonable assumptions, e.g. about a
one to one binding between users and the email addresses
they are associated with.
LAN and WAN Access Controls
While lesser solutions exist, including NTLM, SAMBAv3,
NIS, Kerberos also known as Microsoft (Active
Directory/Domain Controller) prevents LAN security being
worse than the sum of its parts. Traditional layering of access
controls stop at the application layer, but given that the network
provides an alternative route into a system by an attacker, the
LAN should be considered as an additional source of insider
attacks, as should the WAN with outsiders.
From this point outwards, access controls are provided through
virtual private networks (VPNs) and firewalls. In some cases,
protection against distributed denial of service (DDOS) attacks
will require substantial cooperation with an ISP.
OS Access Control in more detail 1
Authentication
Passwords, swipe cards, biometrics
Authorisation
Which permissions (read, write, execute, subtree
traversal, privilege escalation, privilege reduction)
are given to which users, groups and programs.
OS Access Control in more detail 2
Access Control Policy
Deciding which authorisations are needed for useful work
to be done might involve accepting installation defaults or
might involve a local policy. E.G. All members of the
accounts group can view purchase transactions, but only
members of budget-holders can write to these.
Should all users of a standard multi-user system be able to
read each others files by default ? This default might lead
to fewer support problems for small business customers,
but more for criminal justice or health customers.
Unix ACLs 1
The basics of the standard Unix access control model has been
covered in the permissions, use of chmod, chown and setuid/setgid
notes. This design is small enough to be fully understandable with a
relatively small amount of effort - having a fully understandable
system means that more system administrators are likely to be
willing to participate in formulating a policy and changing
installation defaults.
The problem is when the person or persons who need to know the
root password are not fully trusted in the context of the application
being run on the machine they administrate. One defence is to send
the logs to another networked machine administrated by another
party.
Unix ACLs 2
Permission is applied concerning what the user can do to a file. Any
program the user can execute can access any file the user has access
to. This allows a more permissive by default environment than some
(e.g. those concerned with military security) want. FreeBSD Unix
provides some additional file permissions, e.g. append-only,
immutable, undeletable - even by root.
Creating 3 factor security - combines the access allowed by using a
program in connection with a user and a file. This requires setuid or
setgid permissions - with many opportunities for programming
mistakes. In practice many Unix administrators understand how to use
these permissions and system programs well enough that they don't try
to bypass them when something doesn't work using poorly written
setuid programs.
Windows ACLs
Microsoft OSs prior to and including Windows 98 and ME had
very limited and optional attributes applicable to files - read,
write, system and hidden. OSs later than and including
Windows NT provided for more flexibility than in the standard
Unix model. Permissions in addition to read, write and execute
include delete, change permissions, (similar to file ownership
on Unix) and take ownership (can be done using group
ownership on Unix) .
On Unix permissions are either on or off, on Windows these
are AccessDenied, AccessAllowed or SystemAudit. These
allow for more complex delegation polices for those with the
time to decide, learn and implement these.
Windows Active Directory 1
Source: http://en.wikipedia.org/wiki/Active_Directory
Active Directory is a directory service used to store
information about the network resources across a domain
and also centralize the network security administration.
An 'Active Directory' (AD) structure is a hierarchical
framework of objects. The objects fall into three broad
categories: resources (e.g., printers), services (e.g., email),
and users (user accounts and groups). The AD provides
information on the objects, organizes the objects, controls
access and sets security.
Windows Active Directory 2
Source: http://en.wikipedia.org/wiki/Active_Directory
Each object represents a single entity — whether a user, a computer, a
printer, or a group — and its attributes. Certain objects can also be
containers of other objects. An object is uniquely identified by its name and
has a set of attributes — the characteristics and information that the object
can contain — defined by a schema, which also determines the kind of
objects that can be stored in the AD.
Each attribute object can be used in several different schema class objects.
The schema object exists to allow the schema to be extended or modified
when necessary. However, because each schema object is integral to the
definition of AD objects, deactivating or changing these objects can have
serious consequences because it will fundamentally change the structure of
AD itself. A schema object, when altered, will automatically propagate
through Active Directory and once it is created it can only be deactivated —
not deleted. Changing the schema usually requires a fair amount of
planning.
Capabilities
Capabilities are an access control design based on the
principle of least privilege. This means that a
user/program combination is given the privileges
needed to do what they need to do and no more.
Problems with capabilities 1
* Complexity - Much fine tuning is needed before
the "principle of least privilege" is achieved. Few
administrators have the time and knowledge to do this.
It is easy to break an application by giving it or its files
or users too little privilege, and then create security
holes by relaxing these protections more than needed
before the application to work. When the application
eventually does work, the busy administrator will want
to leave well alone.
Problems with capabilities 2
* Miscommunication - If the payments tracking
system uses a relational database this will have its own
protection mechanisms separate from those of the OS
and LAN. The DB might be administrated by a
different department or even a different company. This
leads to many possibilities for miscommunication and
attempts to make the authentication information
compatible which are not as good as the DB, LAN or
OS specific mechanisms themselves.
Problems with capabilities 3
* Single sign on - Or making the security of the strongest
machine in the group no better than that of the weakest.
* Security context creep - a PC used for standalone
wordprocessing and spreadsheets by a single user needed little
security. When this kind of system was networked for
exclusive use by a work group, protections were extended
against more and worse kinds of mistake. Many such systems
were then connected to the Internet, yet were designed for a
different security context .
Capabilities and Microsoft
The most actively and widely used capability systems
is that provided in addition to ACLs by Windows
2000, XP, Vista etc. through Active Directory. Groups
can be defined which cover organisational departments
or units, domains and sites. Other named entities
include users and machines.
SELinux
SELinux (Security Enhanced Linux) was primarily designed by
the US National Security Agency. The NSA has a responsibility
for the security of government systems and monitoring foreign
government, commercial, criminal and terrorist use of
telecommunications.
SELinux has been included in standard 2.6 series Linux
Kernels. It is an active part of Red Hat Enterprise Linux and
Fedora, and is also available in Gentoo Linux and Debian
Linux. It involves a security process which enforces security
policies through the use of the Linux security modules facility
which predated the SELinux patch provided by the NSA.
SELinux Features
Source: http://en.wikipedia.org/wiki/SELinux )
Clean separation of policy from enforcement
Well-defined policy interfaces
Independent of specific policies and policy languages
Independent of specific security label formats and contents
Individual labels and controls for kernel objects and services
Caching of access decisions for efficiency
Support for policy changes
Controls over process initialization and inheritance and
program execution
Controls over file systems, directories, files, and open file
descriptions
Controls over sockets, messages, and network interfaces
Controls over use of "capabilities"

SELinux and FLASK
Source: http://www-128.ibm.com/developerworks/library/s-selinux/?n-s-381
The security architecture is called Flask, designed by the NSA with
academic and commercial partners. In the Flask architecture, the
security policy's logic is encapsulated within a separate component
of the operating system, along with a general interface for obtaining
security policy decisions. This separate component is referred to as
the security server, though it's a kernel subsystem.
This server defines a hybrid security policy composed of Type
Enforcement (TE), role-based access control (RBAC), and the
optional multilevel security (MLS), widely used in military
security. The policy is compiled by a separate program called
checkpolicy, which is read by the security server at boot time.
Definitions: FLASK and MAC
FLASK - FLux Advanced Security Kernel - an
architecture designed for flexible implemenation of
security policies including MAC, RBAC and Type
Enforcement
MAC - Mandatory Access Control - A security
approach different from discretionary access control
(DAC) where the computing system enforces controls
over data access, e.g. within a system containing data
at more than one level in a multilevel security system.
Definitions: DAC
Discretionary Access Control (DAC) - defines basic
access control policies to objects in a filesystem.
Generally, these are done at the discretion of the object
owner -- file/directory permissions and user/group
ownership. The Telecom Glossary defines DAC as "A
means of restricting access to objects based on the
identity and need-to-know of users and/or groups to
which the object belongs. Controls are discretionary in
the sense that a subject with a certain access
permission is capable of passing that permission
(directly or indirectly) to any other subject."
Definitions: RBAC
RBAC - see http://en.wikipedia.org/wiki/RBAC Role Based
Access Control differs from access control lists (ACLs) used
in traditional DAC systems in that it assigns permissions to
specific operations with meaning in the organization, rather
than to low level data objects. For example, an access control
list could be used to grant or deny write access to a particular
system file, but it would not say in what ways that file could be
changed. In an RBAC based system an operation might be to
create a 'credit account' transaction in a financial application or
to populate a 'blood sugar level test' record in a medical
application. The assignment of permission to perform a
particular operation is meaningful, because the operations are
fine grained and themselves have meaning within the
application.
Definitions: Type Enforcement
Type Enforcement is an approach to enforcing access control
which reduces permissions needed to the minimum required to
do the job needed. For example, under standard Unix the
passwd program is setuid to enable it to be run by an ordinary
user as root to enable it to write the /etc/shadow file so
ordinary users can change their own passwords. This has 2
problems:
1. If badly written the passwd program can do anything root
can do, not just write to /etc/shadow and
2. that anything that can run as root can write to /etc/shadow.
With type enforcement only /usr/bin/shadow can write to the
shadow file and that is all it can do.
References and links
1. Ross Anderson, "Security Engineering", Wiley 2001
2. Mayer, MacMillan and Caplan, SELinux by Example: Using
Security Enhanced Linux, Prentice Hall 2006
3. Type Enforcement Access Control (Caplan, MacMillan, Mayer):
http://www.informit.com/articles/article.aspx?p=606586&seqNum=2
4. FLASK: Flux Advanced Security Kernel
http://www.cs.utah.edu/flux/fluke/html/flask.html
4. Wikipedia Articles:
http://en.wikipedia.org/wiki/Discretionary_Access_Control
http://en.wikipedia.org/wiki/RBAC
http://en.wikipedia.org/wiki/Discretionary_Access_Control
http://en.wikipedia.org/wiki/Mandatory_access_control