mirror of
https://gitlab.com/apparmor/apparmor.git
synced 2025-03-04 08:24:42 +01:00
Pam_apparmor: initial markdown conversions
Steve Beattie
parent
46d2691762
commit
87607ba424
2 changed files with 390 additions and 0 deletions
114
Pam_apparmor.md
Normal file
114
Pam_apparmor.md
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
pam\_apparmor
|
||||
=============
|
||||
|
||||
AppArmor has a
|
||||
[PAM](http://en.wikipedia.org/wiki/Pluggable_Authentication_Modules)
|
||||
module that a can be used to attach profiles based off of
|
||||
authentication done at the user or task level.
|
||||
|
||||
pam\_apparmor was built to support several different use cases,
|
||||
including:
|
||||
|
||||
- [Role-based access controls (RBAC)](AppArmorRBAC)
|
||||
- [Multilevel style security](AppArmorMLS)
|
||||
|
||||
For example, you can use AppArmor to support the common case of users
|
||||
being grouped into different groups such as 'staff', 'students',
|
||||
and 'admins'; or 'staff', 'admin', and 'audit'. By providing common
|
||||
privileges in similarly named hats available to all the services (such
|
||||
as sshd, ftpd, smbd, crond, atd, xdm/kdm/gdm, mgetty/mingetty/ngetty,
|
||||
sudo), a site could easily restrict users to just the privileges
|
||||
necessary for their own work, while granting more powerful privileges
|
||||
to another class of users for their work.
|
||||
|
||||
In the past, 'restricted shells' have been used to try to emulate some
|
||||
of these features, but all programs that the restricted shells spawned
|
||||
had to be written very carefully. General-purpose text editors such
|
||||
as emacs and vim have had dozens of security updates to try to fix
|
||||
escape hatches when they are called via a restricted counterpart. Some
|
||||
programs, such as mutt, don't even have restricted versions, because
|
||||
there are so many ways to usefully execute any program, or read and
|
||||
write files.
|
||||
|
||||
pam\_apparmor means that your restricted environments can include
|
||||
any program, with any configuration, and you can be sure your users
|
||||
will have only the privileges that you explicitly grant in the
|
||||
AppArmor configuration files. Of course, AppArmor can be used in
|
||||
addition to restricted shells and editors and programs, if you're a
|
||||
belts-and-suspenders type of person. And it integrates very cleanly
|
||||
with traditional Unix DAC and ACLs; the 'owner' permission attribute
|
||||
can even be used to mitigate against mistakes in Unix DAC and ACLs.
|
||||
|
||||
The library is named /lib/security/pam\_apparmor.so and can be
|
||||
integrated into any PAM-aware application by using the corresponding
|
||||
/etc/pam.d/ configuration file.
|
||||
|
||||
Configuring pam\_apparmor
|
||||
-------------------------
|
||||
|
||||
To add pam\_apparmor support to a pam enabled application, add a line
|
||||
like the following to the pam configuration file for the application
|
||||
(usually stored in /etc/pam.d/):
|
||||
|
||||
```
|
||||
session optional pam_apparmor.so
|
||||
```
|
||||
|
||||
Likely you will to want add the pam\_apparmor module after other
|
||||
session management modules. If you make the pam\_apparmor module
|
||||
'required' instead of 'optional', the session will abort if
|
||||
pam\_apparmor is not able to successfully find a hat to change\_hat
|
||||
into. Be careful when making it required; it is possible to cause
|
||||
all attempted logins to the service to fail if the apparmor policy
|
||||
is insufficient.
|
||||
|
||||
By default, pam\_apparmor will attempt to change\_hat into a hat based
|
||||
on the primary group name of the user logging in. If that hat fails to
|
||||
exist, the module will attempt to change\_hat into a hat named DEFAULT
|
||||
(it is recommended to ensure this hat exists in the apparmor profiles
|
||||
for applications using pam\_apparmor).
|
||||
|
||||
However, this is configurable by adding an option to the pam
|
||||
configuration line to modify what order and what attributes
|
||||
pam\_apparmor will attempt to use when attempting to change\_hat. To
|
||||
do so, add 'order=' followed by a comma separated list of types of
|
||||
hats to try. The type of hats available are:
|
||||
|
||||
* 'user' - the username will be used as the hatname
|
||||
* 'group' - the primary group will be used as the hatname
|
||||
* 'default' - the string 'DEFAULT' will be used as the hatname.
|
||||
Generally, this should be the hat of last resort.
|
||||
|
||||
The order in the list determines the order the hat will be attempted. Some example configurations:
|
||||
|
||||
|
||||
##### The default behavior
|
||||
|
||||
```
|
||||
session optional pam_apparmor.so order=group,default
|
||||
```
|
||||
|
||||
##### Attempt to use only the username
|
||||
|
||||
```
|
||||
session optional pam_apparmor.so order=user
|
||||
```
|
||||
|
||||
##### Username, groupname, DEFAULT
|
||||
|
||||
Use the username, followed by the primary groupname, followed by
|
||||
DEFAULT if the prior hats do not exist in the apparmor profile:
|
||||
|
||||
```
|
||||
session optional pam_apparmor.so order=user,group,default
|
||||
```
|
||||
|
||||
You can also add a 'debug' flag to the pam\_apparmor session line;
|
||||
this will cause the pam module to report more of what it is attempting
|
||||
to do to syslog.
|
||||
|
||||
pam\_apparmor example
|
||||
---------------------
|
||||
|
||||
A working pam\_apparmor example can be seen in
|
||||
[Pam\_apparmor\_example](Pam_apparmor_example).
|
||||
276
Pam_apparmor_example.md
Normal file
276
Pam_apparmor_example.md
Normal file
|
|
@ -0,0 +1,276 @@
|
|||
Example pam\_apparmor configuration
|
||||
===================================
|
||||
|
||||
AppArmor allows you great flexibility in setting up policies
|
||||
with pam\_apparmor. This example provides a basic pam\_apparmor
|
||||
configuration using the change\_hat methodolgy (the current
|
||||
implementation) that can be extended later for your site
|
||||
requirements. In this example, we confine the 'su' binary such
|
||||
that when a user uses su to run commands as another user, AppArmor
|
||||
will apply access controls on the changed to user. This can later
|
||||
be extended to other binaries such as 'sshd' and 'login'. This
|
||||
example is known to work on Ubuntu 10.04 LTS with AppArmor 2.5, but
|
||||
should work fine with AppArmor 2.3 (it is based on techniques from
|
||||
[RBAC\_2\_3](RBAC_2_3)).
|
||||
|
||||
It is recommended while configuring pam\_apparmor that you login to
|
||||
another terminal as root so that in case something goes wrong with
|
||||
your configuration, you can use this terminal to make any necessary
|
||||
changes. Eg:
|
||||
|
||||
```
|
||||
$ sudo -i
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```
|
||||
$ su -
|
||||
```
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The idea behind pam\_apparmor is simple: when a someone uses a confined
|
||||
binary, that binary will transition to an AppArmor role via PAM. So
|
||||
if 'su' is configured for use with pam\_apparmor, when a user invokes
|
||||
'su', PAM is consulted. When the PAM session is started, pam\_apparmor
|
||||
will change\_hat() to either a hat that matches the username, a hat
|
||||
that matches the primary group, or the DEFAULT hat (which depends on
|
||||
the order specified in the pam configuration). This hat (typically)
|
||||
provides a rudimentary policy and declares a transition to a role
|
||||
profile when the user's shell is started. So with our su example:
|
||||
|
||||
1. The user does 'su - gray'
|
||||
2. su then performs a change\_hat() (via pam\_apparmor) to ^gray
|
||||
3. When gray's shell is started, the user transitions to the confined\_user profile
|
||||
|
||||
Put simply, when the user does 'su - gray', the user changes to the
|
||||
'confined\_user' role.
|
||||
|
||||
Initial configuration
|
||||
---------------------
|
||||
|
||||
Make sure you have pam\_apparmor available on your system. For example,
|
||||
on Ubuntu:
|
||||
|
||||
```
|
||||
$ sudo apt-get install libpam-apparmor
|
||||
```
|
||||
|
||||
Next, integrate pam\_apparmor with su by adjusting /etc/pam.d/su
|
||||
to have:
|
||||
|
||||
```
|
||||
# omit 'debug' when in production
|
||||
session optional pam_apparmor.so order=user,group,default debug
|
||||
```
|
||||
|
||||
pam\_apparmor policy files
|
||||
--------------------------
|
||||
|
||||
In this example, we will break out the pam\_apparmor policy into
|
||||
various files to help illustrate the various parts and how they work
|
||||
together. It also serves as a method to make maintaining your policy
|
||||
easier. AppArmor doesn't care if the files are broken apart or in one
|
||||
monolithic file, but we will use the following files in this example:
|
||||
|
||||
- /etc/apparmor.d/pam\_binaries: policy for binaries with profiles (eg 'su')
|
||||
- /etc/apparmor.d/pam\_roles: policy for hats referenced in pam/mappings (ie, our 'roles')
|
||||
- /etc/apparmor.d/pam/mappings: hats referenced in pam\_binaries
|
||||
|
||||
In other words, /etc/apparmor.d/pam\_binaries contains policy
|
||||
for the binaries that are integrated with pam (in this case
|
||||
'su'). /etc/apparmor.d/pam\_roles contains the policy for the different
|
||||
roles at your site, and /etc/apparmor.d/pam/mappings maps login names
|
||||
to an AppArmor role.
|
||||
|
||||
### /etc/apparmor.d/pam\_binaries
|
||||
|
||||
Create /etc/apparmor.d/pam\_binaries to have:
|
||||
|
||||
```
|
||||
#
|
||||
# This file contains the policy for the confined binaries that use
|
||||
# libpam-apparmor.
|
||||
#
|
||||
#include <tunables/global>
|
||||
/bin/su {
|
||||
#include <abstractions/authentication>
|
||||
#include <abstractions/base>
|
||||
#include <abstractions/nameservice>
|
||||
# Include the file with all of our username/group to role mappings
|
||||
#include <pam/mappings>
|
||||
capability chown,
|
||||
capability setgid,
|
||||
capability setuid,
|
||||
owner /etc/environment r,
|
||||
owner /etc/shells r,
|
||||
owner /etc/default/locale r,
|
||||
owner @{HOMEDIRS}/*/.Xauthority rw,
|
||||
owner @{HOMEDIRS}/*/.Xauthority-c w,
|
||||
owner @{HOMEDIRS}/*/.Xauthority-l w,
|
||||
@{HOME}/.xauth* rw,
|
||||
owner @{PROC}/sys/kernel/ngroups_max r,
|
||||
/usr/bin/xauth rix,
|
||||
owner /var/run/utmp rwk,
|
||||
}
|
||||
```
|
||||
|
||||
### /etc/apparmor.d/pam\_roles
|
||||
|
||||
Now create different roles in /etc/apparmor.d/pam\_roles:
|
||||
|
||||
```
|
||||
#
|
||||
# This file contains the roles as referenced by pam/mappings
|
||||
#
|
||||
#include <tunables/global>
|
||||
# By default, allow users to read, lock and link to their own files anywhere,
|
||||
# but only write to files in their home directory. Only allow limited execution
|
||||
# of files.
|
||||
profile default_user {
|
||||
#include <abstractions/base>
|
||||
#include <abstractions/bash>
|
||||
#include <abstractions/consoles>
|
||||
#include <abstractions/nameservice>
|
||||
deny capability sys_ptrace,
|
||||
owner /** rkl,
|
||||
@{PROC}/** r,
|
||||
/bin/** Pixmr,
|
||||
/usr/bin/** Pixmr,
|
||||
owner @{HOMEDIRS}/ w,
|
||||
owner @{HOMEDIRS}/** w,
|
||||
}
|
||||
# Allow confined_users to read, write, lock and link to their own files
|
||||
# anywhere, and execute from some places.
|
||||
profile confined_user {
|
||||
#include <abstractions/base>
|
||||
#include <abstractions/bash>
|
||||
#include <abstractions/consoles>
|
||||
#include <abstractions/nameservice>
|
||||
deny capability sys_ptrace,
|
||||
owner /** rwkl,
|
||||
@{PROC}/** r,
|
||||
/bin/** Pixmr,
|
||||
/usr/bin/** Pixmr,
|
||||
owner @{HOMEDIRS}/bin/** ixmr,
|
||||
}
|
||||
```
|
||||
|
||||
### /etc/apparmor.d/pam/mappings
|
||||
|
||||
Now create /etc/apparmor.d/pam/mappings to map the usernames/groups to roles:
|
||||
|
||||
```
|
||||
#
|
||||
# This file contains the mappings from users to roles for the binaries
|
||||
# confined with AppArmor and configured for use with libpam-apparmor. Users
|
||||
# without a mapping will not be able to login.
|
||||
#
|
||||
# The default hat is a confined user. The hat contains only the permissions
|
||||
# necessary to transition to the user's login shell. All other permissions have
|
||||
# been moved into the default_user profile.
|
||||
^DEFAULT {
|
||||
#include <abstractions/authentication>
|
||||
#include <abstractions/nameservice>
|
||||
capability dac_override,
|
||||
capability setgid,
|
||||
capability setuid,
|
||||
/etc/default/su r,
|
||||
/etc/environment r,
|
||||
@{HOMEDIRS}/.xauth* w,
|
||||
/bin/{,b,d,rb}ash Px -> default_user,
|
||||
/bin/{c,k,tc}sh Px -> default_user,
|
||||
}
|
||||
# gray is a confined user. The hat contains only the permissions necessary
|
||||
# to transition to gray's login shell. All other permissions have been
|
||||
# moved into the confined_user profile.
|
||||
^gray {
|
||||
#include <abstractions/authentication>
|
||||
#include <abstractions/nameservice>
|
||||
capability dac_override,
|
||||
capability setgid,
|
||||
capability setuid,
|
||||
/etc/default/su r,
|
||||
/etc/environment r,
|
||||
@{HOMEDIRS}/.xauth* w,
|
||||
/bin/{,b,d,rb}ash Px -> confined_user,
|
||||
/bin/{c,k,tc}sh Px -> confined_user,
|
||||
}
|
||||
# Don't confine members whose primary group is 'admin' who are not specifically
|
||||
# confined. Systems without this special primary group may want to define an
|
||||
# unconfined 'root' hat in this manner (depending on site policy).
|
||||
^admin {
|
||||
#include <abstractions/authentication>
|
||||
#include <abstractions/nameservice>
|
||||
capability dac_override,
|
||||
capability setgid,
|
||||
capability setuid,
|
||||
/etc/default/su r,
|
||||
/etc/environment r,
|
||||
@{HOMEDIRS}/.xauth* w,
|
||||
/bin/{,b,d,rb}ash Ux,
|
||||
/bin/{c,k,tc}sh Ux,
|
||||
}
|
||||
```
|
||||
|
||||
### Applying the policy
|
||||
|
||||
After adjusting policy, you must reload the profiles and roles (the
|
||||
mappings are pulled in automatically):
|
||||
|
||||
```
|
||||
$ sudo apparmor_parser -r -T -W /etc/apparmor.d/pam_binaries /etc/apparmor.d/pam_roles
|
||||
```
|
||||
|
||||
See if they were loaded:
|
||||
|
||||
```
|
||||
$ sudo aa-status
|
||||
...
|
||||
17 profiles are in enforce mode.
|
||||
/bin/su
|
||||
/bin/su//admin
|
||||
/bin/su//gray
|
||||
...
|
||||
confined_user
|
||||
...
|
||||
```
|
||||
|
||||
You may of course update /etc/apparmor.d/pam\_binaries
|
||||
and /etc/apparmor.d/pam\_roles individually. Changes
|
||||
to /etc/apparmor.d/pam/mappings require you to reload
|
||||
/etc/apparmor.d/pam\_binaries (because it has the mappings file as
|
||||
an \#include).
|
||||
|
||||
Extending
|
||||
---------
|
||||
|
||||
Once you are comfortable with your 'su' configuration, you can extend
|
||||
this to other binaries like sshd and login by:
|
||||
|
||||
- adding a 'session optional pam\_apparmor.so ...' entry to the corresponding pam configuration
|
||||
- adding policy for the binary to /etc/apparmor.d/pam\_binaries
|
||||
|
||||
To add a new user or role:
|
||||
|
||||
- adjust /etc/apparmor.d/pam\_roles for the new role
|
||||
- adjust /etc/apparmor.d/pam/mappings to map the login name to the AppArmor role
|
||||
|
||||
Caveats
|
||||
-------
|
||||
|
||||
pam\_apparmor does not consult secondary groups, so using role groups
|
||||
is currently limited to primary groups only.
|
||||
|
||||
Final thoughts
|
||||
--------------
|
||||
|
||||
Much of /etc/apparmor.d/pam/mappings is boiler plate and can be
|
||||
abstracted out and then added via an \#include. Also remember that
|
||||
there is nothing special about the pam\_binaries, pam\_roles and
|
||||
pam/mappings files. You can use other names or include all of the
|
||||
policy in one file. For ease of understanding and maintenance on
|
||||
larger sites, breaking the policy up into smaller chunks in this way
|
||||
can help a lot.
|
||||
Loading…
Add table
Reference in a new issue