Access Control and SELinux

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

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

81 εμφανίσεις

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 diffi
­
cult to protect against if determined to compromise a sys
­
tem. 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 restrict
­
ing 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 phys
ical 
damage 
deters most attacks from those with physical ac
cess.
Losing usability might not be acceptable ­ e.g. preventing stu
­
dents from studying using software which comes with its own 
operating system on CD/USB. If hardware has to be modified 
reg
u
larly, catalogueing keys and getting through locks and re
­
pla
cing them wastes effort.
Operating System Access Control 1
As with all these layers, access control over the operating sys
­
tem can't be better than that on the layer below ­ it can only 
provide additional weaknesses. E.G. it doesn't matter if 

for
­
get 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 
re
strict
­
ing 
the memory and devices individual applic
ations 
can 
write 
to, 
providing (read write execute 
directory_traversal 
other) 
per
missions and other access con
trol 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 
con
­
sidered in a similar light to middleware, but with the 
greater 
level 
of 
ac
cess control engineering present in an operating 
system 
ported 
to 
run 
in a VM environment or running on hardware 
emulated 
by a 
modi
fied OS or VM aware hardware, we could con
sider the OS 
lay
­
er 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 ma
­
chines and SQL databases. MySQL and Oracle have their 
own internal authentication and access control systems. 
Programming language restricted environments also en
­
force controls over what software instructions can do. 
The following  C++ preprocessor statement which viol
­
ates 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 sup
­
plying 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 to
­
gether, but life for the application designer can be simpli
­
fied by reusing protections provided by the operating 
sys
­
tem 
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 net
­
work provides an alternative route into a system by an attack
­
er, 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) at
­
tacks 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 under
­
standable 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 applica
­
tion 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, immut
­
able, 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 mis
­
takes. 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 writ
­
ten 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 Win
­
dows NT provided for more flexibility than in the standard 
Unix model. Permissions in addition to read, write and ex
­
ecute 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 al
­
low 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 in
­
formation 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 ob
­
jects, 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 con
­
tainers 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 ob
­
jects 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 cre
ate 
security holes by relaxing these protections more 
than needed before the application to work

When 
the 
application eventually does work, the busy
 ad
min
is
­
trat
or 
will want to leave well alone
.
Problems with capabilities 2
 
    
* Miscommunication ­ If 
the 
pay
ments 
track
ing 
sys
­
tem uses a relational data
base 
this 
will 
have its 
own 
protection mechanisms 
separ
ate 
from 
those of 
the OS 
and 
LAN. 
The 
DB 
might 
be 
adminis
trated by 
a dif
­
ferent 
depart
ment 
or 
even 
a dif
ferent 
company. 
This 
leads to 
many 
pos
sib
ilities 
for 
mis
communica
tion 
and at
tempts to 
make 
the au
then
tica
tion informa
tion 
com
patible 
which are 
not as 
good as 
the DB, 
LAN or 
OS 
specific 
mechan
isms 
themselves.
Problems with capabilities 3
* Single sign on ­ Or making the security of the strongest ma
­
chine in the group no better than that of the weakest.
* Security context creep ­ a PC used for standalone wordpro
­
cessing and spreadsheets by a single user needed little secur
­
ity. 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 responsibil
­
ity for the security of government systems and monitoring for
­
eign government, commercial, criminal and terrorist use of 
telecommunications.
SELinux has been included in standard 2.6 series Linux Ker
­
nels. It is an active part of Red Hat Enterprise Linux and Fe
­
dora, 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 pro
­
gram execution

Controls over file systems, directories, files, and open file de
­
scriptions

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 compon
­
ent of the operating system, along with a general interface for ob
­
taining security policy decisions. This separate component is re
­
ferred to as the security server, though it's a kernel subsystem. 
This server defines a hybrid security policy composed of Type En
­
forcement (TE), role­based access control (RBAC), and the op
­
tional 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 archi
­
tecture designed for flexible implemenation of secur
­
ity policies including MAC, RBAC and Type En
­
forcement
MAC ­ Mandatory Access Control ­ A security ap
­
proach different from discretionary access control 
(DAC) where the computing system enforces con
­
trols 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 ob
­
ject 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 permis
­
sion (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 applica
­
tion or to populate a 'blood sugar level test' record in a med
­
ical application. The assignment of permission to perform a 
particular operation is meaningful, because the operations are 
fine grained and themselves have meaning within the applica
­
tion.
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 ordin
­
ary 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 Se
­
curity 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