The security choices available for Linux, starting with the ones you're most familiar, are: user name and password required for login to the system, and permissions set on files that control what can be done based on your identity. For lack of a better term, call this the default security model. The default security model has flaws in that what can be controlled thereafter is fairly sparse: you can control what files can be executed, read, and written, but not what system functionality can be accessed. This means that a user who gains the rights to execute files on the system has free reign over what that executable can do; for example, it could open network ports and begin sending data, or install kernel modules that could crash the system. In order to have fine-grained access control, you need to use SELinux or PAM to control the system; these systems allow the administrator to control what resources can be accessed and which files can be read and written to. The need for security is to some extent dictated by the device and the configuration of the kernel. A device, for example, without an Ethernet port or networking built into the kernel isn't susceptible to attacks across the network; therefore, spending effort to ensure that this isn't possible is wasteful. Before deciding on a security technology, understand the susceptibilities of the system and how it is used so you can formulate requirements in order to judge what security works best for the device. All security mechanisms just described rely on the Linux Security Model (LSM) infrastructure, which is a generalized framework for handling security enforcement. The LSM doesn't make decisions about what to do but checks with software providing security policy information to see if the requested action is permissible.
This is the standard Linux security, which is much like the standard Unix security from decades past: you're challenged for your password at login, and if you present the right one, you're allowed access to the system. Users can belong to a number of groups, with one group having the same name as the user.
Based on your group and user, you have the ability to read, write, create, or execute files. Files and directories are owned by a certain user; being owner gives you the ability modify the permissions for a file. True to its name, the built-in security system is a part of Linux. There's nothing you have to do to get what's offered. Because it's built into Linux as the default security system, is doesn't add anything to the size of the system-and for those who are counting every byte, this matters. Using this system is as easy as creating additional entries in the /etc/groups and /etc/passwd files, assigning files to groups and owners using chown, and then setting permissions using chmod. Just as with a desktop system, the regular user for running applications shouldn't be root; rather, you should create a user for running the application and make an entry in /etc/passwd for that user.
SELinux is a project undertaken by the National Security Agency (NSA) to harden the Linux kernel; the changes were accepted into the Linux kernel early in the 2.6 release cycle. The patches, now incorporated as part of the Linux kernel project, involve controlling access to kernel resources like memory, the file system, networking, and external buses like PCMCIA and USB. By configuring access rights to these resources, the system administrator can grant specific rights to specific users to not only execute programs but also control what in the operating system those programs can do while running. SELinux is a good security model for an embedded system that is offering services over a network or a system that is running a set of programs that may not be known when the device ships. Consider a device like a network switch or a cell phone: these devices leave the factory with a set of programs, and third parties can then write additional software that the user loads on the device. In this case, it's important to guard the system from programs that either accidentally or purposely compromise the system by accessing resources that belong to another process. In order to get SELinux running on your board, you need to enable it in the kernel and have some user-space programs help with creating security profiles.
SEEdit is a group of tools and starting-point security policies created for embedded Linux targets by Hitachi, LTD. The goal of this project is to have a simple set of policies that are both small in size and appropriate for embedded systems and that can be installed with ease. The tool also includes a GUIbased policy editor that insulates you from some of the complexities of editing SELinux policies. As part of this project, a set of SELinux commands have been added to BusyBox: load_policy, setfiles, restorecon, and is_selinux_enabled. This means you don't have to cross-compile the larger SELinux commands for the target. When you're configuring BusyBox on a system that is using SELinux, you need to enable Support NSA Security Enhanced Linux under the General Configuration menu in the BusyBox configuration menu. After you do so, SELinux Utilities appears on the top-level menu, and you can select the BusyBox builds of these commands.
Pluggable Authentication Modules (PAM) is an access-control system that provides an authentication system. This means PAM provides the tools to verify the identity of the user making the request for resources; it then lets the program decide what powers to grant the user based on that information. This is very different from SELinux, even though SELinux performs the job of authentication like PAM. SELinux also contains the rules for what resources the user can access, which is unlike the way PAM modules do their job.
On a desktop system, the directory pam.d contains a file for each of the PAM modules. This is an acceptable configuration for an embedded system, but it requires a little more space. Putting all the PAM information for an embedded system in one file isn't as flexible but does save a little space. Most embedded systems aren't as complex as a desktop system, so the additional administrative overhead of managing more than one file isn't worth the marginal gain in flexibility. The configuration files specify some number of PAM modules, so those modules must be crosscompiled for your target machine. To get sources for these modules, download the PAM sources, stored at ftp://ftp.kernel.org/pub/linux/libs/pam/library/. In this directory is a file named LATEST_IS_<filename> with the name of the file in the directory to download. The process puts a complete installation of PAM in your root file system, which may be more than is necessary for the embedded device. You need to remove the modules not used in your PAM configuration file; for example, unused PAM modules in the /lib/security directory can be removed, and the remainder can be stripped to further reduce space requirements. In addition to the extra library files, a standard PAM installation includes a group of files installed under etc/security that you can remove if you aren't using PAM's access-control features. One thing that may sneak past you as you're configuring this program is that it attempts to compile the program even if it can't find a symbol it needs: yywrap, which is part of the flex tokenizer package. PAM uses Flex to parse the configuration files that it uses. You need to cross-compile Flex for your toolchain if the compilation fails with a message that yywrap can't be found.
/path/to/sysroot is the sysroot path of your toolchain. These files can be installed in any directory on your development machine, as long as the linker is able to find them. You shouldn't install these files in the root file system of the target device, because they're only used to build the PAM libraries and helpers. After it's built and installed, the software on the target device can begin using PAM for authentication. For example, if the device is running Samba, then Samba needs entries in the pam.conf file if you want to use something different than the "other" configuration. Samba also needs to be configured with the right settings so it knows to use PAM for authentication. When you're working on the project, you need to ensure that each of the services you expect to use PAM is properly configured, because this is a package-specific setting.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Donnie F. Rierson at 02022010
1. Why is Linux such an incredible piece of sowtware
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.