31
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

Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

Embed Size (px)

Citation preview

Page 1: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

Access Control

Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN.

OS Access Control and ACLs (Access Control Lists) in more detail

CapabilitiesCapabilities and MicrosoftSELinux - Security Enhanced Linux

Page 2: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 3: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 4: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 5: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 6: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 7: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 8: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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

Page 9: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 10: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 11: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 12: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 13: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 14: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 15: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

Unix ACLs 2Permission 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.

Page 16: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

Windows ACLsMicrosoft 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.

Page 17: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

Windows Active Directory 1Source: 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.

Page 18: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

Windows Active Directory 2Source: 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.

Page 19: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 20: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 21: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 22: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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 .

Page 23: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 24: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 25: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

SELinux FeaturesSource: 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"

Page 26: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

SELinux and FLASKSource: 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.

Page 27: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 28: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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."

Page 29: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 30: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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.

Page 31: Access Control Overview of Access Control: Hardware, Operating System, Middleware, Application, LAN, WAN. OS Access Control and ACLs (Access Control Lists)

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 Kernelhttp://www.cs.utah.edu/flux/fluke/html/flask.html

4. Wikipedia Articles:http://en.wikipedia.org/wiki/Discretionary_Access_Controlhttp://en.wikipedia.org/wiki/RBAChttp://en.wikipedia.org/wiki/Discretionary_Access_Controlhttp://en.wikipedia.org/wiki/Mandatory_access_control