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



-- 
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to