[apparmor] apparmor 2.3 -> 2.8 change summary
John Johansen
john.johansen at canonical.com
Fri Nov 8 04:50:56 UTC 2013
So here is a first pass through changes for (2.3 - 2.8+ admittedly not all features are available in all versions of 2.8 it will depend on the extra patches that have been applied). It contains a lot of the same info as the release note set that Christian posted in the IRC channel but its arranged in a different way, and does have some extra info
Removed
-------
utils/severity.pl - due to incorrect license/copyright statement
rc.sd-event-dispatch.suse - replaced by aa-eventd, which is not nearly but almost as obsolete
gnome apparmor applet - replaced by aa-notify
old v2.0 log parsing code from libapparmor
set capabilities
set profile via /proc/<pid>/attr/current
Policy
-------
General Policy
- file chmod, chown mediation reintroduced - write permission on the file is required
- capability MAC_ADMIN is required to modify policy
Alias rule
alias <source> -> <target>,
allows declaring a source and alias of target (think of source like a symlink to target). This results in all rules beginning with source also allowing access to target. The source rule is retained allowing essentially allowing access to source and target.
eg.
alias /home/ -> /data/home/
file - the optional file keyword was added. This allows file rules to resemble other rule types which all start with a keyword (network, mount, ...)
file /example/rule r,
file, # grant access to all files
allow - the optional allow prefix was added. If it is not specified and deny is not used it is implied
allow file /example r,
allow /example r,
allow network,
capability rules can now list multiple capabilities in a single rule, or all caps with a bare keyword
capability dac_override sys_admin,
capability, # Grant all capabilities
Support for several new capabilities have been added
audit_write, audit_control, setfcap, mac_override, mac_admin, syslog, wake_alarm, block_suspend
safe/unsafe keywords added
prefix can be used with exec based file rules instead of using character case to determine whether environment scrubbing is done during an exec transition
File rules can use leading or trailing permissions
File rule permissions do not need to be specified as a trailing permission any more. They can be used at the start of the rule. This is important in that, while not currently used, it makes file rules behave like other rule types.
eg.
/path rw, #old style
rw /path, #leading perm
file rw /path,
allow file rw /path,
New x transition fallbacks Pux, Cux, to allow falling back to "unconfined" when the profile isn't found. (hrmm and maybe Pix, Cix (though I think those were in 2.3)
eg.
/path pux,
/path pux -> <profile>,
pux /path,
pux /path -> <profile>,
Mount rules - also requires out of tree kernel patch, see man apparmor.d
DBus rules (requires dbus patches, and aa3.0 kernel) see man apparmor.d
Profile names can contain pattern matching
eg.
/foo/** { }
profile /foo/** { }
Profiles can provide a logical name separate from the attachment specification. Must use the profile keyword
profile firefox /usr/lib/*/firefox* { }
New profile control flags
chroot_relative, namespace_relative, attach_disconnected, no_attach_disconnected, chroot_attach, chroot_no_attach
Policy Namespaces
-----------------
multiple policy namespaces can be created (this was an experimental feature in 2.3). Unlike the 2.3 version they are hierarchical. A namespace can see its children but a child can not see its parent.
Policy namespace names start with a : followed by an alpha numeric string, a trailing : and an optional //
eg.
:childns://
profiles loaded to a child namespace will be prefixed with their namespace name (if viewed from a parent)
eg.
:childns://apache
Policy namespaces are used to provide different profiles set. Say one for the system, another for a chroot or container
Policy namespaces can be entered via the change_profile API or named profile transitions
eg.
/some/exec px -> :childns://profile,
Policy Development
------------------
apparmor.vim - for syntax highlighting in vim editor
Alternate methods of declaring the complain and disabling a profile. This allows setting these modes without disturbing the profile file which might be owned by package management
The
force_complain
and
disable
directories (and support for) have been added. Placing a symlink in these directories back to the profile will result in the profile mode being set
Logging Message Format
----------------------
Logging was moved to LSM audit. It is largely the same as the format in aa2.3 however the base field type is now 1400 (auditd knows this as AVC) instead of 150X and instead of the log type (DENIED, ALLOWED, STATUS, ...) being encoded in the X value of the type there is an apparmor= field
eg.
[229656.398829] type=1400 audit(1383816826.833:8093): apparmor="DENIED" operation="open" parent=1260 profile="/usr/lib/libvirt/virt-aa-helper" name="/home/jj/.libvirt/images/quantal.img" pid=14948 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
The learning profile has transitioned from being
null-complain-profile
to
null-XXX
where XXX is a unique string to the new profile being learned
Interfaces
----------
- unconfined is a profile mode that can be reported via ps -Z or the profile interface (aa-status). This will show up on profiles that don't that have are not the unconfined profile.
eg.
/foo (unconfined)
- compound label/mode reporting (coming in aa3.0). Tasks can be confined by multiple profiles, each profile on the task is reported separated by //&. The modes will be reported using the first character of the mode name
/foo//&/bar//&:child://unconfined (ECU)
where
/foo is in enforce mode
/bar is in complain mode
and the unconfined profile from the child namespace is in the unconfined mode
this format will only show up if multiple profiles are stacked on the task. Otherwise the old format is used
Kernel Interfaces (new low level interfaces - API provides a front end for some of theses)
-----------------
AppArmor filesystem (still mounted/registered as part of mounting securityfs, this assumes security fs is mounted at /sys/kernel/security)
- profiles file is virtualized and will report policy namespaces, and profiles in subnamespaces.
/sys/kernel/security/apparmor/profiles
- features directory (the features file was converted to a directory that carries a lot more information)
/sys/kernel/security/apparmor/features/
- policy directory (3.12 kernel or out of tree patch). This provides a directory of loaded policy. It contains all the information in the profiles files but includes extra info like attachment, and profile hash
/sys/kernel/security/apparmor/policy
- .access file for policy queries (coming in aa3.0). This is used by the API to provide permission queries to trusted helpers in userspace.
/sys/kernel/security/apparmor/.access
- /proc/<pid>/attr/prev - allows querying what the parent profile is when in a hat profile
- /proc/<pid>/attr/exec - allows setting/querying the change_onexec profile that will be used at the next exec
- apparmor parameters that can be configured on grub kernel command line
apparmor.enabled or read via /sys/module/apparmor/parameters/enabled
Controls whether apparmor is enabled on boot (alternative to apparmor=0), and allows introspecting if apparmor is enabled
values - Y/N
eg.
apparmor.enabled=N
cat /sys/module/apparmor/parameters/enabled
N
apparmor.audit or via /sys/module/apparmor/parameters/audit
Controls apparmors audit behavior
Values - "normal", "quiet_denied" - quiets denied messages, "quiet" - quiet all auditing, "noquiet" - don't use quieting of denials so you can see rejects that are normally hidden by the deny keyword, "all" - audit everything
eg.
apparmor.audit=noquiet
cat /sys/module/apparmor/parameters/audit
noquiet
echo "normal" >/sys/module/apparmor/parameters/audit
apparmor.audit_header or via /sys/module/apparmor/parameters/audit_header
Controls turning on and off the apparmor=type field in the log. This was useful for older kernels that used the type=150X as it is redundant information. Now it is pretty much required
Values - Y/N
apparmor.debug or via /sys/module/apparmor/parameters/debug
Controls whether some extra debug output is on. Only really useful for developers and bug hunting
apparmor.lock_policy use only via /sys/module/apparmor/parameters/lock_policy
One way lock on policy. Once set can not be reversed. Do not use from grub command line or you can not load policy
Values - Y/N
apparmor.logsyscall
Currently unused
apparmor.mode or via /sys/module/apparmor/parameters/mode
apparmor enforement mode
Values - "enforce" - normal mode, "complain" - put profiles in complain mode, "kill" - put profiles in kill on denial mode, "unconfined" - put profile in unconfined mode,
apparmor.paranoid_load or via /sys/module/apparmor/parameters/paranoid_load
Additional check on policy load. This is deprecated and will become a dead toggle with paranoid checks always being applied
apparmor.path_max boot only on newer kernels
Allow setting a different max path_buffer size, or introspective the value at run time. This option if set to low can cause a lot of failures, it should only be used with extreme caution.
Values - valid integer specifying the number of bytes that is the maximum
apparmor= 0/1 - enable/disable apparmor at boot
eg.
apparmor=0 # disable apparmor on boot
apparmor=1 # enable apparmor on boot
security=<LSM> allows setting/overriding what the default/active lsm is.
the security and apparmor parameters can be combined in different ways dependent on whether apparmor is configured (compiled) to be enabled by default
Eg. apparmor disabled by default, but set as default lsm
- No parameters capabilities are used
- apparmor=1 apparmor is used
Eg. apparmor enabled by default set as default lsm
- No parameters apparmor is used
- apparmor=0 capabilities are used
Eg. apparmor enabled by default NOT set as default lsm
- No parameters alt LSM or capabilities used
- security=apparmor apparmor is used
Eg. apparmor disabled by default NOT set ad default lsm
- No parameters alt LSM or capabilities used
- security=apparmor capabilities are used because apparmor is disabled
- security=apparmor apparmor=1 apparmor is used
Generally apparmor is configured enabled, and it is system dependent what the default LSM is
Configuration
-------------
/etc/apparmor/parser.conf - this file allow specifying a default set options that the parser will by default (see man apparmor_parser)
Tools
-----
- moved tools to aa- prefix except apparmor_parser
New Tools
-----
aa-disable
aa-exec
aa-notify
aa-decode
aa-status - rewritten in python, should be largely the same picked up a few changes
aa-easyprof
aa-sandbox
Initscripts/Early bring up
-------
- improved init scripts
- /etc/init.d/apparmor stop #does nothing. AppArmor is not a service that can be stopped. Used to remove profiles
- /etc/init.d/apparmor teardown #removes all profiles
- systemd support
- upstart support and integration (not relevant to suse)
Compiler (apparmor_parser)
--------------------------
- compiled policy caching. This speeds up boots and policy reloads. The cache defaults to /etc/apparmor.d/cache/ but can be configured to other locations via /etc/apparmor/parser.conf (see configuration section). It is time stamp based, and takes into account the compiler, the profile file, and include files, and the cache file time stamps, in addition it uses the kernel features, and a stored feature file in the cache. The take away here is that policy reload, boots are fast as long as the cache is valid but if it isn't policy may have to recompiled on first boot after policy updates or new kernel installation, unless the package system or someone manually regenerated the cache.
- the ability to configuration default parameters/flags used by the parser via /etc/apparmor/parser.conf (see configuration section)
- New control flags (man apparmor_parser)
-p,o,O,D,B,n,Q,k,K,T,W,L
- the parser can accept multiple profile names on one invocation
apparmor_parser -r /etc/apparmor.d/profile1 /etc/apparmor.d/profile2 /etc/apparmor.d/profile3
- state minimization (smaller policy size)
- improved compression (smaller policy size)
- faster policy compilation
- reduced runtime foot print (uses a lot less memory to compile larger policies)
API - libapparmor (Developer features)
---------------------------------------
- change_onexec (man aa_change_profile)
- change_profile - support for policy namespaces
- aa_change_hatv
- aa_change_hat_vargs
- aa_getprocattr_raw (man aa_getcon)
- aa_getprocattr (man aa_getcon)
- aa_gettaskcon (man aa_getcon)
- aa_getcon (man aa_getcon)
- aa_getpeercon (man aa_getcon)
- aa_find_mountpoint
- aa_is_enabled
- there are new aa-genprof/logprof complain/enforce etc coming in aa3.0, done as part of a GSoC rewrite but I don't know that they are worth documenting yet
libvirt support
---------------
support has been added to libvirt to support apparmor as a security model
lxc support
-----------
lxc has support to use apparmor as a security model
Reference Profiles
------------------
- lots of fixes/improvements
- new abstractions
- multi-arch support
- /var/run -> /run
More information about the AppArmor
mailing list