SELinux and grsecurity are two noticeable security improvements made to the Linux kernel that try to enforce Linux. SELinux is a Mandatory Access Control (MAC) mechanism that provides identity and role-based access control as well as domain-type enforcement. The second option, grsecurity, is more similar to ACLs and is, in fact, more suitable for web servers and other systems that support remote connections. With regard to how security is implemented for Linux and how the Yocto Project handles this domain, these aspects will be presented in the next section. One thing I must admit is that security handling inside the Yocto Project is still a young project at the time of writing this chapter, but I am waiting with enthusiasm to see how the number of iterations will increase over time.
At the core of every Linux system is the Linux kernel. Any malicious code that is able to damage or take control of a system also has repercussions that affect the Linux kernel. So, it only makes clear to users that having a secure kernel is also an important part of the equation. Fortunately, the Linux kernel is secure and has a number of security features and programs. The man behind all this is James Morris, the maintainer of the Linux kernel security subsystem. There is even a separate Linux repository for this that can be accessed at http://git.kernel.org/?p=linux/kernel/git/jmorris/linux-security.git;a=summary. Also, by inspecting http://kernsec.org/wiki/index.php/Main_Page, which is the main page of the Linux kernel security subsystem, you can see the exact projects that are managed inside this subsystem and maybe lend a hand to them if you're interested.
SELinux is a security enhancement for the Linux kernel, and is developed by the National Security Agency's office of Information Assurance. It has a policy-based architecture and is one of the Linux security modules that is built on the interface of Linux Security Modules (LSM) that aims at military-level security.
The basic functionalities inside SELinux are sandboxed with the help of the implementation of MAC. Inside the sandbox, each application is allowed to perform only the task it was designed to execute as defined in the security policies. Of course, standard Linux permissions are still available for the system and they will be consulted before the policies when access attempts are required. If no permissions are available, SELinux will not be able to influence the system in any way. However, if the permission rights allow access, then the SELinux policies should be consulted to offer the final verdict on whether access is permitted or denied.
- Users: In the SELinux context, the user is not the same as the one available in the UNIX context. The major difference between them is that, in the SELinux context, the user does not change during a user session and there is a possibility for more UNIX users to operate in the same SELinux user context. However, there is also a possibility of operating in a 1:1 user mapping, such as the Linux root user and the SELinux root user. Generally, the SELinux users have the
_u
suffix added to their naming. - Roles: A SELinux user can have one or multiple roles. The meaning of a role is defined in the policies. An object usually has the
object_r
role and the role is generally suffixed with the_r
string. - Types: It's the primary method applied to take authorization decisions. It can also be referred to as a domain and is generally suffixed with
_t
. - Contexts: Each process and object has its context. It is, in fact, an attribute that determines whether access should be allowed between an object and process. A SELinux context is expressed as three required fields and as an optional one as well, such as
user:role:type:range
. The first three fields represent the SELinux user, role, and the type. The last one represents the range of MLS and it will be presented shortly. More information about MLS can be gathered at http://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/sec-mls-ov.html. - Object Classes: An SELinux object class represents the category of objects available. Categories, such as
dir
for directories andfile
for files, also have a set of permissions associated with them. - Rules: These are the security mechanisms of SELinux. They are used as a type of enforcement and are specified using the type of the object and process. The rules usually state if a type is allowed to perform various actions.
As mentioned already, the SELinux is so well known and appreciated that it was included in most of the available Linux distributions. Its success is also demonstrated through the fact that a huge number of books were written on this subject. For more information regarding it, refer to http://www.amazon.com/s/ref=nb_ss_gw/102-2417346-0244921?url=search-alias%3Daps&field-keywords=SELinux&Go.x=12&Go.y=8&Go=Go. Having said this, let's take a look at the steps required to install SELinux on a Ubuntu host machine. The first step refers to the SELinux package installation:
sudo apt-get install selinux
With the package installed, the SELinux mode needs to be changed from disabled (the mode in which the SELinux policy is not enforced or logged) to one of the other two available options:
Enforcing
: This is most useful in a production system:sudo sed -i 's/SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
Permissive
: In this mode, policies are not enforced. However, any denials are logged and it is mostly used in debugging activities and when new policies are developed:sudo sed -i 's/SELINUX=.*/SELINUX=permissive/' /etc/selinux/config
With the configuration implemented, the system needs to reboot, to make sure that the system files are labeled accordingly.
More information about SELinux is also available in the Yocto Project. There is an entire layer dedicated to SELinux support. Also, for more information regarding this tool, you are encouraged to read one of the books dedicated to this matter. If you dislike this method, then there are alternative manuals with information related to SELinux, available inside various distributions, such as Fedora (https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/ch09.html), Red Hat (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/SELinux_Guide/index.html), and so on.
Grsecurity is a suite of patches released under the GNU General Public License, available for the Linux kernel and will help with the security enhancements for Linux. This suite of patches offers four main benefits:
- Configuration-free operations
- Protection against a large variety of address space change bugs
- It includes an access control list system and a number of auditing systems that are quite comprehensive to meet all sorts of demands
- It is able to interact with multiple operating systems and processor architectures
Grsecurity has a number of features that are suitable mostly for web servers or servers that accept shell access from untrusted users. One of the major feature is the
Role-based Access Control (RBAC), which is the alternative to the already available UNIX
Discretionary Access Control (DAC), or even the latter, mandatory access control (MAC) that is offered by Smack or SELinux. The aim of RBAC is to offer a least privilege system in which the processes and users only have the minimum required privileges needed for archiving their tasks. One other feature that grsecurity has is related to the hardening of the chroot()
system call to make sure that privilege escalation is eliminated. In addition to this, there are a number of miscellaneous features, such as auditing and /proc
restrictions.
- Memory corruption defences:
- Automatic response to brute force exploits
- Hardened BPF JIT against spray attacks
- Hardened userland memory permission
- Random padding between thread stacks
- Preventing direct userland access by a kernel
- Industry leading ASLR
- Bound checking kernel copies to/from a userland
- Filesystem Hardening:
- Chroot hardening
- Eliminating side-channel attacks against admin terminals
- Preventing users from tricking Apache into accessing other user files
- Hiding the processes of other users from unprivileged users
- Providing trusted path execution
- Miscellaneous protections:
- Preventing process snooping based on ptrace
- Preventing the dumping of unreadable binaries
- Preventing attackers from autoloading vulnerable kernel modules
- Denying access to overly permissive IPC objects
- Enforcing consistent multithreaded privileges
- RBAC:
- Intuitive design
- Automatic full system policy learning
- Automated policy analysis
- Human-readable policies and logs
- Stackable with LSM
- Unconventional features
- GCC plugins:
- Preventing integer overflows in size arguments
- Preventing the leakage of stack data from previous syscalls
- Adding entropy during early boot and runtime
- Randomizing kernel structure layout
- Making read-only sensitive kernel structures
- Ensuring all kernel function pointers point to the kernel
Keeping the features of grsecurity in mind, we can now move towards the installation phase of grsecurity and its administrator called gradm
.
After all the packages are available and properly verified, we can now move to the kernel configuration phase. The first step is the patching process, which is done with the grsecurity patch, but this requires access to the Linux kernel source code first:
It can be solved by installing the libncurses5-dev
package, using the following command:
With these problems fixed, the configuration process can continue. The grsecurity
option is available inside the security option subsection, as depicted in the following screenshot:
The first option refers to the configuration method, which can be Custom or Automatic:
The second option refers to the actual available configuration options:
One piece of advice I would like to offer is that first enable the Automatic configuration method and then proceed with the Custom configuration to fine tune the Grsecurity and PaX settings if necessary. Another tip would be to enable the Grsecurity | Customize Configuration | Sysctl Support option because it offers the possibility of changing the grsecurity options without compiling the kernel again. Of course, if the Automatic configuration method is selected, this option is enabled by default. The auditing option produces a big number of logs, so to prevent log flooding, make sure that Grsecurity | Customize Configuration | Logging Options is also enabled.
The next tool from the grsecurity family is the gradm
administrator, which is a powerful parser for ACLs and also optimizes them. To make sure that this utility can be installed, the installation process requires that the host operating machine for gradm
offers grsecurity support or else the compilation process will fail. There are also a number of other packages that are required before installing gradm
: lex
, flex
, byacc
, bison
, and even pam
, if necessary.
Inside the Yocto layers, there is support for the gradm
recipe that is inside the meta-oe
layer. It is available at recipes-support/gradm/gradm_3.0.bb
on the master branch. Also, a grsecurity kernel configuration is available on the master branch for the meta-accel
layer; the exact location for the configuration fragment is recipes-kernel/linux/linux-yocto-iio/grsec.cfg
. For anyone interested in learning about the concrete grsecurity support provided in Yocto, I believe the road is clear for you to start working on such a thing. One piece of advice, though, you should first ask the Yocto Project community whether anyone has started doing this already.
In the Yocto Project, the security question is is still young. Since this project was announced less than five years ago, it is only normal that discussions about security started in the last year or so. There is, of course, a specialized mailing list for the security team and it includes a large number of individuals from various companies, but their working procedure is not quite finished since it's currently in state of work in progress.
For the time being, the most time consuming of the security activity revolves around the Poky reference system, but there are also initiatives taken by various companies to try to push a series of patches toward various BSP maintainer layers or other third-party layers. For those of you interested, the mailing list of security-related discussions is <
[email protected]>
. Also, until the group is formed, they can be found in the #yocto
IRC available at http://webchat.freenode.net/?channels=#yocto, or even at the Yocto technical team meeting that takes place once every two weeks.
In this section, the layer initiatives related to the security tools of Linux are presented. In this chapter, two layers that provide both security and hardening tools are available for the Linux kernel and its libraries. Their purpose is to simplify mode embedded devices, make sure that they're secure, and maybe offer the security level similar to a desktop.
Inside the meta-security layer, there are tools that are used to secure, harden, and protect embedded devices that may offer exterior access to various entities. If the device is connected to the Internet or is susceptible to any form of attack or hijacking, then the meta-security layer may be the first stop for you. With this layer and the meta-selinux layer, the Yocto Project tries to provide security levels that are suitable for most of the community or embedded user devices. Of course, enhancing the support for various tools or adding new ones is not forbidden, so do not hesitate and add your contribution for enhancing tools if you feel the need or urge to do so. Any new commit or committer is welcome - our community is really friendly.
Besides these packages, there are a number of libraries and also TOMOYO, a kernel security module for a MAC implementation, which is also very useful as a system analysis tool. It was first released in March 2003, and was sponsored by NTT Data Corporation, Japan, until March 2012.
TOMOYO's main focus is the system behavior. For this, every process involved in the creation of the system declares its behavior and the required resources necessary to achieve a purpose. It consists of two components: one kernel component, linux-ccs, and a user space one, ccs-tools; both are required for proper functionality. TOMOYO tries to provide a MAC implementation that is both practical and easy to use. Finally, it likes to let a system be usable for a majority of users, being perfect for average users and system administrators. It is different from SELinux because it has an automatic policy configuration mechanism offered by the LEARNING mode; also, its policy language is very easy to grasp.
After protection is enabled, TOMOYO Linux acts as a watchdog that restricts the processes from using more than what they had declared initially. Its main features include the following:
- System analysis
- Tools that offer aid in the process of policy generation
- Simple to use and understand syntax
- Easy to use
- Increased security of the system through the MAC implementation
- Contains a small number of dependencies (the embedded GNU C library, libncurses, and GNU readline library)
- No modification of the already available binaries inside the root filesystem
- Since the version 2.6.30, the Linux kernel merged with the TOMOYO kernel module, making only the enabling of the module in the configuration phase necessary. It started as a patch that provided MAC support, and the porting inside a mainline kernel required a redesign using hooks into the LSM (Linux Security Modules), which also includes SELinux, AppArmor, and SMACK. However, since more hooks would be necessary for the integration of the remaining MAC functionalities, there are two other parallel development lines for the project, as follows:
- TOMOYO Linux 1.x: This is the original code version:
- It uses nonstandard specific hooks
- It offers all the MAC features
- It is released as a patch for the kernel since it does not depend on LSM
- Its latest version is 1.7.1
- TOMOYO Linux 2.x: This is the mainline source code version:
- It uses standard LSM hooks
- It contains a fewer subset of features
- It is an integral component of the 2.6.30 Linux kernel version
- The latest version is 2.5.0 and offers support for Linux kernel version 3.2
- AKARI and TOMOYO 1.x fork version:
Bastille
is a hardening program used to secure the environment and system for a Unix host. It uses rules to accomplish its goals and does this by first calling the bastille –c
command that makes you pass through a long list of questions. After they are answered, a configuration file is created and executed and this symbolizes the fact that your operating system is now hardened according to your needs. If a configuration file is already available on the system by calling bastille –b
, it can be set up for system hardening.
find-chroot.sh
: This tool scans the whole system for ELF files that callchroot
and also include a call tochdir
. The programs that fail this test do not containcwd
insidechroot
and they are not protected and safe to use.find-chroot-py.sh
: This tool is similar to the preceding point, but only tests Python scripts.rpm-chksec.sh
: This tool takes an rpm file and checks its content for its compiling flags. It does this for security reasons. If the results are green, then everything is OK, yellow means passable, and red requires the user's attention.find-nodrop-groups.sh
: This tool scans the whole system for programs that change the UID or GID without calling thesetgroups
andinitgroups
calls.rpm-drop-groups.sh
: This tool scans the whole system similar to the preceding tool, but this one uses the available RPM files.find-execstack.sh
: This tool scans the whole system for ELF files that mark the stack as executable. It is used to identify programs that are susceptible to stack buffer overflow.find-sh4errors.sh
: This tool scans the whole system for shell scripts and checks their correctness by using thesh –n
command.find-hidden-exec.sh
: This tool scans the system for hidden executables and reports the results back to the user for investigation.selinux-ls-unconfined.sh
: This tool is used to scan all the running processes and look for theinitrc_t
label orinetd
on them (this means that they are daemons that are running unconfined). The problems should be reported as SELinux policy problems.selinux-check-devides.sh
: This tool checks all the available devices too see if they are correctly labelled. It is also marked as a SELinux policy problem that should be solved.find-elf4tmp.sh
: This tool scans the whole system and checks whether the usedtmp
files are well known, are created withmktemp
, or have some obscure format.find-sh3tm.sh
: This tool also scans the filesystem, although only inside/tmp
and looks for ELF files there. When it finds them, it checks if any of the random name generators function was called on them by investigating the symbol table. If the result is affirmative, it will output the string value.lib-bin-check.sh
: This tool checks the packages of libraries and their the package they contain. It is based on the idea that the fewer binaries available on a system, the more secure it is.
Another tool that is included is pax-utils
. It also includes a number of scripts that scan ELF binaries mostly for consistency, but this is not all. Take a look at some of them:
scanelf
: This tool is used to find pre-information about the ELF structure of the binarydumpelf
: This tool is a user space utility used to dump the internal ELF structure in equivalent C structures for debugging or reference purposespspax
: This tool is used to scan/proc
and list the various ELF types available and their corresponding PaX flags, attributes, and filenames
Suricata is a high-performance IDS/IPS and Security Monitoring engine for the network. It is owned and maintained by OISF (Open Information Security Foundation) and its supporters. It uses the HTP library that is a very powerful HTTP parser and normalizer and offers some nice features, such as protocol identification, MD5 checksum, file identification, and even extraction.
ISIC, on the other hand, is what its name suggests, an IP Stack Integrity Checker. It is, in fact, a suite of utilities for IP Stack ad other stacks, such as TCP, ICMP, UDP, and others that test either the firewall, or the protocol itself.
For any web server, nikto is the tool to execute on your device. It is a scanner used to run a suite of tests that identifies dangerous CGI1s or other files. It also presents an outdated version for more than 1250 servers and various lists of vulnerabilities for each version.
Next on the list is the libseccomp library that provides an easy-to-use abstract interface to the Linux kernel, syscall
, filtering a mechanism called seccomp
. It does this by abstracting the BPF syscall
filter language and presenting it a more user-friendly format for application developers in general.
Checksecurity is the next package on the line which uses a collection of shell scripts and other plugins for testing various changes to setuid
programs. Using the filter defined in /etc/checksecurity.conf
, it scans the mounted filesystems and compares the already available list of setuid
programs to the newly scanned ones and prints the changes for the user to see. It also offers information about these filesystems that were mounted unsecure.
ClamAV is an antivirus for Unix that operates from the command line. It is a very good engine for tracking trojans, malware, viruses, and detection of other malicious threats. It can do a large variety of things from e-mail scanning to web scanning and end-point security. It also has a very versatile and scalable daemon, command-line scanner, and database interaction tool.
The last on the list is Network Mapper (nmap). It is the most well known and is used for security auditing as well as a network discovery tool by network and system administrators. It is used to manage service upgrade schedules, network inventory, monitoring various services, or even host uptime.
The other available security layer is represented by the meta-selinux layer. This one is different from meta-security because it only offers support for one tool, but as mentioned in the preceding tool, it is so big and vast that it spreads its wings across the whole system.
I will start the introduction of this layer with the audit userspace tool, which as the name suggests, is a tool that can be used for auditing, more specifically for kernel auditing. It uses a number of utilities and libraries to search and store recorded data. The data is generated through an audit subsystem available inside the Linux kernel. It is designed to work as a standalone component, but it cannot offer Common Criteria (CC) or FIPS 140-2 functionalities without a second security component being available.
The next element on the list is libcap-ng, an alternative library with simplified POSIX capabilities that can be compared to the traditional libcap solution. It offers utilities that analyze running applications and print out their capabilities, or if they have an open ended bounding set. For an open bounding set that lacks the securebit
, NOROOT
flag will permit only by using an execve()
call to retain full capabilities for applications that retain the 0
UID. By using the libcap-ng libraries, these applications that have the most privileges, are very easy to spot and deal with tools. The interaction and their detection is done with other tools, such as netcap, pscap, or filecap.
SETools is a policy analysis tool. It is in fact, an extension of SELinux and contains a collection of libraries, graphical tools, and command-lines that try simply analyze the the SELinux policies. The primary tools that this open source project are as follows:
apol
: This is a tool used to analyze SELinux policiessediff
: This acts as a semantic differentiator between SELinux policiesseaudit
: This is a tool used to analyze audit messages for SELinuxseaudit-report
: This is used to generate a highly customizable audit report based on available audit logssechecker
: This is a command-line tool that is engaged in modular checks of SELinux policiessecmds
: This is another command-line tool that is used to reach and analyze SELinux policies
Next is SWIG (Simplified Wrapper and Interface Generator), a software development tool used with a variety of target languages to create a high-level programming environment, user interfacing, and anything else that is necessary. It is usually used for fast testing or prototyping because it generates the glue that a target language can call inside the C or C++ code.
For those of you interested in obtaining a SELinux enhance distribution, you could choose to use one of the two available images in the meta-selinux layer: core-image-selinux-minimal.bb
or core-image-selinux.bb
. The alternative would be to incorporate one of the available SELinux-specific defined package groups, packagegroup-selinux-minimal
or packagegroup-core-selinux
, into a newly defined image according to the needs of a developer. After this choice is made and the configuration is done accordingly, the only thing remaining would be to call bitbake
for the chosen image and at the end of the build process, a custom Linux distribution will reveal itself with SELinux support enabled and can be tweaked some more if necessary.
Besides these packages, there are a number of libraries and also TOMOYO, a kernel security module for a MAC implementation, which is also very useful as a system analysis tool. It was first released in March 2003, and was sponsored by NTT Data Corporation, Japan, until March 2012.
TOMOYO's main focus is the system behavior. For this, every process involved in the creation of the system declares its behavior and the required resources necessary to achieve a purpose. It consists of two components: one kernel component, linux-ccs, and a user space one, ccs-tools; both are required for proper functionality. TOMOYO tries to provide a MAC implementation that is both practical and easy to use. Finally, it likes to let a system be usable for a majority of users, being perfect for average users and system administrators. It is different from SELinux because it has an automatic policy configuration mechanism offered by the LEARNING mode; also, its policy language is very easy to grasp.
After protection is enabled, TOMOYO Linux acts as a watchdog that restricts the processes from using more than what they had declared initially. Its main features include the following:
- System analysis
- Tools that offer aid in the process of policy generation
- Simple to use and understand syntax
- Easy to use
- Increased security of the system through the MAC implementation
- Contains a small number of dependencies (the embedded GNU C library, libncurses, and GNU readline library)
- No modification of the already available binaries inside the root filesystem
- Since the version 2.6.30, the Linux kernel merged with the TOMOYO kernel module, making only the enabling of the module in the configuration phase necessary. It started as a patch that provided MAC support, and the porting inside a mainline kernel required a redesign using hooks into the LSM (Linux Security Modules), which also includes SELinux, AppArmor, and SMACK. However, since more hooks would be necessary for the integration of the remaining MAC functionalities, there are two other parallel development lines for the project, as follows:
- TOMOYO Linux 1.x: This is the original code version:
- It uses nonstandard specific hooks
- It offers all the MAC features
- It is released as a patch for the kernel since it does not depend on LSM
- Its latest version is 1.7.1
- TOMOYO Linux 2.x: This is the mainline source code version:
- It uses standard LSM hooks
- It contains a fewer subset of features
- It is an integral component of the 2.6.30 Linux kernel version
- The latest version is 2.5.0 and offers support for Linux kernel version 3.2
- AKARI and TOMOYO 1.x fork version:
Bastille
is a hardening program used to secure the environment and system for a Unix host. It uses rules to accomplish its goals and does this by first calling the bastille –c
command that makes you pass through a long list of questions. After they are answered, a configuration file is created and executed and this symbolizes the fact that your operating system is now hardened according to your needs. If a configuration file is already available on the system by calling bastille –b
, it can be set up for system hardening.
find-chroot.sh
: This tool scans the whole system for ELF files that callchroot
and also include a call tochdir
. The programs that fail this test do not containcwd
insidechroot
and they are not protected and safe to use.find-chroot-py.sh
: This tool is similar to the preceding point, but only tests Python scripts.rpm-chksec.sh
: This tool takes an rpm file and checks its content for its compiling flags. It does this for security reasons. If the results are green, then everything is OK, yellow means passable, and red requires the user's attention.find-nodrop-groups.sh
: This tool scans the whole system for programs that change the UID or GID without calling thesetgroups
andinitgroups
calls.rpm-drop-groups.sh
: This tool scans the whole system similar to the preceding tool, but this one uses the available RPM files.find-execstack.sh
: This tool scans the whole system for ELF files that mark the stack as executable. It is used to identify programs that are susceptible to stack buffer overflow.find-sh4errors.sh
: This tool scans the whole system for shell scripts and checks their correctness by using thesh –n
command.find-hidden-exec.sh
: This tool scans the system for hidden executables and reports the results back to the user for investigation.selinux-ls-unconfined.sh
: This tool is used to scan all the running processes and look for theinitrc_t
label orinetd
on them (this means that they are daemons that are running unconfined). The problems should be reported as SELinux policy problems.selinux-check-devides.sh
: This tool checks all the available devices too see if they are correctly labelled. It is also marked as a SELinux policy problem that should be solved.find-elf4tmp.sh
: This tool scans the whole system and checks whether the usedtmp
files are well known, are created withmktemp
, or have some obscure format.find-sh3tm.sh
: This tool also scans the filesystem, although only inside/tmp
and looks for ELF files there. When it finds them, it checks if any of the random name generators function was called on them by investigating the symbol table. If the result is affirmative, it will output the string value.lib-bin-check.sh
: This tool checks the packages of libraries and their the package they contain. It is based on the idea that the fewer binaries available on a system, the more secure it is.
Another tool that is included is pax-utils
. It also includes a number of scripts that scan ELF binaries mostly for consistency, but this is not all. Take a look at some of them:
scanelf
: This tool is used to find pre-information about the ELF structure of the binarydumpelf
: This tool is a user space utility used to dump the internal ELF structure in equivalent C structures for debugging or reference purposespspax
: This tool is used to scan/proc
and list the various ELF types available and their corresponding PaX flags, attributes, and filenames
Suricata is a high-performance IDS/IPS and Security Monitoring engine for the network. It is owned and maintained by OISF (Open Information Security Foundation) and its supporters. It uses the HTP library that is a very powerful HTTP parser and normalizer and offers some nice features, such as protocol identification, MD5 checksum, file identification, and even extraction.
ISIC, on the other hand, is what its name suggests, an IP Stack Integrity Checker. It is, in fact, a suite of utilities for IP Stack ad other stacks, such as TCP, ICMP, UDP, and others that test either the firewall, or the protocol itself.
For any web server, nikto is the tool to execute on your device. It is a scanner used to run a suite of tests that identifies dangerous CGI1s or other files. It also presents an outdated version for more than 1250 servers and various lists of vulnerabilities for each version.
Next on the list is the libseccomp library that provides an easy-to-use abstract interface to the Linux kernel, syscall
, filtering a mechanism called seccomp
. It does this by abstracting the BPF syscall
filter language and presenting it a more user-friendly format for application developers in general.
Checksecurity is the next package on the line which uses a collection of shell scripts and other plugins for testing various changes to setuid
programs. Using the filter defined in /etc/checksecurity.conf
, it scans the mounted filesystems and compares the already available list of setuid
programs to the newly scanned ones and prints the changes for the user to see. It also offers information about these filesystems that were mounted unsecure.
ClamAV is an antivirus for Unix that operates from the command line. It is a very good engine for tracking trojans, malware, viruses, and detection of other malicious threats. It can do a large variety of things from e-mail scanning to web scanning and end-point security. It also has a very versatile and scalable daemon, command-line scanner, and database interaction tool.
The last on the list is Network Mapper (nmap). It is the most well known and is used for security auditing as well as a network discovery tool by network and system administrators. It is used to manage service upgrade schedules, network inventory, monitoring various services, or even host uptime.
The other available security layer is represented by the meta-selinux layer. This one is different from meta-security because it only offers support for one tool, but as mentioned in the preceding tool, it is so big and vast that it spreads its wings across the whole system.
I will start the introduction of this layer with the audit userspace tool, which as the name suggests, is a tool that can be used for auditing, more specifically for kernel auditing. It uses a number of utilities and libraries to search and store recorded data. The data is generated through an audit subsystem available inside the Linux kernel. It is designed to work as a standalone component, but it cannot offer Common Criteria (CC) or FIPS 140-2 functionalities without a second security component being available.
The next element on the list is libcap-ng, an alternative library with simplified POSIX capabilities that can be compared to the traditional libcap solution. It offers utilities that analyze running applications and print out their capabilities, or if they have an open ended bounding set. For an open bounding set that lacks the securebit
, NOROOT
flag will permit only by using an execve()
call to retain full capabilities for applications that retain the 0
UID. By using the libcap-ng libraries, these applications that have the most privileges, are very easy to spot and deal with tools. The interaction and their detection is done with other tools, such as netcap, pscap, or filecap.
SETools is a policy analysis tool. It is in fact, an extension of SELinux and contains a collection of libraries, graphical tools, and command-lines that try simply analyze the the SELinux policies. The primary tools that this open source project are as follows:
apol
: This is a tool used to analyze SELinux policiessediff
: This acts as a semantic differentiator between SELinux policiesseaudit
: This is a tool used to analyze audit messages for SELinuxseaudit-report
: This is used to generate a highly customizable audit report based on available audit logssechecker
: This is a command-line tool that is engaged in modular checks of SELinux policiessecmds
: This is another command-line tool that is used to reach and analyze SELinux policies
Next is SWIG (Simplified Wrapper and Interface Generator), a software development tool used with a variety of target languages to create a high-level programming environment, user interfacing, and anything else that is necessary. It is usually used for fast testing or prototyping because it generates the glue that a target language can call inside the C or C++ code.
For those of you interested in obtaining a SELinux enhance distribution, you could choose to use one of the two available images in the meta-selinux layer: core-image-selinux-minimal.bb
or core-image-selinux.bb
. The alternative would be to incorporate one of the available SELinux-specific defined package groups, packagegroup-selinux-minimal
or packagegroup-core-selinux
, into a newly defined image according to the needs of a developer. After this choice is made and the configuration is done accordingly, the only thing remaining would be to call bitbake
for the chosen image and at the end of the build process, a custom Linux distribution will reveal itself with SELinux support enabled and can be tweaked some more if necessary.
I will start the introduction of this layer with the audit userspace tool, which as the name suggests, is a tool that can be used for auditing, more specifically for kernel auditing. It uses a number of utilities and libraries to search and store recorded data. The data is generated through an audit subsystem available inside the Linux kernel. It is designed to work as a standalone component, but it cannot offer Common Criteria (CC) or FIPS 140-2 functionalities without a second security component being available.
The next element on the list is libcap-ng, an alternative library with simplified POSIX capabilities that can be compared to the traditional libcap solution. It offers utilities that analyze running applications and print out their capabilities, or if they have an open ended bounding set. For an open bounding set that lacks the securebit
, NOROOT
flag will permit only by using an execve()
call to retain full capabilities for applications that retain the 0
UID. By using the libcap-ng libraries, these applications that have the most privileges, are very easy to spot and deal with tools. The interaction and their detection is done with other tools, such as netcap, pscap, or filecap.
SETools is a policy analysis tool. It is in fact, an extension of SELinux and contains a collection of libraries, graphical tools, and command-lines that try simply analyze the the SELinux policies. The primary tools that this open source project are as follows:
apol
: This is a tool used to analyze SELinux policiessediff
: This acts as a semantic differentiator between SELinux policiesseaudit
: This is a tool used to analyze audit messages for SELinuxseaudit-report
: This is used to generate a highly customizable audit report based on available audit logssechecker
: This is a command-line tool that is engaged in modular checks of SELinux policiessecmds
: This is another command-line tool that is used to reach and analyze SELinux policies
Next is SWIG (Simplified Wrapper and Interface Generator), a software development tool used with a variety of target languages to create a high-level programming environment, user interfacing, and anything else that is necessary. It is usually used for fast testing or prototyping because it generates the glue that a target language can call inside the C or C++ code.
For those of you interested in obtaining a SELinux enhance distribution, you could choose to use one of the two available images in the meta-selinux layer: core-image-selinux-minimal.bb
or core-image-selinux.bb
. The alternative would be to incorporate one of the available SELinux-specific defined package groups, packagegroup-selinux-minimal
or packagegroup-core-selinux
, into a newly defined image according to the needs of a developer. After this choice is made and the configuration is done accordingly, the only thing remaining would be to call bitbake
for the chosen image and at the end of the build process, a custom Linux distribution will reveal itself with SELinux support enabled and can be tweaked some more if necessary.