[Apparmor-dev] AppArmor 2.3 beta 1
John Johansen
jjohansen at suse.de
Fri May 30 02:50:35 MDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This list has been quiet for all too long. After many delays I would
like to finally announce that AppArmor 2.3 is in beta. The road to 2.3
has been a long and bumpy one, hopefully 2.4/3.0? will go smoother.
In addition to the AppArmor 2.3 beta, the roadmap is going to finally
get updated in the coming weeks. Now on to the beta
the tarballs can be grabbed from
http://forge.novell.com/modules/xfcontent/downloads.php/apparmor/AppArmor%202.3-Beta1
or you can just grab from the trunk of svn
https://forgesvn1.novell.com/svn/apparmor/trunk/
known issues
- - many of the features are only partial accessible or not accessable
at all from the tools. This isn't planned to be fixed for 2.3,
as much of the limitations are waiting on more extensive under the
hood improvements.
- - cx named transitions are not handled correctly by the parser,
causing them to fail.
The work around at the moment is to just use a px named transition
and prepend the parent profile name.
- - there is a bug in setting the apparmor.enabled boot parameter
- - still some of the outstanding bugs from 2.1 that are waiting on
other cleanups
- - the suse rpm spec files aren't included yet
Packages are not available through the build service yet, hopefully in a
couple days I will get suse specific packages up, and then after that
packages for other distributions. If anyone is so inclined to help out
on getting packages together for Debian, Ubuntu or any other distros, I
wouldn't complain a bit.
The following documentation can also be found at
http://en.opensuse.org/AppArmor/Changes_AppArmor_2_3
and will hopefully added to the Novell forge wiki for AppArmor soon.
Comments, questions, and corrections are as always welcomed.
- ------------------------------------------------------------------
AppArmor 2.3
1. Minor Semantic Change
1.1 Append
1.2 change_profile
2. New tool - aa-repo.pl
3. Profile Changes
3.1 Profiles without attachment specification
3.1.1 Uses for profiles that don't attach
3.2 Local or Children Profiles
3.3 Hat and Local profile names
3.4 External Local Profiles and Hats
3.5 Change_hat and Change_profile rules
3.6 Differences between change_hat and change_profile
3.7 Safety of Domain transitions and when to use them
3.8 Profile Namespaces
4. New execute permissions
4.1 New transition mode cx
4.2 Named (specified) profile transitions
4.3 Difference between px/cx and named profile transitions
4.4 Profile transitions and inheritance fall back
4.5 Named Profile Transitions and Log Messages
5. Link Pair rules
6. File Rules conditional on file ownership
7. Per rule audit control
8. Deny rules
9. Alias rules
10. Rlimit rules
11. Set capability per profile
12. Variable Improvements
13. Updated Log Entries
14. Determining which features the AppArmor kernel module supports
1. Minor Semantic Change
1.1 Append
File creation semantics have been changed slightly so that the
append permission provides sufficient privilege to create a new file.
1.2 change_profile
The change_profile interface has been extended so that it can be used
by an unconfined process to enter confinement. An unconfined
process using change_profile can enter any loaded profile. For
unconfined processes the change_profile interface differs from the
set_profile interface in that it only applies to the current task
while the set_profile interface can be used to change confinement on
any task.
2. New tool
aa-repo.pl - allows direct access to the profile repository and the
configuration used by logprof/genprof.
3. Extensions to Profile Specification
3.1 Profiles without attachment specification
AppArmor 2.3 allows for profiles that names do not reside in the
filesystem namespace and thus can not be automatically attached to,
ie. they will never match a program name.
Creating profiles without attachment is much the same as creating
standard profiles except that the "profile" key word appears before
the name of the profile.
eg.
profile An.unattached.profile {
/foo/bar rw,
}
The profile names have a few limitations, they can not begin with
the ':' or '.' characters (though they may be used internally) and
they can only contain whitespace characters if the name is quoted.
Starting the profile name with '/' is the same as specifying a
standard profile that will attach to a program of the same name.
eg.
profile /bin/ping { ... }
is the same as just doing
/bin/ping { ... }
3.1.1 Uses for profiles that don't attach
Profiles don't provide confinement unless they are attached to a
running program. Profiles without attachment specification will
not attach to a program when it is invoked (the executable name
will never match the profile name), nor can they be transitioned
to through a standard px transition rule. For one of these
profiles to be attached so it provides confinement either
change_profile profile or the new named (specified) profile
transition is used.
This type of profile provides for more flexibility and advanced
uses such as providing roles, or specialized profiles for system
utilities that generally should not be confined by a system wide
profile. For example, grep generally should not have its own
profile but, it can be useful to have a specialized profile for
an invocation of grep from within a confined shell script.
3.2 Children (local) Profiles
Local profiles are an extension of AppArmor "hats". They are a
profile that is embedded inside of a parent profile, that is used to
provide tighter or alternate confinement for a subtask of an
application.
A good use for local profiles is providing specialized confinement
for utility programs launched by a confined application. In
previous versions of AppArmor, if a global profile for the utility
didn't exist or wasn't appropriate then the ix execute mode was the
only choice for providing confinement to the utility application.
This means that utility application has the full privileges of the
parent task which is not always desirable. Local profiles provide
an alternative where the utility applications profile can be
customized for the application that launches it.
Local profiles are specified just like standard profiles except they
are embedded in a profile and the begin with the "profile" keyword.
eg.
/parent/profile {
profile local/profile {
}
}
Local profiles can specify an attachment, but it will only ever
get used with the new cx, or named profile transition rules.
eg.
/parent/profile {
profile /bin/grep {
}
}
3.3 Hat and Local profile names
AppArmor "hats" are a local profile with some additional
restrictions and an implicit rule allowing for change_hat to be used
to transition to them. AppArmor "hats" may not contain their own
"hats" but local profiles can contain their own local profiles and
"hats". Local profiles that are not "hats" and can not be used with
change_hat without an explicit hat rule.
"Hats" and local profiles are actually just standard profiles with
special names. When a hat or Local profile is loaded, its name in
the logs and as reported by ps -Z is the name of the parent profile
and the name of the local profile seperated by '//'.
eg.
/parent/profile {
^foo {
}
profile local.profile {
}
profile /bin/grep {
}
}
Will show up as 4 profiles in the loaded profile listing.
/parent/profile
/parent/profile//foo
/parent/profile//local.profile
/parent/profile///bin/grep
3.4 External Local Profiles and Hats
With knowledge that "hats" and local profiles are just standard
profiles with using a standard naming convention it is possible to
specify local profiles and "hats" external to a profile.
eg.
/parent/profile {
^foo, # rule allowing change_hat
}
/parent/profile//foo {
}
/parent/profile//local.profile {
}
/parent/profile///bin/grep {
}
Notice that for the external profile to function, as a "hat", a hat
rule must be specified in the profile.
3.5 Change_hat and Change_profile rules
AppArmor 2.3 provides change_hat and change_profile rules that
control domain transitioning via the change_hat and
change_profile api.
Change_hat rules have the same basic syntax as an embedded hat
except that, instead of being followed by a block of rules they end
with a comma.
eg.
^a_hat, #permission to transition to a_hat,
An embedded hat, implicitly adds the change_hat rule to the profile
as well as all the sibling hats.
Change_profile rules are similar except that they start with the
keyword change_profile.
eg.
change_profile a_profile,
3.6 Differences between change_hat and change_profile
Both change_hat and change_profile provide for an application
directed profile transition, without having to launch a separate
application.
Change_profile provides a generic one way transition between any of
the loaded profiles. Change_hat provides for a returnable parent
child transition where an application can switch from the parent
profile to the hat profile and if it provides the correct secret key
return to the parent profile at a later time.
3.7 Safety of Domain transitions and when to use them
The change_hat and change_profile domain transitions are less secure
than a domain transition done through an exec. This is because they
do not affect a processes memory mappings, nor do they close
resources that have already been opened.
Change_hat is a specialized version of change_profile that has
additional security implications, so we will look at
change_profile first.
Change_profile provides a one way transition, that allows an
application to go through a setup phase and then when setup is done,
transition to a profile with less privledge. Any resources mapped
or opened during the startup phase may still be accessible after the
profile change but the new profile will restrict the opening of new
resources, and will even limit some of the resources opened before
the switch.
Specifically memory resources will still be available while
capability and file resources (as long as they are not memory
mapped) can be limited.
Change_profile is best used in situations where an application goes
through a trusted setup phase and then can lower its privlege level.
Change_hat is designed to be used in situations where privlege is
temporarily dropped and then reaquired after a time. As such
change_hat is restricted to where it can be safely used. Since
change_hat stores the return secret key in the applications memory
the phase of reduced privilege should not have direct access to
memory. Also it is important that file access is properly separated,
the hat can restrict accesses to a file handle but it does not close
it. If an application does buffering and provides access to the open
files with buffering, the accesses to these files may not be seen by
the kernel and hence not restricted by the new profile.
Change_hat is best used in situations where an applications runs a
VM or interpreter that does not provide direct access to the
applications resources. An example of where it could add security
value is apache's mod_perl and mod_php.
3.8 Profile namespaces
AppArmor 2.3 has the beginnings of support for the concept of
profile namespaces. Profile namespaces provide a means for several
sets of profiles to be loaded at the same time, with one set of
tasks using the profiles in one set, while other tasks are using the
profiles in a different set.
Profile namespaces will be useful for allowing different policy sets
for different filesystem namespaces or vservers. However at this
time only the most basic support of them is included, and the tools
cannot handle them at all.
All profiles as currently specified belong to the default profile
namespace, whose name is not displayed in log messages or when
introspecting loaded profiles or confinement. So for all intents
and purposes profile namespaces are hidden in the current release
except when examining the source code.
4. New execute permissions
AppArmor 2.3 has some new options for execute permissions. In
addition to the ix, ux, and px permissions present in AppArmor 2.1,
there is a new cx permission, as well as the ability to specify a
profile to transition to. Additionally each of these can be offered
in an inherit fall back mode.
4.1 New transition mode cx
The new cx permision is like px except it specifies a transition to
a child (also known as local) profile (see ??local profiles). Just
as with px, cx specifies transitioning to a profile who's name
matches the executable, except instead of searching the global
profile set, only the local profiles of the current profile are
search.
The cx profile transition combines with local profiles providing
a way for an application to have alternate profiles for helper
applications. For example a text based mail viewer could have a
profile for /bin/grep, which the system doesn't confine by default.
The cx transition provides an alternative to using ix for utilities,
providing the possiblity of achieving tighter confinement.
eg.
/usr/bin/mutt {
....
/bin/grep cx,
profile /bin/grep {
}
}
As with the ux and px profile transition modes, cx comes in both
safe and unsafe variants. Cx is "safe" and has glibc sanitize the
environment variables, while cx does not sanitize the environment
variables.
NOTE: currently cx transitions are limited to top level profiles
and can not be used in hats and children profiles. This
restriction will be removed in the future.
4.2 Named (specified) profile transitions
In addition to the cx transition mode AppArmor 2.3 adds the ability
to specify exactly which profile will be transitioned to.
This can be useful if multiple binaries should share a single
profile, or if they should use a different profile than there name
would specify.
Named profile transitions use -> to indicate the name of the profile
that should be transitioned to.
eg.
/usr/bin/mutt {
/bin/** px -> shared_profile,
}
The px in the rule indicates the transition will look for the
profile in the global scope. If a cx is used the transition
searches for a local profile.
eg.
/usr/bin/mutt {
/bin/** px -> shared_profile,
/usr/*bash cx -> /bin/bash,
profile /bin/bash {
}
}
Using cx in a named profile transition is a convience and is
equivalent to specifying px with the parent profile name properly
prepended. ie. the cx line from the above example is equivalent to
/usr/*bash px -> /usr/bin/mutt///bin/bash,
There is an implementation specific limit on how many named profile
transitions can be specified in a profile. The limit in AppArmor
2.3 is 12.
4.3 Globbing with px/cx and named profile transitions
The px/cx execute permissions use the executable name to specify
which profile to transition to, so when they are used with globbing
they can specify many different profile transitions.
ie. /bin/** px, Will transition to /bin/ping, /bin/cat, ...
depending on the program being run.
Named profile transitions when combined with globbing provide a many
to one transition. ie. All programs that match the rule regardless
of their name will transition to the specified profile.
When globbing is not used, a px transition is equivalent to a named
profile transition to the file rule pathname.
ie.
/bin/ping px,
is equivalent to
/bin/ping px -> /bin/ping,
4.4 Profile transitions and inheritance fall back
The px, cx, and named profile transitions specify a hard dependency,
in that if the specified profile does not exist, the exec will be
failed.
AppArmor 2.3 introduces the ability to have an inheritance fall back
so that instead of the program execution failing, it will succeed
but inherit the current profile. This allows for a soft profile
dependency, which allows for gradual or partial profile deployment.
To specify inheritance fall back ix is combined with px, cx into the
pix and cix modes. The pix and cix modes can be used with named
profile transition to provide inheritance fallback as well. The pix
and cix modes like px, and cx have safe and unsafe versions.
4.5 Named Profile Transitions and Log Messages
Named profile transitions show up in the log as having the mode Nx
and the name of the profile to be changed to is in the name2 field.
5. Link Pair rules
AppArmor 2.3 introduces the ability to specify links as a source
and destination pair providing even greater control over how
hard links are created.
link /link/file -> /target/file,
Link pair rules by default do not enforce the link subset permission
test that the standard rules link permission requires. To force the
rule to require the permission subset test the "subset" keyword is
used.
link subset /link/file -> /target/file,
The link permission expressed in the standard rule is equivalent to
the following link pair rule
link subset /link/file -> /**,
So the rule
/link/file rwl,
is equivalent to
link subset /link/file -> /**,
/path/name rw,
NOTE: currently link pair rules are not supported by the tools
but they will not be stripped so it is safe to update profiles
containing them.
6. File Rules conditional on file ownership
AppArmor 2.3 extends file rules so that they can be conditional upon
the the user being the owner of the file.
To make a file rule conditional on the file being owned by the
user the owner keyword is prepend to the rule.
eg.
owner /home/*/** rw,
Owner conditional rules accumulate just as regular file rules and
are considered a subset of regular file rules so that if a regular
file rule overlaps with an owner conditional file rule, the resultant
permissions will be that of the regular file rule, since it specifies
permissions regardless of ownership.
eg. given the following rules
owner /home/*/** rw,
/home/*/foo rw,
/home/*/foo does not have be owned by the user.
It is important to remember with owner rules that like standard rules
they are just a further restriction of dac permissions, they do not
grant additional permissions and the file must be accessible via the
dac permission test before it will be checked against the profiles
permissions.
When using file ownership conditions with link rules the ownership
test is against the target file. This enables forcing open wall style
link restrictions where to link to a file the user must own the file.
eg.
owner /** l, # restrict hardlinks to user owned files
Note: The ownership test of a file is done by testing the user of the
confined process matches the owner of the file, specifically the
processes fsuid (see man 2 setuid) is compared to the files uid.
7. Per rule audit control
AppArmor 2.3 provides the ability to audit given rules so that when
they are matched an audit message will appear in the audit log.
To enable audit messages for a given rule the audit keyword is
prepended to the rule.
eg.
audit /etc/shadow w,
If it is desirable to audit only a given permission on a rule then
the rule can be split into two rules.
eg.
If audit messages are only desired for write accesses to /etc/shadow
then the rule.
/etc/shadow rw,
can be split into
audit /etc/shadow w,
/etc/shadow r,
this will result in audit messages when /etc/shadow is opened for
writing, but not when it is opened for just reading.
It is important to note with audit messages that they are not
generated for every read or write of a file but only when a file is
opened for read or write.
Audit control can be combined with owner conditional file rules to
provide auditing when a user access files they own, but at this time
it can not be used to audit only files they don't own.
eg.
audit owner /home/*/.ssh/** rw,
8. Deny rules
AppArmor 2.3 now allows for deny rules. Deny rules are used to:
1. Annotate known rejects, so the tools don't ask about them on
subsequent runs.
2. Quiet known rejects, so that when a profile is loaded a known
reject will not result in audit messages filling up the logs. If
it is desirable for auditing purposes to have audit messages for
a known reject then the audit keyword can be prepended to the
deny rule. Alternatively the deny rule can be removed from the
profile, the difference being that the tools will no longer have
a way to know that a given reject is known and will prompt for it
during subsequent profiling.
eg.
audit deny /foo/bar w,
3. Carve out permissions from allow rules. Deny rules have their
permissions accumulated just as allow rules do except that any
the permissions in the deny set of rules are subtracted from the
allow set of rules. This allows the writing of broader allow
rules, and then subtracting a few known files that should not be
allowed.
eg. Allow access to everything in a users directory except
write access to the .ssh/ files.
deny /home/*/.ssh/** w,
/home/*/** rw,
This use of deny rules should be used sparingly, as excessive use
can make profiles harder to read, however judicious use of it can
simplify profiles.
Deny rules can be combined with owner rules, to deny files owned by
the user. It is not currently possible to write deny rules to deny
access to files not owned by the user.
eg.
deny owner /home/*/foo w,
audit deny owner /home/*/.ssh** w,
9. Alias rules
Alias rules provide an admin a way to manipulate profile path
mappings to site specific layouts. They are an alternative form of
path rewriting to using variables, and are done post variable
resolution.
eg.
alias /home/ -> /mnt/users/
NOTE: Currently no tool support, but they will not be stripped.
they are not available in the tools and are hidden in tunables/alias
so an admin who want to use them needs to edit tunables/alias file.
10. Rlimit rules
AppArmor 2.3 provides the ability for a profile to set and control an
applications rlimits (man 2 setrlimit) also known as ulimits
(man 3 ulimit, man 1 ulimit). By default AppArmor does not control
applications rlimits, and it will only control those limits that there
is a specific rule for in the confining profile.
AppArmor leverages linux's rlimits and as such does not provide an
additional auditing than the would normally occur. Also AppArmor's
rlmits only every reduce an applications current rlimits, they can not
be used to raise any limit that has been set.
The set limits will be inherited by a processes children and will
remain even if a new profile is transitioned to or the application
becomes unconfined.
If an application transitions to a new profile that profile has the
ability to further reduce the applications rlimits.
AppArmor's rlimit rules will also provide mediation of an setting an
applications hard limits, should it try to raise them. The
application will not be able to raise its hard limits any farther than
specified in the profile.
The mediation of raising hard limits is not inherited as the set limit
is, so that once the application transitions to a new profile it is
free to raise its limits as specified in the profile.
AppArmor's rlimit control does not affect an applications soft limits
beyound ensuring that they are less than or equal to the applications
hard limits.
AppArmor's hard limit rules have the general form of
set rlimit <rlimit> <= <value>,
where <rlimit> and <value> are as described below.
<rlimit>
* cpu - currently unsupported.
* fsize, data, stack, core, rss, as, memlock, msgqueue:
These rlimits take either a number in bytes, or a number with
a suffix where the suffix can be (K - kilobytes, M - megabytes,
G - gigabytes).
eg.
rlimit data <= 100M,
* nofile, locks, sigpending, nproc, rtprio
These rlimits take a number greater or equal to 0 indicating
their limit.
* nice
The nice rlimit takes a value between -20 and 19.
Special nproc rlimit
The nproc rlimit is special in that it is handled different than all
the other rlimits. Instead of indicating the standard process
rlimit it controls the maximum number of processes that can be
running under the profile at any given time. Once the limit is
exceeded the creation of new processes under the profile will fail
until the number of currently running processes is reduced.
Note: currently the tools can not be used to add rlimit rules to
profiles. The only way to add rlimit controls to a profile is
manually edit the profile with a text editor. The tools will still
work with profiles containing rlimit rules and will not remove them,
so it is safe to use the tools to update profiles containing them.
11. Set capability per profile
AppArmor 2.3 provides the ability to set an applications capabilities.
This provides the ability to give non-root users administrative
privileges, and as such it must be used with extreme caution.
This is the only rule that AppArmor has that can be used to raise
privilege. Using it is akin to setting a program to setuid or, using
fscaps.
The difference is that (like fscaps) it can control capabilities
granted better than setuid, and it does not change the processes uid.
Unlike fscaps and setuid instead of applying to a single program file
it applies to all programs run under the profile. This allows the
creation of admin style profiles, that use ix transitions for all
applications that should run with the elevated privilege.
It is important to note, that AppArmor's set capabilities are not
inheritable, and that as soon as an application transitions to
another profile, or becomes unconfined it looses the elevated
privilege granted by the profile. Once a process leaves the profile
it will return to its regular capability set. Another profile may
have the same or other set capabilities, which will be used.
AppArmor set capabilities cannot be learned. They can only ever be
added to a profile through manual editing. The tools will work with
profiles containing these rules and not strip them, so it is safe to
update profiles using these rules.
To set a capability in a profile the keyword 'set' is prepended to a
capability rule.
eg.
set capability dac_override,
Setting a capability also implicitly adds a capability rule allowing
that capability.
To repeat the warning, these rules should not be used with out good
cause as they allow giving a process some of traditional unix root
privileges.
Note: currently the tools can not be used to add rules that allow
setting capabilities. To add set capabilities the profile must be
manually edited with a text editor. The tools will still work with
profiles containing rules setting capabilities and will not remove the
rules from the profile when saving so it is safe to use the tools to
update profiles containing these rules.
12. Variable Improvements
AppArmor 2.3 now allows for variables to be declared at the head of
the file. This allows declaring of profile specific variables within
the profile itself. This is useful for example to provide the base
of for a chrooted path.
eg.
@{CHROOT_BASE}=/tmp/foo
/sbin/syslog-ng {
...
# chrooted applications
@{CHROOT_BASE}/var/lib/*/dev/log w,
@{CHROOT_BASE}/var/log/** w,
...
}
AppArmor 2.3 tools support for variables is still limited to not
removing rules containing them, and rules that do contain them will
not be matched by the tools to eliminate log entry questions.
13. Updated Log Entries
AppArmor 2.3 uses the same basic log entry format as that of
AppArmor 2.1, ie. name value pair (eg. name="/foo"), however it has
been extended to support the new features in 2.3.
eg.
type=APPARMOR_DENIED msg=audit(1211946303.024:499): type=1503
operation="inode_permission" requested_mask="::r" denied_mask="::r"
fsuid=1000 name="/proc/net/unix" pid=4280
profile="/usr/lib/firefox/firefox-bin///bin/netstat"
13.1 denied_mask and requested_mask
The requested_mask and denied_mask have been extended to report
permissions tests based on the owner. The ownership of the
permissions tested can be determined by the position of the
character in the value string.
The value string is a colon ':' separated tuple with the following
ordering: owner:extended owner:other. A permission will be reported
in the ownership field if the file passed the ownership test. The
middle position or extended owner test is unused at this time. The
final position is for files that do not match the first two tests.
eg. requested_mask="r::" means the file was read by its owner.
requested_mask="::r" means the file is owned by a user other
than the processes fsuid, or the extended ownership tests.
The denied and requested masks have also been extended to report the
new transition types. Cx or cx is reported for child (local)
transitions, while Nx, or nx is reported for named profile
transitions. When Nx is reported the name2 field contains the name
of the profile that is being transitioned to.
13.2 fsuid
The fsuid field reports the fsuid of the process accessing the file.
The entry format is fsuid=##.
eg. fsuid=1000
13.3 namespace
The namespace field reports the name of the confining profiles
namespace. It is only reported if profile is not from the default
namespace. Since namespaces are not fully supported in AppArmor 2.3
this field should not be seen.
14. Determining which features the AppArmor kernel module supports
AppArmor supports an interface for determining which features are
supported by the AppArmor module in the kernel.
The interface file can be found in the apparmor/matching file under
securityfs. The standard mount point is at
/sys/kernel/security/apparmor/matching
AppArmor 2.3 has the following value for the matching file
pattern=aadfa audit perms=rwxamlk/ user::other
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIP7/bi/GH5xuqKCcRAhzFAJ4isBuPJ9TrY36IwAz5ZlB1U02uXwCeNbYn
PakGvWtuE4wRvmUHGcV7l6U=
=BpbD
-----END PGP SIGNATURE-----
More information about the Apparmor-dev
mailing list