Book Image

Linux: Embedded Development

By : Alexandru Vaduva, Alex Gonzalez, Chris Simmonds
Book Image

Linux: Embedded Development

By: Alexandru Vaduva, Alex Gonzalez, Chris Simmonds

Overview of this book

Embedded Linux is a complete Linux distribution employed to operate embedded devices such as smartphones, tablets, PDAs, set-top boxes, and many more. An example of an embedded Linux distribution is Android, developed by Google. This learning path starts with the module Learning Embedded Linux Using the Yocto Project. It introduces embedded Linux software and hardware architecture and presents information about the bootloader. You will go through Linux kernel features and source code and get an overview of the Yocto Project components available. The next module Embedded Linux Projects Using Yocto Project Cookbook takes you through the installation of a professional embedded Yocto setup, then advises you on best practices. Finally, it explains how to quickly get hands-on with the Freescale ARM ecosystem and community layer using the affordable and open source Wandboard embedded board. Moving ahead, the final module Mastering Embedded Linux Programming takes you through the product cycle and gives you an in-depth description of the components and options that are available at each stage. You will see how functions are split between processes and the usage of POSIX threads. By the end of this learning path, your capabilities will be enhanced to create robust and versatile embedded projects. This Learning Path combines some of the best that Packt has to offer in one complete, curated package. It includes content from the following Packt products: ? Learning Embedded Linux Using the Yocto Project by Alexandru Vaduva ? Embedded Linux Projects Using Yocto Project Cookbook by Alex González ? Mastering Embedded Linux Programming by Chris Simmonds
Table of Contents (6 chapters)

In this chapter, you will be presented with various security enhancements tools. Our first stop is the Linux kernel and here, there are two tools, SELinux and grsecurity, both of which are really interesting as well as necessary. Next, the Yocto Project's security-specific layers will also be explained. These include the meta-security and meta-selinux that contain an impressive number of tools and can be used to secure or audit various components of the Linux system. Since this subject is vast, I will also let you inspect various other solutions, both implemented in the Linux kernel but also externally. I hope you enjoy this chapter and that you find this information interesting and useful.

In any operating system, security is a really important concern both for the users and developers. It did not pass much time and developers have started to address these security problems in various methods. This resulted in a number of security methodologies and improvements for available operating systems. In this chapter, a number of security enhancement tools will be introduced along with some policies and verification routines that are defined to ensure that various components, such as the Linux kernel or the Yocto Project, are secure enough to be used. We will also take a look at how various threats or problems are handled as they appear during the course of this chapter.

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.

There is also a workgroup that provides security enhancements and verifications to the Linux kernel to make sure that it is secure and also to maintain a certain level of trust in the security of the Linux ecosystem. Their activities include, but of course, are not limited to verification and testing of critical subsystems for various vulnerabilities or the development of tools to assist in the security Linux kernel. The workgroup also consists of guidance and maintenance of security subsystems or security improvements added to various projects or build tools.

All the other Linux software components have their own security teams. Of course, there are some that do not have these teams well defined, or have some internal rules related to this subject, but they are still aware of security threats that occur around their components and try to repair these vulnerabilities. The Yocto Project tries to help with these problems and in some ways unifies these software components. I hope that some improvements are made over the years in this area.

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.

Currently, it is shipped with a large number of distributions, including the most well known and often used ones, such as Debian, SuSe, Fedora, Red Hat, and Gentoo. It is based on MAC on which administrators can control all interactions with the user space components of a system. It uses the concept of least privileges: here, by default, a user and application have no rights to access the system resources since all of them are granted by an administrator entity. This makes up the part of the system security policies and its emphasis is shown in the following figure:

SELinux

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.

In the context of SELinux, access decisions are made based on the security context of the subject. This may very well be a process associated with a specific user context that is compared with the actual attempted action (such as a file read action), and the security context of the available object, which can be a file.

Before moving on, we will see how the SELinux support can be enabled on a Ubuntu machine. I will first present some basic concepts related to SELinux:

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:

The grsecurity software is free and its development began in 2001, by first porting a number of security enhancing patches from the Openwall Project. It was first released for the 2.4.1 Linux kernel version and since then, development has continued. Over time, it included a PaX bundle of patches that offered the possibility of protecting memory pages. This is done by using a least-privilege approach, which implies that for the execution of a program, no more than the necessary actions should be taken with the help of extra or fewer steps.

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.

I took the liberty of keeping the features of the grsecurity defined in groups, as presented on the grsecurity website. They have been presented in the chapter because I think that knowing its features will help users and developers make the right decision when a security solution is required for their activities. A list with all the grsecurity features is mentioned as follows:

Keeping the features of grsecurity in mind, we can now move towards the installation phase of grsecurity and its administrator called gradm.

The first thing that needs to be done is to get the corresponding packages and patches. As shown in the following command lines, the kernel version for which grsecurity is enabled is 3.14.19:

After the packages are available, their signature needs to be checked. The signature check process for the Linux kernel is big and different from other systems, as follows:

The first time this command is called, the signature is not verified, but the ID field is made available for later use. It is used to identify the public key from the PGP keyserver:

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:

In the patching process, include/linux/compiler-gcc5.h is missing from the source code, so this part of the patch requires skipping. However, after this, the patching process is finished without problems. With this step completed, the configuration phase can continue. There are generic configurations that should work without any extra modifications, but for each distribution there would always be some specific configuration available. To go through them and make sure that each one of them matches with your hardware, the following command can be used:

If you are calling it for the first time, the preceding command has a warning message that will prompt you with the following:

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:

Grsecurity

Inside the grsecurity option, there are two more submenu options. More details about this can be seen in the following screenshot:

Grsecurity

The first option refers to the configuration method, which can be Custom or Automatic:

Grsecurity

The second option refers to the actual available configuration options:

Grsecurity

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.

Once all the dependencies are met, the installation process can start. One last bit of information I'd like to give you is that if the distribution that you use comes with a kernel that has support for grsecurity patches, then you may first want to check it because the patches can also come with the gradm utility pre-installed.

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.

The activities that are mainly realized by the members of the security team consist of being aware of the latest and most dangerous security threats and making sure that they find the fixes, even if it includes fixing themselves and applying the changes inside Yocto's available layers.

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

Since embedded devices have become increasingly competent and powerful, concerns related to security can only be natural. The Yocto Project's initiative layers, here, I am referring to meta-security and meta-selinux, take another step in simplifying the process to ensure secure, hardened, and protected Linux systems. Together, with the detect and fix vulnerability system, they are implemented inside the security team, and help with the ideal of having the same level of security on embedded devices as desktops, along with taking this idea a step further. Having said this, let's proceed to the actual explanation of layers.

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.

As you're already used to, the tools provided are open source packages that are suitable for embedded devices. Inside the meta-security layer a number of them are available, each one trying to offer not only system hardening, but also security checking, security, port scanning, and other useful features that target various levels of security. The following packages are included:

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:

The next package is samhain, a system integrity monitoring and reporting tool used by system administrators that suspect changes or activities on their systems. Its operation is based on a client/server environment and is able to monitor multiple hosts while providing a centralized maintenance and logging system. Besides the already advertised functionalities, it is also able to provide port monitoring, detection of rogue SUID, rootkit detection, and also hidden processes that add to the fact that it offers support for multiple platforms; it is a really interesting tool to have.

The next element here falls in the same category as samhain and it is called tripwire. It is another integrity tool, but this one tries to detect changes for filesystem objects and works as a host intrusion detection system. Information is stored in a database after each file scan and the results are compared with the already available results. Any changes that are made are reported back to the user.

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.

The next tool is redhat-security, which is a collection of scripts used for various problems related to security scanning. The following are a collection of the tools needed to run a redhat-security script to simply invoke one script in the terminal:

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:

Now, the next tool that will be presented is a security scanner that is different from the already presented bastille. Similar to the redhat-security command, this one also executes a number of scripts and can be configured to confirm the user's needs. It is suitable for Debian and Ubuntu users, and before calling the buck-security executable, there are a few configurations that need to be done. Use export GPG_TTY=`tty` to make sure that all the functionalities of the buck-security are enabled and before executing the tool, check inside the conf/buck-security.conf configuration file to check that your needs are fulfilled.

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.

These are the tools supported and offered inside the meta-security layer. I took the liberty of presenting most of them in a succinct manner with the purpose of making them available to you in an easy fashion. It is my opinion that for security problems, one should not overcomplicate things and only keep the solutions that fit your needs best. By presenting a large palette of tools and software components, I tried to do two things: make a larger number of tools available for the general public and also help you make a decision with regard to the tools that might help you in your quest to offer and even maintain a secure system. Of course, curiosity is encouraged, so make sure that you check out any other tools that might help you on your quest to find out more about security, and why they should not be integrated inside the meta-security layer.

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.

The layer's purpose is to enable the support for SELinux and offer it through Poky to anyone in the Yocto Project community for use if required. As mentioned previously, since it influences the whole Linux system, most of the work on this layer is done inside the bbappend files. I hope you enjoy working with the functionalities available inside this layer and maybe even contribute to it if you see fit.

This layer not only contains a number of impressive bbappend files, but also offers a list of packages that could be used not only as SELinux extensions. These packages can be used also for other self-contained purposes too. The available packages inside the meta-selinx layer are as follows:

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:

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.

The last component to be presented is a micro string API for a C language called ustr, which has the benefit of how overheads compared to available APIs. It is very easy to use in the C code as it only includes a header file and is ready for usage. Its overhead over strdup() for strings varies from 85.45 for 1-9 byte strings to 23.85 for 1-198 byte strings. For a simpler example, if an 8 byte storage ustr uses 2 bytes, the strdup() function uses 3 bytes.

This is where other tools and libraries are available alongside the SELinux functionality, although some of them can be used as separate components or in tandem with other available software components that were presented here. This would add more value to the SELinux product, so it only seems fair to find them in the same place.

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.

Meta-security

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.

As you're already used to, the tools provided are open source packages that are suitable for embedded devices. Inside the meta-security layer a number of them are available, each one trying to offer not only system hardening, but also security checking, security, port scanning, and other useful features that target various levels of security. The following packages are included:

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:

The next package is samhain, a system integrity monitoring and reporting tool used by system administrators that suspect changes or activities on their systems. Its operation is based on a client/server environment and is able to monitor multiple hosts while providing a centralized maintenance and logging system. Besides the already advertised functionalities, it is also able to provide port monitoring, detection of rogue SUID, rootkit detection, and also hidden processes that add to the fact that it offers support for multiple platforms; it is a really interesting tool to have.

The next element here falls in the same category as samhain and it is called tripwire. It is another integrity tool, but this one tries to detect changes for filesystem objects and works as a host intrusion detection system. Information is stored in a database after each file scan and the results are compared with the already available results. Any changes that are made are reported back to the user.

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.

The next tool is redhat-security, which is a collection of scripts used for various problems related to security scanning. The following are a collection of the tools needed to run a redhat-security script to simply invoke one script in the terminal:

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:

Now, the next tool that will be presented is a security scanner that is different from the already presented bastille. Similar to the redhat-security command, this one also executes a number of scripts and can be configured to confirm the user's needs. It is suitable for Debian and Ubuntu users, and before calling the buck-security executable, there are a few configurations that need to be done. Use export GPG_TTY=`tty` to make sure that all the functionalities of the buck-security are enabled and before executing the tool, check inside the conf/buck-security.conf configuration file to check that your needs are fulfilled.

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.

These are the tools supported and offered inside the meta-security layer. I took the liberty of presenting most of them in a succinct manner with the purpose of making them available to you in an easy fashion. It is my opinion that for security problems, one should not overcomplicate things and only keep the solutions that fit your needs best. By presenting a large palette of tools and software components, I tried to do two things: make a larger number of tools available for the general public and also help you make a decision with regard to the tools that might help you in your quest to offer and even maintain a secure system. Of course, curiosity is encouraged, so make sure that you check out any other tools that might help you on your quest to find out more about security, and why they should not be integrated inside the meta-security layer.

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.

The layer's purpose is to enable the support for SELinux and offer it through Poky to anyone in the Yocto Project community for use if required. As mentioned previously, since it influences the whole Linux system, most of the work on this layer is done inside the bbappend files. I hope you enjoy working with the functionalities available inside this layer and maybe even contribute to it if you see fit.

This layer not only contains a number of impressive bbappend files, but also offers a list of packages that could be used not only as SELinux extensions. These packages can be used also for other self-contained purposes too. The available packages inside the meta-selinx layer are as follows:

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:

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.

The last component to be presented is a micro string API for a C language called ustr, which has the benefit of how overheads compared to available APIs. It is very easy to use in the C code as it only includes a header file and is ready for usage. Its overhead over strdup() for strings varies from 85.45 for 1-9 byte strings to 23.85 for 1-198 byte strings. For a simpler example, if an 8 byte storage ustr uses 2 bytes, the strdup() function uses 3 bytes.

This is where other tools and libraries are available alongside the SELinux functionality, although some of them can be used as separate components or in tandem with other available software components that were presented here. This would add more value to the SELinux product, so it only seems fair to find them in the same place.

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.

Meta-selinux

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.

The layer's purpose is to enable the support for SELinux and offer it through Poky to anyone in the Yocto Project community for use if required. As mentioned previously, since it influences the whole Linux system, most of the work on this layer is done inside the bbappend files. I hope you enjoy working with the functionalities available inside this layer and maybe even contribute to it if you see fit.

This layer not only contains a number of impressive bbappend files, but also offers a list of packages that could be used not only as SELinux extensions. These packages can be used also for other self-contained purposes too. The available packages inside the meta-selinx layer are as follows:

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:

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.

The last component to be presented is a micro string API for a C language called ustr, which has the benefit of how overheads compared to available APIs. It is very easy to use in the C code as it only includes a header file and is ready for usage. Its overhead over strdup() for strings varies from 85.45 for 1-9 byte strings to 23.85 for 1-198 byte strings. For a simpler example, if an 8 byte storage ustr uses 2 bytes, the strdup() function uses 3 bytes.

This is where other tools and libraries are available alongside the SELinux functionality, although some of them can be used as separate components or in tandem with other available software components that were presented here. This would add more value to the SELinux product, so it only seems fair to find them in the same place.

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.