33 Immunizing programs #
Effective hardening of a computer system requires minimizing the number of programs that mediate privilege, then securing the programs as much as possible. With AppArmor, you only need to profile the programs that are exposed to attack in your environment, which drastically reduces the amount of work required to harden your computer. AppArmor profiles enforce policies to make sure that programs do what they are supposed to do, but nothing else.
AppArmor provides immunization technologies that protect applications from the inherent vulnerabilities they possess. After installing AppArmor, setting up AppArmor profiles, and rebooting the computer, your system becomes immunized because it begins to enforce the AppArmor security policies. Protecting programs with AppArmor is called immunizing.
Administrators need only concern themselves with the applications that are vulnerable to attacks, and generate profiles for these. Hardening a system thus comes down to building and maintaining the AppArmor profile set and monitoring any policy violations or exceptions logged by AppArmor's reporting facility.
Users should not notice AppArmor. It runs “behind the scenes” and does not require any user interaction. Performance is not noticeably affected by AppArmor. If some activity of the application is not covered by an AppArmor profile or if some activity of the application is prevented by AppArmor, the administrator needs to adjust the profile of this application.
AppArmor sets up a collection of default application profiles to protect standard Linux services. To protect other applications, use the AppArmor tools to create profiles for the applications that you want protected. This chapter introduces the philosophy of immunizing programs. Proceed to Chapter 34, Profile components and syntax, Chapter 36, Building and managing profiles with YaST, or Chapter 37, Building profiles from the command line if you are ready to build and manage AppArmor profiles.
AppArmor provides streamlined access control for network services by specifying which files each program is allowed to read, write, and execute, and which type of network it is allowed to access. This ensures that each program does what it is supposed to do, and nothing else. AppArmor quarantines programs to protect the rest of the system from being damaged by a compromised process.
AppArmor is a host intrusion prevention or mandatory access control scheme. Previously, access control schemes were centered around users because they were built for large timeshare systems. Alternatively, modern network servers largely do not permit users to log in, but instead provide a variety of network services for users (such as Web, mail, file, and print servers). AppArmor controls the access given to network services and other programs to prevent weaknesses from being exploited.
To get a more in-depth overview of AppArmor and the overall concept behind it, refer to Section 31.2, “Background information on AppArmor profiling”.
33.1 Introducing the AppArmor framework #
This section provides a very basic understanding of what is happening “behind the scenes” (and under the hood of the YaST interface) when you run AppArmor.
An AppArmor profile is a plain text file containing path entries and access permissions. See Section 34.1, “Breaking an AppArmor profile into its parts” for a detailed reference profile. The directives contained in this text file are then enforced by the AppArmor routines to quarantine the process or program.
The following tools interact in the building and enforcement of AppArmor profiles and policies:
aa-statusaa-statusreports various aspects of the current state of the running AppArmor confinement.aa-unconfinedaa-unconfineddetects any application running on your system that listens for network connections and is not protected by an AppArmor profile. Refer to Section 37.7.3.12, “aa-unconfined—identifying unprotected processes” for detailed information about this tool.aa-autodepaa-autodepcreates a basic framework of a profile that needs to be fleshed out before it is put to use in production. The resulting profile is loaded and put into complain mode, reporting any behavior of the application that is not (yet) covered by AppArmor rules. Refer to Section 37.7.3.1, “aa-autodep—creating approximate profiles” for detailed information about this tool.aa-genprofaa-genprofgenerates a basic profile and asks you to refine this profile by executing the application and generating log events that need to be taken care of by AppArmor policies. You are guided through a series of questions to deal with the log events that have been triggered during the application's execution. After the profile has been generated, it is loaded and put into enforce mode. Refer to Section 37.7.3.8, “aa-genprof—generating profiles” for detailed information about this tool.aa-logprofaa-logprofinteractively scans and reviews the log entries generated by an application that is confined by an AppArmor profile in both complain and enforced modes. It assists you in generating new entries in the profile concerned. Refer to Section 37.7.3.9, “aa-logprof—scanning the system log” for detailed information about this tool.aa-easyprofaa-easyprofprovides an easy-to-use interface for AppArmor profile generation.aa-easyprofsupports the use of templates and policy groups to quickly profile an application. Note that while this tool can help with policy generation, its utility is dependent on the quality of the templates, policy groups and abstractions used.aa-easyprofmay create a profile that is less restricted than creating the profile withaa-genprofandaa-logprof.aa-complainaa-complaintoggles the mode of an AppArmor profile from enforce to complain. Violations to rules set in a profile are logged, but the profile is not enforced. Refer to Section 37.7.3.2, “aa-complain—entering complain or learning mode” for detailed information about this tool.aa-enforceaa-enforcetoggles the mode of an AppArmor profile from complain to enforce. Violations to rules set in a profile are logged and not permitted—the profile is enforced. Refer to Section 37.7.3.6, “aa-enforce—entering enforce mode” for detailed information about this tool.aa-disableaa-disabledisables the enforcement mode for one or more AppArmor profiles. This command will unload the profile from the kernel and prevent it from being loaded on AppArmor start-up. Theaa-enforceandaa-complainutilities may be used to change this behavior.aa-execaa-execlaunches a program confined by the specified AppArmor profile and/or namespace. If both a profile and namespace are specified, the command will be confined by the profile in the new policy namespace. If only a namespace is specified, the profile name of the current confinement will be used. If neither a profile or namespace is specified, the command will be run using standard profile attachment—as if run withoutaa-exec.aa-notifyaa-notifyis a handy utility that displays AppArmor notifications in your desktop environment. You can also configure it to display a summary of notifications for the specified number of recent days. For more information, see Section 37.7.3.13, “aa-notify”.
33.2 Determining programs to immunize #
Now that you have familiarized yourself with AppArmor, start selecting the applications for which to build profiles. Programs that need profiling are those that mediate privilege. The following programs have access to resources that the person using the program does not have, so they grant the privilege to the user when used:
cronJobsPrograms that are run periodically by
cron. Such programs read input from a variety of sources and can run with special privileges, sometimes with as much asrootprivilege. For example,croncan run/usr/sbin/logrotatedaily to rotate, compress, or even mail system logs. For instructions for finding these types of programs, refer to Section 33.3, “Immunizingcronjobs”.- Web applications
Programs that can be invoked through a Web browser, including CGI Perl scripts, PHP pages, and more complex Web applications. For instructions for finding these types of programs, refer to Section 33.4.1, “Immunizing web applications”.
- Network agents
Programs (servers and clients) that have open network ports. User clients, such as mail clients and Web browsers mediate privilege. These programs run with the privilege to write to the user's home directory and they process input from potentially hostile remote sources, such as hostile Web sites and e-mailed malicious code. For instructions for finding these types of programs, refer to Section 33.4.2, “Immunizing network agents”.
Conversely, unprivileged programs do not need to be profiled. For
example, a shell script might invoke the cp
program to copy a file. Because cp does not by
default have its own profile or subprofile, it inherits the profile
of the parent shell script. Thus cp can copy any
files that the parent shell script's profile can read and write.
33.3 Immunizing cron jobs #
To find programs that are run by
cron, inspect your local
cron configuration.
Unfortunately, cron configuration
is rather complex, so there are numerous files to inspect. Periodic
cron jobs are run from these
files:
/etc/crontab /etc/cron.d/* /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/*
The crontab command lists/edits the current user's
crontab. To manipulate root's
cron jobs, first become
root, and then edit the tasks with crontab -e
or list them with crontab -l.
33.4 Immunizing network applications #
An automated method for finding network server daemons that should be
profiled is to use the aa-unconfined tool.
The aa-unconfined tool uses the command
netstat -nlp to inspect open ports from inside your
computer, detect the programs associated with those ports, and inspect
the set of AppArmor profiles that you have loaded.
aa-unconfined then reports these programs along with
the AppArmor profile associated with each program, or reports
“none” (if the program is not confined).
If you create a new profile, you must restart the program that has been profiled to have it be effectively confined by AppArmor.
Below is a sample aa-unconfined output:
37021 /usr/sbin/sshd2 confined by '/usr/sbin/sshd3 (enforce)' 4040 /usr/sbin/smbd confined by '/usr/sbin/smbd (enforce)' 4373 /usr/lib/postfix/master confined by '/usr/lib/postfix/master (enforce)' 4505 /usr/sbin/httpd2-prefork confined by '/usr/sbin/httpd2-prefork (enforce)' 646 /usr/lib/wicked/bin/wickedd-dhcp4 not confined 647 /usr/lib/wicked/bin/wickedd-dhcp6 not confined 5592 /usr/bin/ssh not confined 7146 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (complain)'
The first portion is a number. This number is the process ID number (PID) of the listening program. | |
The second portion is a string that represents the absolute path of the listening program | |
The final portion indicates the profile confining the program, if any. |
aa-unconfined requires root privileges and
should not be run from a shell that is confined by an AppArmor profile.
aa-unconfined does not distinguish between one network
interface and another, so it reports all unconfined processes, even those
that might be listening to an internal LAN interface.
Finding user network client applications is dependent on your user
preferences. The aa-unconfined tool detects and
reports network ports opened by client applications, but only those
client applications that are running at the time the
aa-unconfined analysis is performed. This is a problem
because network services tend to be running all the time, while network
client applications tend only to be running when the user is interested
in them.
Applying AppArmor profiles to user network client applications is also dependent on user preferences. Therefore, we leave the profiling of user network client applications as an exercise for the user.
To aggressively confine desktop applications, the
aa-unconfined command supports a
--paranoid option, which reports all processes running
and the corresponding AppArmor profiles that might or might not be
associated with each process. The user can then decide whether each of
these programs needs an AppArmor profile.
If you have new or modified profiles, you can submit them to the <apparmor@lists.ubuntu.com> mailing list along with a use case for the application behavior that you exercised. The AppArmor team reviews and may submit the work into SUSE Linux Enterprise Server. We cannot guarantee that every profile will be included, but we make a sincere effort to include as much as possible.
33.4.1 Immunizing web applications #
To find Web applications, investigate your Web server configuration. The
Apache Web server is highly configurable and Web applications can be
stored in many directories, depending on your local configuration.
SUSE Linux Enterprise Server, by default, stores Web applications in
/srv/www/cgi-bin/. To the maximum extent possible,
each Web application should have an AppArmor profile.
Once you find these programs, you can use the
aa-genprof and aa-logprof tools to
create or update their AppArmor profiles.
Because CGI programs are executed by the Apache Web server, the profile
for Apache itself, usr.sbin.httpd2-prefork for
Apache2 on SUSE Linux Enterprise Server, must be modified to add execute permissions
to each of these programs. For example, adding the line
/srv/www/cgi-bin/my_hit_counter.pl rPx grants Apache
permission to execute the Perl script
my_hit_counter.pl and requires that there be a
dedicated profile for my_hit_counter.pl. If
my_hit_counter.pl does not have a dedicated profile
associated with it, the rule should say
/srv/www/cgi-bin/my_hit_counter.pl rix to cause
my_hit_counter.pl to inherit the
usr.sbin.httpd2-prefork profile.
Some users might find it inconvenient to specify execute permission for
every CGI script that Apache might invoke. Instead, the administrator
can grant controlled access to collections of CGI scripts. For example,
adding the line /srv/www/cgi-bin/*.{pl,py,pyc} rix
allows Apache to execute all files in
/srv/www/cgi-bin/ ending in .pl
(Perl scripts) and .py or .pyc
(Python scripts). As above, the ix part of the rule
causes Python scripts to inherit the Apache profile, which is
appropriate if you do not want to write individual profiles for each CGI
script.
If you want the subprocess confinement module
(apache2-mod-apparmor) functionality when Web
applications handle Apache modules (mod_perl and
mod_php), use the ChangeHat features when you add
a profile in YaST or at the command line. To take advantage of the
subprocess confinement, refer to
Section 38.2, “Managing ChangeHat-aware applications”.
Profiling Web applications that use mod_perl and
mod_php requires slightly different handling. In
this case, the “program” is a script interpreted directly
by the module within the Apache process, so no exec happens. Instead,
the AppArmor version of Apache calls change_hat()
using a subprofile (a “hat”) corresponding to the name of
the URI requested.
The name presented for the script to execute might not be the URI, depending on how Apache has been configured for where to look for module scripts. If you have configured your Apache to place scripts in a different place, the different names appear in the log file when AppArmor complains about access violations. See Chapter 40, Managing profiled applications.
For mod_perl and mod_php
scripts, this is the name of the Perl script or the PHP page requested.
For example, adding this subprofile allows the
localtime.php page to execute and access to the
local system time and locale files:
/usr/bin/httpd2-prefork {
# ...
^/cgi-bin/localtime.php {
/etc/localtime r,
/srv/www/cgi-bin/localtime.php r,
/usr/lib/locale/** r,
}
}
If no subprofile has been defined, the AppArmor version of Apache applies
the DEFAULT_URI hat. This subprofile is
sufficient to display a Web page. The
DEFAULT_URI hat that AppArmor provides by
default is the following:
^DEFAULT_URI {
/usr/sbin/suexec2 mixr,
/var/log/apache2/** rwl,
@{HOME}/public_html r,
@{HOME}/public_html/** r,
/srv/www/htdocs r,
/srv/www/htdocs/** r,
/srv/www/icons/*.{gif,jpg,png} r,
/srv/www/vhosts r,
/srv/www/vhosts/** r,
/usr/share/apache2/** r,
/var/lib/php/sess_* rwl
}
To use a single AppArmor profile for all Web pages and CGI scripts served
by Apache, a good approach is to edit the
DEFAULT_URI subprofile. For more information on
confining Web applications with Apache, see
Chapter 38, Profiling your Web applications using ChangeHat.
33.4.2 Immunizing network agents #
To find network server daemons and network clients (such as
fetchmail or Firefox) that need to be profiled,
you should inspect the open ports on your machine. Also consider
the programs that are answering on those ports, and provide profiles
for as many of those programs as possible. If you provide profiles
for all programs with open network ports, an attacker cannot get to
the file system on your machine without passing through an AppArmor
profile policy.
Scan your server for open network ports manually from outside the
machine using a scanner (such as nmap), or from inside the machine using
the netstat --inet -n -p command as root.
Then, inspect the machine to determine which programs are answering on
the discovered open ports.
Refer to the man page of the netstat command for a
detailed reference of all possible options.