The Linux operating system is a freely distributed operating system developed collaboratively, which means that no one person or company is responsible for its development (610: Cyberspace & Cybersecurity). Because of this open source model, which differs from other operating systems such as Microsoft Windows or Apple OS, there are unique security pros and cons. One of the cons of this approach is that the code which houses the security protection is freely open to the public, which includes hackers. It is possible for them to access this code and use their knowledge for malicious intents. On the other side, the open source community can find these flaws as well, but provide patches to fix them and make the operating system more secure as a whole. Additionally, since there is a large open-source community that supports Linux, patches can be made available in a few days. It is generally accepted that, from a security standpoint, the pros of open-source code outweighs the negatives.
Get your grade
or your money back
using our Essay Writing Service!
Since the OS is the base layer for interaction of applications with lower level processes, and validating users, it must have a robust security framework and multiple levels of protection. The following points will discuss the implementation of the Linux security framework and why the implementation is a benefit or has potential security flaws that should be considered.
Linux Security Model
According to Bassil (2012), the Linux security model is comprised of a number of processes, daemon services and libraries. A model of the security model is shown below in Figure 1: Linux Security Model.
Figure 1: Linux Security Model
From the illustration, the user logs in and must traverse through a series of modularized interfaces before hitting the main authentication services. The reason there are a number of management and module sessions is to allow the open source community to develop customized management libraries, as well as separate the duties of each service. Similar to the separation of privileges as a model for security, the same idea holds true for software development as well. Bassil (2012), describes the duty of the following modules within the security framework:
The PAM library is made of Pluggable Authentication Modules, and allows the development of PAM-aware applications. This library allows the authentication of users in the Linux OS. It is important to note that since the framework is pluggable, different types of authentication methods for different purposes can be easily fitted into the underlying framework.
PAM Configuration File
The PAM Configuration File is a text file where the system administrator can specify the authentication scheme for an application. As shown in Figure 1, it is directly read into the PAM Library to load the corresponding authentication modules.
The authentication module contains several authentication procedures and creates authentication credentials, authenticates users, and grants privileges to users.
Account Management Module
Much like an authorization module, this manages users accounts and determines if a user is permitted access to the system or not. It also creates a login session after a successful login, and validates the expiration of the username and password.
Password Management Module
The Password Management Module manages a userââ‚¬â„¢s passwords. This includes setting, resetting, and changing.
Session Management Module
This module handles the session that was created from the account management module, and creates the appropriate log entries for each session as well.
The benefit of the way the Linux Security model is set up is many. Since the Linux kernel is modularized, there can be a separation of the Linux kernel and the users that need to perform on top of it. Being decoupled, errors found in the security model are easier for the open source community to patch. Additionally, since it is easily customizable, there is no need to rely on a second-hand module that does not offer the specific level of security that a user might need.
Identification refers to the method a user is specifically identified and serves as an underlying principle that propagates to a number of ways Linux does its security for other areas such as access tokens, impersonations, and authorizations. First each user is given a username and a user identification number (UID). The UID is created by the system administrator when the account is first created. A unique uid is recommended but not enforced. Likewise, for groups, a group identification number or GID is used. Note that every user belongs to a group. By assigning each user a unique ID, each session can be traced specifically between one user and another.
Always on Time
Marked to Standard
The Linux method of identification is important because it serves as a ââ‚¬Å“keyââ‚¬Â for access tokens. According to Bassil (2012), an access token identifies the security context of a process or thread by attaching itself to an executable. It then uses the UID or GID to understand its privileges. A figure showing the configuration making up an access token is Figure 2: Access Tokens.
Figure 2: Access Tokens
Since the token has no inherent restrictions themselves, Linux must use DAC and MAC to impose restrictions on a particular process.
Impersonation allows the server application to have the same acess as the client in order to secure objects. In Linux, set UID (SUID) and set GID (SGID) mechanisms are used for impersonation. An executable attaches itself to the unique UID or GUID and inherits the permission of that particular UID or GID. Services that need super user permissions are wrapped in a suid-super program and the users given permission to execute. It is important to note that this type of handoff of privileges can be troublesome. Should a client be given permissions to execute something by the server that it normally shouldnââ‚¬â„¢t, a hacker can exploit this capability to their own malicious reasons. This is a flaw of the Linux operating system.
File System Security
Linux file system security is very basic. According to Bassil (2012), it uses Extended Access Control Lists (EACL) to define a file mode. This file mode uses DAC since it ties the read / write / update controls of the file to the user or group that is trying to access it. Although this works at a basic level, it misses encryption technologies over files. Third-party software must be used to add this additional capability.
In conclusion, Linux has a very structured, easily modifiable framework that allows the open source community to quickly determine bugs and fix them. Much of the underlying file permissions and access rights that are used throughout the system rely heavily on the inherent set up of the access controls tied to the UID or GID. Should these permissions be modified, such as incorrect impersonation, there could be a potential breach in security. As Linux has basic file system security, it is important that the system administrator of a Linux server or box implement and install the necessary third party software to provide additional levels of security encryption. Luckily, there are many free libraries out there from the open source community to facilitate this.