1.4 Immunizing Network Applications
An automated method for finding network server daemons that should be
profiled is to use the aa-unconfined tool. You can also simply view a report
of this information in the YaST module (refer to
Application Audit Report for instructions).
The aa-unconfined tool uses the command netstat -nlp to
inspect your open ports from inside your computer, detect the programs
associated with those ports, and inspect the set of Novell AppArmor profiles that you
have loaded. aa-unconfined then reports these programs along with the Novell AppArmor
profile associated with each program or reports none
if the
program is not confined.
NOTE:
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:
2325 /sbin/portmap not confined
3702 /usr/sbin/sshd confined
by '/usr/sbin/sshd (enforce)'
4040 /usr/sbin/ntpd confined by '/usr/sbin/ntpd (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)'
5274 /sbin/dhcpcd 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.
|
NOTE:
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 Novell AppArmor profiles to user network client applications is also
dependent on user preferences. Therefore, we leave 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 [email protected]
mailing list along with a use case for the application behavior that you
exercised. The AppArmor team reviews and may submit the work into openSUSE. We cannot guarantee that every profile will
be included, but we make a sincere effort to include as much as possible so
that end users can contribute to the security profiles that ship in openSUSE.
Alternatively, use the AppArmor profile repository to
make your profiles available to other users and to download profiles
created by other AppArmor users and the AppArmor developers. Refer to Section 2.5, Using the External AppArmor Profile Repository for more information on how to use the AppArmor
profile repository.
1.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. openSUSE, by default, stores Web applications in
/srv/www/cgi-bin/. To the maximum extent possible,
each Web application should have an Novell AppArmor profile.
Once you find these programs, you can use the AppArmor to create profiles for them. Refer to
Section 3.1, Adding a Profile Using the Wizard.
Because CGI programs are executed by the Apache Web server, the profile
for Apache itself, usr.sbin.httpd2-prefork for
Apache2 on openSUSE, must be modified to add execute permissions
to each of these programs. For instance, 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 instance,
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 Python script.
NOTE:
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 5.1, Apache ChangeHat.
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 Novell AppArmor
version of Apache calls change_hat() using a
subprofile (a hat
) corresponding to the name of the URI
requested.
NOTE: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 log file when Novell AppArmor
complains about access violations. See Section 6.0, 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 the local system time:
/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 Novell AppArmor version of Apache applies the
DEFAULT_URI hat. This subprofile is basically
sufficient to display an HTML Web page. The
DEFAULT_URI hat that Novell AppArmor provides by default is
the following:
^DEFAULT_URI {
/usr/sbin/suexec2 ixr,
/var/log/apache2/** rwl,
/home/*/public_html/** r,
/srv/www/htdocs/** r,
/srv/www/icons/*.{gif,jpg,png} r,
/usr/share/apache2/** r,
}
To use a single Novell AppArmor profile for all Web pages and CGI scripts
served by Apache, a good approach is to edit the
DEFAULT_URI subprofile.
1.4.2 Immunizing Network Agents
To find network server daemons and network clients (such as fetchmail,
Firefox, amaroK or Banshee) that should be profiled, you should inspect the
open ports on your machine, 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 a Novell 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. Then inspect the machine
to determine which programs are answering on the discovered open ports.
HINT:Refer to the man page of the netstat command for a
detailed reference of all possible options.