|
|
Personal tools |
|
|
/User Guide/AppArmor
From AnnvixConfiguring AppArmor As of 2.0-CURRENT, Annvix includes Novell's AppArmor kernel security system. Unlike SUSE, Annvix does not have anything like YaST to graphically configure AppArmor so this documentation will describe how to configure AppArmor using the CLI tools.
What Is AppArmor?AppArmor is an easy-to-use and effective Linux security system that makes use of the Linux 2.6 kernel's LSM (Linux Security Modules) interface. AppArmor protects the system and applications from other applications that may be exploited by an attacker, or may be behave in ways the administrator doesn't wish, by containing the capabilities of an application via configurable profiles. This proactive approach can protect the operating system from unknown vulnerabilities in profiled applications before an update can be provided, rendering a number of threats inexploitable. AppArmor, unlike RSBAC and SELinux, does not require extensive policies that affect every running system. AppArmor can easily be configured to contain only specific applications and leave the rest of the system alone. To that end, Annvix also includes RSBAC for full MAC (Mandatory Access Control) if required, however AppArmor makes an excellent stop-gap for a number of network-facing applications and services that require additional protection without impeding those applications that do not. If a profile for an application does not exist, AppArmor does not interfere with that application's operation. Starting AppArmorAnnvix installs AppArmor and all it's required packages by default, including apparmor-profiles, apparmor-utils, and apparmor-parser. There is an initscript that starts and stops AppArmor support on Annvix which can be enabled or disabled using: # service apparmor start and # service apparmor stop On the first boot of Annvix, AppArmor is started, using the default profiles, and ready to begin protecting your system. AppArmor Configuration FilesThe heart of AppArmor are it's plain-text configuration (or profile) files. These can be found in the /etc/apparmor.d directory. The files contained here take the form of full system path names, so /usr/bin/exim would have a profile named /etc/apparmor.d/usr.bin.exim. Configuration files for the operation of AppArmor itself are contained in the /etc/apparmor directory. In the /etc/apparmor/profiles/extras directory are a number of profile files that can be experimented with and/or used but are not enabled by default for various reasons. The Anatomy of an AppArmor ProfileAn AppArmor profile consists of a file in the /etc/apparmor.d directory with a filename similar to the application's path name, such as /usr/bin/exim would become /etc/apparmor.d/usr.bin.exim. An example profile for /sbin/klogd would be named /etc/apparmor.d/sbin.klogd and contain:
# $Id: sbin.klogd 12 2006-04-12 21:35:41Z steve-beattie $
# ------------------------------------------------------------------
#
# Copyright (C) 2002-2005 Novell/SUSE
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation.
#
# ------------------------------------------------------------------
#include <tunables/global>
/sbin/klogd {
#include <abstractions/base>
capability sys_admin,
/boot/System.map* r,
/proc/kmsg r,
/sbin/klogd rix,
/var/log/boot.msg rwl,
/var/run/klogd.pid rwl,
}
You can see that comments are possible in the profile, lines beginning with '#' are comments, the exception being #include statements (more on that in a moment). The application's profile begins with the full name and path of the program to contain. Note that this is one fundamental difference between AppArmor and other solutions like RSBAC and SELinux. AppArmor performs path-based operations on programs where as RSBAC and SELinux are inode-based. In other words, if you have a hardlink copy of the file, the hardlink would not be protected without it's own profile (whereas in RSBAC and SELinux the hardlink file, since it shares the same inode, would be protected). The curly braces ({}) serve as a container for include statements to other profiles and also for path and capability entries. The include statement pulls in another profile (in this case, /etc/apparmor.d/abstractions/base) to re-use other profile directives (such as access to common libraries and files). The capability entry statements enable each of the 29 POSIX.1e draft capabilities (in this case, the sys_admin capability). Finally, path-based entries indicate access rights for the program being contained. In this case, the /boot/System.map* files are available for reading, /proc/kmsg is available for reading, /sbin/klogd (the program itself) is available for reading and executing, /var/log/boot.msg is available for reading, writing and linking, and /var/run/klogd.pid is also available for reading, writing, and linking. Path entries take the form "/path/to/file [mode]". The path entry can be the full path and filename or can be a path using regular expression globbing. When an application has a profile, only those files, modes, and POSIX capabilities specified can be used by the application. These restrictions are in addition to native ACLs (so, for instance, if a program does not have access to /etc/passwd, permitting access in the profile will not magically grant access to the file). File Permission Access ModesThe following is a list of file permission access modes that AppArmor uses:
Read mode allows the program to have read access to the resource. Read access is required for shell scripts and other interpreted content and determines if an executing process can core dump or be attached to with ptrace(2). Write mode allows the program to have write access to the resource. This must be available for files to be unlinked (removed). Discrete profile execute mode is a mode that requires that a discrete security profile is defined for a resource executed at an AppArmor domain transition. If no profile is defined, access is denied. This mode is incompatible with inherit and unconstrained execute entries. Unconstrained execute mode is a mode that allows the program to execute a resource without any AppArmor profile being applied to the executed resource. This mode is incompatible with inherit and discrete execute entries. The unconstrained execute mode is useful when a confined program needs to be able to perform a privileged operation, such as rebooting the machine. Inherit execute mode is a mode that prevents the normal AppArmor domain transition on execve(2) when the profiled application executes the resource. Instead, the executed resource inherits the constraints of the current profile. This mode is incompatible with the discrete and unconstrained execute entries. The inherit execute mode is useful when a confined program needs to call another confined program without gaining the permissions of the target's profile or losing the permissions of the current profile. Link mode is a mode that grants access to symlinks and hardlinks the privileges to unlink (or delete) files. When a link is created, the file that is linked to must have the same access permissions as the link created (with the exception that the destination does not have to have link access). CapabilitiesThe POSIX.1e capabilities are noted and listed in the capabilities(7) man page. Using genprof to Profile an Applicationgenprof is the utility used to generate profiles for applictions. What this program does is scan /var/log/system/audit/current for events, which look like: type=APPARMOR msg=audit(1182207408.754:34): PERMITTING access to capability 'setgid' (ntpd(18040) profile /usr/sbin/ntpd active /usr/sbin/ntpd) type=APPARMOR msg=audit(1182207408.754:35): PERMITTING access to capability 'setuid' (ntpd(18040) profile /usr/sbin/ntpd active /usr/sbin/ntpd) type=APPARMOR msg=audit(1182207408.754:36): PERMITTING r access to /etc/hosts (ntpd(18039) profile /usr/sbin/ntpd active /usr/sbin/ntpd) If a capability is requested but not available for the program, the audit log will note this. genprof takes these and allows you to build profiles based on this information. For instance, to profile /usr/sbin/ntpd, use: # genprof /usr/sbin/ntpd Then, in another terminal, execute /usr/sbin/ntpd (or run the runscript) and let it run. When it has run sufficiently long enough for it to do most of what it would do, press S in genprof to scan the audit log for events. It will notify you as to what events took place, and you can determine whether or not to allow the events (and thus add them to the profile). This is done by creating a new profile and placing it into "complain" mode. Once you are done, press F to finish, and the new profile is written and placed into "enforce" mode. |
 |
|
|
| |||