[Apparmor-dev] AppArmor 2.3 tentative features and schedule.

[John Johansen]

AppArmor 2.3 tentative release and features.

This is the tentative feature list for AppArmor 2.3 which is scheduled for
a mid February release.  This release is more about getting these features
out and letting people play with and using them, the interactions and or
integration may not be as refined as we would like, but we feel the features
are significant enough that it warrants the release.

Of course any and all feedback is welcome and Appreciated.

1. Tentative Fully supported features, and changes.

  1.1 Append is sufficient permission to create a file
    Currently you need to have full write permissions to create a file,
    which greatly limits the use of the append permission.

    With this release append will be enough permission to create a file
    or append to existing file.  It will not be sufficient permission
    to truncate or remove a file.

  1.2 pix execute mode
    The generalized transition model is not ready for AppArmor 2.3 but
    it does picks up a new "pix" execute mode.  The pix execute mode
    provides a hybrid of the px and ix modes that allows for an
    incremental deployment of profiles.  A pix rule will first
    try to do a px and if that fails, instead of failing the execute
    it falls back to allowing the execute inheriting the current
    profile.

    Both the safe and unsafe (scrubbed environment variables) execute modes
    are support

    /foo pix,  #unsafe px or inherit
    /foo Pix,  #safe px or inherit

  1.3 link pair rules
    Currently AppArmor's link rules are very broad in the form of

    /linkname/path {other perms}l,

    which means allow /linkname/path to be a link to anything /** as long
    as the profile permission set for /linkname/path is a subset of
    the target path.

    This link permission subset test is required to keep creations of
    links from elevating permissions, but it can also be confusing
    and limiting when a specific link should be allowed with an
    elevated permission.  The current form of the link rule can also
    be more obtuse than it should be.

    To address these deficiencies 2.3 includes a new form of link
    rule allowing the specification of link pairs.

    link /linkname -> /targetname,

    the link keyword can be abreviated as a just the l permission
    but no other permissions can be specified with it.

    l /linkname -> /targetname,   # valid
    lr /linkname -> /targetname,  # invalid

    with this form of link rule the permission subset test is not
    performed unless the <= symbol is used.

    l <= /linkname -> /targetname,  # do the link subset test

    old style link rules are still allowed and internally map to
    a link pair rule.

      /linkname l,

    maps to

      link <= /linkname -> /**,

    If you are using globbing within the /linkname or /targetname portion
    of the rule it is recommended you use the link permission subset test,
    to ensure that the link can not be used to increase permissions.

  1.4 File rules that are conditional on file ownership.
    AppArmor 2.3 extends the ability of file rules by allowing them to
    be conditional on file ownership.  This is useful for separating
    user tasks that are writing to shared temp locations, or for
    writing generic rules that apply to home directories.

    The conditionality is specified by a prefix flag to a file rule,
    or by using the flag to open a block of file rules*.  There
    are two flags that can be used: "owner" makes the rule conditional
    upon the file being accessed by its owner (file's uid = process fuid),
    while "other" make the rule conditional on the file NOT being accessed
    by its owner (file's uid != process fuid).

    So to make a generic rule covering access to files the user owns in
    their home directory one would do.

      owner /home/*/**  rwl,

    or even better

      owner @{HOME}/** rwl,

    to specify the file must not be owned by the user

      other /lib/** rm,

    It is important to understand how "owner" and "other" permissions
    interact with permission accumulation and standard AppArmor rules.

    Standard AppArmor rules literally map to providing their permissions
    to both the owner and other permission sets so that.

      /path rw,

    is equivalent to a profile containing

      owner /path rw,
      other /path rw,

    Permission accumulation is done across all file rules so that when
    rules over lap the sum of the union of the specified permissions
    is granted.

    "owner" and "other" prefixes can be used in combination with link
    pair rules allowing link creation to limited to only files owned
    by the user.

      owner /** l,

    maps to

      owner link <= /** -> /**,

    which means allow a link to any file owned by the user as long as
    the profile permissions for the link are a subset of the profile
    permissions for the target.

    For the permission subset test both the owner and the other permission
    sets are considered so that the owner set of /linkname must be a subset
    of the owner set of /targetname and the similarly for the other set.   

    * The use of "owner" and "other" prefix to specify a block of rules
      is only partially supported see section 2.2

  1.5 Deny rules
    AppArmor 2.3 introduces deny rules for 2 limited but important purposes.
    1.  deny rules allow the profile tools (genprof/logprof) to remember
        accesses that were explicitly denied so that they are not
        prompted for in new profiling runs.
    2.  Quiet the logging of known rejects so that known rejects don't
        flood the audit log, and also so that they don't overwhelm or hide
        rejects that are unknown making tools that warn of new rejects
        far more useful.
        
    deny rules start with a the keyword "deny" that is prepended to the
    given rule.

    eg.

      deny /foo px,
      deny other @{HOME}/** w,

    Deny rules can be used to carve out permissions from allow rules as
    the deny rule list takes precedence over the allow list and is
    subtracted from the allow permissions before the policy is loaded,
    but that use is not recommend at this time as it may change.

  1.6 Rule auditing enhancements
    AppArmor 2.3 gains the ability to control auditing on a per rule
    basis in enforce and complain modes.  To force a rule to leave
    an audit message the keyword "audit" is prepended to the rule.
    For file rules using the "owner" and "other" prefixes, the
    "audit" keyword must appear before the "owner", "other" prefix, or
    the "deny" keyword.

    This will result in an audit message going to the log every time
    the rule is matched.  Just exactly what this means is depends on the
    rule type, but generally it results in the same number of messages
    as if the rule was missing and the profile was in complain mode:
      file rules - an audit message is logged every time the file is opened
                   or revalidated.  A message will not be logged for
                   every read/write to the file.
      network rules - currently this means every time a network rule is
                   matched, so it is not recommended for use at this time.
      capability - an audit message is logged for every capable check
                   matching the capability.

    When audit the audit modifier is used with a deny rule it prevents
    the deny rule from quieting the reject thus resulting in reject
    messages for the audited deny rule.  This would be the same as
    not having the deny rule in the profile except that the audited
    deny rule let the profile tools (logprof/genprof) know the reject
    message is expected, so that they don't prompt for them.
    
    eg.
      audit /etc/shadow w,

      audit other /etc/shadow w,

      audit deny /etc/shadow w,

    To have a rule that has some of its permissions audited split the
    rule into a regular rule and an audit rule.

      /foo rw,

    to audit the write permission and not the read, do

      /foo r,
      audit /foo w,

  1.7 Improved Gui Applet and dbus audit dispatcher
    The Gui applet and dbus audit dispatcher have under gone numerous
    minor improvements.   The dbus audit dispatcher will work with
    the audit subsystem, syslogng or syslog.  And can broadcast a wider
    variety of events.

    The gnome applet has been improved, slightly.

    *There may be a non-gnome gtk based application that can provide the
     same information as the gnome applet.

  1.8 Command line tools for the profile repository
    AppArmor 2.3 should see the release of some command line tools to better
    control and interact with the profile repository, independent of
    genprof/logprof.


2. Partially Supported Features
  With the AppArmor 2.3 release there are some features, or changes
  that are only partially supported.  Generally this is because
  support has not been added to the tools, and more general support
  is waiting for a generic parsing library and the moving of the
  tools over to use that library.

  2.1 file rules with leading permissions (permissions first)
    The AppArmor 2.3 parser supports specifying file rules with the file
    permission leading, which makes aligning rules easier.

    rw /foo,

    this style can be used with link as well as long as the link pair is
    not specified.

    rwl /foo,  # valid

    rwl /foo -> /bar,  #BAD

    for link pairs the l permission must not be specified with other perms.

    l /foo -> /bar,  #valid

  2.2 blocks (audit, owner, other)
    With AppArmor 2.3 the parser supports grouping rules together in blocks
    instead of having to specify a prefix for every rule.  The only prefix
    that must be specified on every rule is the deny prefix.

    eg.
    audit {
       /etc/shadow w,
       @{HOME}/.ssh/* w,
    }

    owner {
      @{HOME}/** rwl,
      @{TMP}/** rwl,
    }

  2.3 Profile Namespaces
    The AppArmor 2.3 kernel and parser supports the concept of profile
    namespaces.  Where there their can be multiple profile sets and
    a give set (namespace) can be attached to a process and its children.

    This can be used for example to give each vserver a seperate
    policy, or to confine a group a users with a different policy
    than the rest of the system.

    Profile Namespaces are still limited in several ways in that unconfined
    processes always revert to the default namespace.  And the tools
    don't support them and layout (storage) of the namespace hasn't been
    finialized.

 2.4 x rule overlap
    Currently x rules are not allowed to overlap except in the case of an
    exact match.  A more generic overlap rule is coming but full support
    will mostly likely not be ready.


3. What won't be in AppArmor 2.3
  There are a lot of things that have been discussed or prototyped that won't
  go into AppArmor 2.3.  I am working on writing these up so that they can
  be discussed and prioritized and the next release schedule can be put
  together.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20080125/c66e698d/attachment.pgp