AppArmorEasyprof

Differences between revisions 1 and 2
Revision 1 as of 2012-02-07 19:36:24
Size: 1980
Editor: jdstrand
Comment:
Revision 2 as of 2012-02-07 23:44:50
Size: 5646
Editor: jdstrand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:

== Release note ==

 * N/A
Line 17: Line 12:
 * Dan develops applications for Ubuntu and would like to add !AppArmor protection to his application. He would like to be able to state 'my application uses X but does not use networking' without having to know all the details about !AppArmor profiling.
 * Regina reviews packages for the ARB. Most applications currently require extensive code review, but if she receives an application with an !AppArmor profile, it could reduce some of the code review (eg, reduce it to networking and DBus interactions).
Line 18: Line 15:
== The rest of the specification == == Documentation ==
=== Usage ===
`aa-easyprof` is a standalone CLI application which can also be imported into developer SDKs. `aa-easyprof` supports the use of templates and policy groups to quickly profile an application. In essence, aa-easyprof takes a different view on policy generation and is useful when you already know how the application should behave and want to create an initial policy based on this behavior. As such, one can use a template and any appropriate policy groups (groupings of !AppArmor policy rules) then use aa-easyprof to generate a policy.
Currently the combination of the `user-application` template along with the `opt-application` and `user-application` policygroups should achieve a [[http://developer.ubuntu.com/publish/my-apps-packages/|working policy for Ubuntu's Application Review Board]]. Specify multiple arguments as desired (see `man aa-easyprof`), then the policy is generated, verified and sent to stdout. Eg:
{{{
$ aa-easyprof --template=user-application \
              --policy-groups=opt-application,user-application \
              --abstractions="python,audio" \
              --read-path="@{HOME}/Downloads/" \
              --write-path="/opt/@{APPNAME}/tmp/" \
              --write-path="/opt/@{APPNAME}/log/" \
              --template-var="@{APPNAME}=foo" \
              --author="Dan Doodongle" \
              --copyright="Copyright 2012, Dangling Doodongles Inc" \
              --comment="AppArmor is easy with aa-easyprof" \
              /opt/foo/bin/foo
# vim:syntax=apparmor
# AppArmor policy for foo
# Author: Dan Doodongle
# Copyright: Copyright 2012, Dangling Doodongles Inc
# Comment: AppArmor is easy with aa-easyprof
Line 20: Line 37:
Replace that heading with headings for each thing you’re changing or specifying. #include <tunables/global>
Line 22: Line 39:
Checklist: # Specified profile variables
@{APPNAME}=foo
Line 24: Line 42:
 1. Have you reviewed the bug reports for the relevant package? (Yes, this may take an hour or two. But you might be able to fix multiple bugs with a well-designed change.) /opt/foo/bin/foo {
  #include <abstractions/base>
Line 26: Line 45:
 1. If any user interface is involved, is it fully described? Include any wireframes or mockups.   # Specified abstractions
  #include <abstractions/python>
  #include <abstractions/audio>
Line 28: Line 49:
 1. Have you had any new user interface, or new visible text, reviewed by a designer? (Or if you are a designer, have you had it peer-reviewed?)   # Rules specified via policy groups
  # Policy group for applications installed in /opt
  /opt/@{APPNAME}/ r,
  /opt/@{APPNAME}/** mrk,
Line 30: Line 54:
 1. Is the change accessible? (For example, have you specified accessible labels for any graphic-only elements?)   # Policy group allowing various writes to standard directories in @{HOMEDIRS}
  owner @{HOMEDIRS}/.cache/@{APPNAME}/ rw,
  owner @{HOMEDIRS}/.cache/@{APPNAME}/** rwkl,
  owner @{HOMEDIRS}/.config/@{APPNAME}/ rw,
  owner @{HOMEDIRS}/.config/@{APPNAME}/** rwkl,
  owner @{HOMEDIRS}/.local/share/@{APPNAME}/ rw,
  owner @{HOMEDIRS}/.local/share/@{APPNAME}/** rwkl,
Line 32: Line 62:
 1. How will users learn the new way of doing things? Describe any help pages required, and any changes to the Ubuntu Web site or installer slideshow.   # Specified read permissions
  @{HOME}/Downloads/ r,
  owner @{HOME}/Downloads/** r,
Line 34: Line 66:
 1. Is any migration of data or settings required?   # Specified write permissions
  /opt/@{APPNAME}/tmp/ rwk,
  /opt/@{APPNAME}/tmp/** rwk,
  /opt/@{APPNAME}/log/ rwk,
  /opt/@{APPNAME}/log/** rwk,
}
}}}
Line 36: Line 74:
 1. How will the feature be tested? Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. Templates can also be specified using an absolute path like `aa-easyprof --template=~/my-cool-template ...`.
Also see `man aa-easyprof` for more information.
Line 38: Line 77:
== Unresolved issues == === SDK integration ===
 
While `aa-easyprof` is a CLI application which outputs its policy on stdout. It is written in python and implemented as a library and requires no special privileges to use. This means that SDKs can either use `aa-easyprof` directly or import `aparmor.easyprof`. Eg:{{{
import apparmor.easyprof
from apparmor.easyprof import AppArmorException, error
...
class FooSDK(...):
    ...
    def __init__(self, binary):
        ...
        self.conffile = "<path>/sdk/aa-easyprof.conf"
        ...
Line 40: Line 90:
Highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.     def cmd(self, template, pgroups, abstractions, ...):
        ...
        args = ['-c', self.conffile, '-t', template, '-p', pgroups, '-a', abstractions, ...]
        try:
            (options, args) = apparmor.easyprof.parse_args(args + [binary])
        except AppArmorException:
            raise
        except Exception:
            raise

        easyp = apparmor.easyprof.AppArmorEasyProfile(binary, options)
        params = apparmor.easyprof.gen_policy_params(binary, options)
        policy = easyp.gen_policy(**params)
        ...
}}}
See `utils/test/test-aa-easyprof.py` for examples on some of the ways easyprof.py can be used.

SDKs can simply drop files into the system wide `/usr/share/apparmor/easyprof/templates` and `/usr/share/apparmor/easyprof/policygroups` to make them readily available, or they can setup their own templates and policygroups directories and pass '--templates-dir' and '--policy-groups-dir' as arguments to `-aa-easyprof` or `apparmor.easyprof.parse_args`.

To support the ARB and other projects, AppArmor should include a a standalone CLI application which can also be imported into developer SDKs.

Rationale

Confining applications is desirable for many reasons, including security, protection from misbehaving applications, malicious software and reducing the burden of application review. The ARB have discussed this to some extent, but other projects including AppArmor's users would also benefit.

User stories

  • Dan develops applications for Ubuntu and would like to add AppArmor protection to his application. He would like to be able to state 'my application uses X but does not use networking' without having to know all the details about AppArmor profiling.

  • Regina reviews packages for the ARB. Most applications currently require extensive code review, but if she receives an application with an AppArmor profile, it could reduce some of the code review (eg, reduce it to networking and DBus interactions).

Documentation

Usage

aa-easyprof is a standalone CLI application which can also be imported into developer SDKs. aa-easyprof supports the use of templates and policy groups to quickly profile an application. In essence, aa-easyprof takes a different view on policy generation and is useful when you already know how the application should behave and want to create an initial policy based on this behavior. As such, one can use a template and any appropriate policy groups (groupings of AppArmor policy rules) then use aa-easyprof to generate a policy. Currently the combination of the user-application template along with the opt-application and user-application policygroups should achieve a working policy for Ubuntu's Application Review Board. Specify multiple arguments as desired (see man aa-easyprof), then the policy is generated, verified and sent to stdout. Eg:

$ aa-easyprof --template=user-application \
              --policy-groups=opt-application,user-application \
              --abstractions="python,audio" \
              --read-path="@{HOME}/Downloads/" \
              --write-path="/opt/@{APPNAME}/tmp/" \
              --write-path="/opt/@{APPNAME}/log/" \
              --template-var="@{APPNAME}=foo" \
              --author="Dan Doodongle" \
              --copyright="Copyright 2012, Dangling Doodongles Inc" \
              --comment="AppArmor is easy with aa-easyprof" \
              /opt/foo/bin/foo
# vim:syntax=apparmor
# AppArmor policy for foo
# Author: Dan Doodongle
# Copyright: Copyright 2012, Dangling Doodongles Inc
# Comment: AppArmor is easy with aa-easyprof

#include <tunables/global>

# Specified profile variables
@{APPNAME}=foo

/opt/foo/bin/foo {
  #include <abstractions/base>

  # Specified abstractions
  #include <abstractions/python>
  #include <abstractions/audio>

  # Rules specified via policy groups
  # Policy group for applications installed in /opt
  /opt/@{APPNAME}/ r,
  /opt/@{APPNAME}/** mrk,

  # Policy group allowing various writes to standard directories in @{HOMEDIRS}
  owner @{HOMEDIRS}/.cache/@{APPNAME}/ rw,
  owner @{HOMEDIRS}/.cache/@{APPNAME}/** rwkl,
  owner @{HOMEDIRS}/.config/@{APPNAME}/ rw,
  owner @{HOMEDIRS}/.config/@{APPNAME}/** rwkl,
  owner @{HOMEDIRS}/.local/share/@{APPNAME}/ rw,
  owner @{HOMEDIRS}/.local/share/@{APPNAME}/** rwkl,

  # Specified read permissions
  @{HOME}/Downloads/ r,
  owner @{HOME}/Downloads/** r,

  # Specified write permissions
  /opt/@{APPNAME}/tmp/ rwk,
  /opt/@{APPNAME}/tmp/** rwk,
  /opt/@{APPNAME}/log/ rwk,
  /opt/@{APPNAME}/log/** rwk,
}

Templates can also be specified using an absolute path like aa-easyprof --template=~/my-cool-template .... Also see man aa-easyprof for more information.

SDK integration

While aa-easyprof is a CLI application which outputs its policy on stdout. It is written in python and implemented as a library and requires no special privileges to use. This means that SDKs can either use aa-easyprof directly or import aparmor.easyprof. Eg:

import apparmor.easyprof
from apparmor.easyprof import AppArmorException, error
...
class FooSDK(...):
    ...
    def __init__(self, binary):
        ...
        self.conffile = "<path>/sdk/aa-easyprof.conf"
        ...

    def cmd(self, template, pgroups, abstractions, ...):
        ...
        args = ['-c', self.conffile, '-t', template, '-p', pgroups, '-a', abstractions, ...]
        try:
            (options, args) = apparmor.easyprof.parse_args(args + [binary])
        except AppArmorException:
            raise
        except Exception:
            raise

        easyp = apparmor.easyprof.AppArmorEasyProfile(binary, options)
        params = apparmor.easyprof.gen_policy_params(binary, options)
        policy = easyp.gen_policy(**params)
        ...

See utils/test/test-aa-easyprof.py for examples on some of the ways easyprof.py can be used.

SDKs can simply drop files into the system wide /usr/share/apparmor/easyprof/templates and /usr/share/apparmor/easyprof/policygroups to make them readily available, or they can setup their own templates and policygroups directories and pass '--templates-dir' and '--policy-groups-dir' as arguments to -aa-easyprof or apparmor.easyprof.parse_args.


CategorySpec

SecurityTeam/Specifications/Precise/AppArmorEasyprof (last edited 2012-02-07 23:44:50 by jdstrand)