Manifest

Differences between revisions 2 and 19 (spanning 17 versions)
Revision 2 as of 2013-06-28 22:10:37
Size: 6543
Editor: jdstrand
Comment:
Revision 19 as of 2013-07-05 21:30:45
Size: 10577
Editor: jdstrand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Manifest file - security (draft) =
Line 2: Line 3:
= Manifest file - security = ||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; background-repeat: no-repeat; background-position: 98% 0.5ex; margin: 0 0 1em 1em; padding: 0.5em;"><<TableOfContents>>||
Line 4: Line 5:
== Overview ==
Line 6: Line 6:
discussed the manifest file format for click packages in general. This page discusses the manifest file format for click packages in general. This page
Line 8: Line 8:
contain the toplevel 'security' key, and the 'security' is itself a dictionary
with each subkey representing a profile. The ''aa-easyprof''' tool is used to
parse the security section of the manifest and generate an !AppArmor profile.
'''aa-easyprof''' will be used by click via a hook to install !AppArmor policy.
For more details on '''aa-easyprof''', see `man 8 aa-easyprof`. An example
manifest representing all possible keys is: {{{
contain the toplevel 'security' key, and the 'security' object is a dictionary
with currently only one key defined: 'profiles'. The profiles object is a
dictionary each of its keys be
ing the name of a profile object
(also a dictionary)
. The '''aa-easyprof''' tool is used to parse the security
section of the manifest and generate an !AppArmor profile.  '''aa-easyprof'''
will be used by click via a hook to install !AppArmor policy.  For more details
on '''aa-easyprof''', see `man 8 aa-easyprof`. An example manifest representing
all possible keys is: {{{
Line 15: Line 17:
  "name": "Name used by click",
  "version": "Version used by click>",
  "name": "Name used by click (reverse domain name)",
  "version": "Version used by click",
  "maintainer": "Your Name <your.name@example.com
>",
  "title": "Display name (translatable)",
Line 19: Line 23:
    "com.example.foo": {
      "abstractions": [
        "audio",
        "gnome"
      ],
      "author": "Your Name",
      "binary": "/opt/foo/**",
      "comment": "Unstructured single-line comment",
      "copyright": "Unstructured single-line copyright statement",
      "name": "My Foo App",
      "policy_groups": [
        "networking",
        "user-application"
      ],
      "policy_vendor": "somevendor",
      "policy_version": 1.0,
      "read_path": [
        "/tmp/foo_r",
        "/tmp/bar_r/"
      ],
      "template": "user-application",
      "template_variables": {
        "APPNAME": "foo",
        "VAR1": "bar",
        "VAR2": "baz"
      },
      "write_path": [
        "/tmp/foo_w",
        "/tmp/bar_w/"
      ]
    "profiles": {
  
"com.example.foo": {
        "abstractions": [
          "audio",
          "gnome"
        ],
        "author": "Your Name",
   "binary": "/opt/foo/**",
        "comment": "Unstructured single-line comment",
   "copyright": "Unstructured single-line copyright statement",
        "name": "My Foo App",
        "policy_groups": [
          "networking",
          "user-application"
        ],
        "policy_vendor": "somevendor",
   "policy_version": 1.0,
        "read_path": [
          "/tmp/foo_r",
          "/tmp/bar_r/"
        ],
        "template": "user-application",
        "template_variables": {
   "APPNAME": "foo",
          "APPVERSION": "0.1",
          
"VAR1": "bar",
          "VAR2": "baz"
        },
        "write_path": [
          "/tmp/foo_w",
          "/tmp/bar_w/"
        ]
      }
Line 54: Line 61:
=== Security keys ===
 * '''profile name''': each profile is represented as a dictionary object. Therefore in the above example, "com.example.foo" is the profile name and the contents of the "com.example.foo" dictionary represent the profile.
 * '''binary''': path to binary for this policy when using path-based attachment
== Security keys ==
aa-easyprof is a general purpose tool and all of the keys within a profile object are optional.
 * '''profile name''': keys to the 'profiles' dictionary are the profile names for each profile object. Therefore in the above example, "com.example.foo" is the profile name and the contents of the "com.example.foo" dictionary represent the profile. The profile name may specify the normalized absolute path to the binary (with AARE (see `apparmor.d(8)`) or an name that consists only of lower case letters (a-z), upper case letters (A-Z), digits (0-9), plus (+) and minus (-) signs, periods (.), colons (:) and tildes (~) (essentially a combination of the allowed characters for Ubuntu package names and versions)
 * '''binary''': path to binary for this policy when using path-based attachment. Should not be specified when the profile name is an absolute path
Line 60: Line 68:
 * '''name''': name of policy. If not specified, use the name of the binary. This is not the !AppArmor profile name.
 * '''policy_vendor''': the vendor for policy groups and templates
 * '''policy_version''': version of the vendor policy
 * '''template''': template to use
 * '''template_variables''': list of template variable assignments
 * '''name''': name of policy. If not specified, use the name of the binary. Note, this is not the !AppArmor profile name.
 * '''policy_vendor''': vendor of policy groups and templates ([a-zA-Z_0-9\-\.])
 * '''policy_version''': version of the vendor policy (float)
 * '''template''': template to use ([a-zA-Z_0-9\-\.])
 * '''template_variables''': list of template variable assignments. Supported template variables are template-specific
Line 66: Line 74:
 * '''policy_groups''': list of !AppArmor policy groups to include  * '''policy_groups''': list of !AppArmor policy groups to include ([a-zA-Z_0-9\-\.])
Line 70: Line 78:
'''aa-easyprof''' is a general purpose tool and all of the security keys are
optional.
= Use in Ubuntu =
== Click ==
Click packages in Ubuntu are required to run under application confinement and therefore the manifest file must contain a security section. When a click package is installed, a hook will be invoked on the package to process the manifest file and output an !AppArmor profile. This hook will setup some `aa-easyprof` fields automatically (such as policy_vendor). As such, some fields are required, some handled automatically, some unused and some are technically supported but dangerous and will red flag the package for manual review.
 * Required fields for each profile object in the profiles dictionary of the security object:
  * JSON profile object (ie, the '''profile name''' key and its corresponding dictionary). In click on Ubuntu, the profile name should specify the name of the desktop that launches the program that this profile is meant to protect. The only exception is if the profile name is used to specify path-based attachment (where the version of the app is expected to be part of the absolute path)
  * '''policy_groups''' - these are used to grant permissions to the app, such as networking, online accounts, content picking, etc. See `aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-policy-groups` for a complete list
  * '''policy_version''' should be set. '''1.0''' is the first supported Ubuntu policy version. For other versions, see /usr/share/apparmor/easyprof/templates/ubuntu/ and /usr/share/apparmor/easyprof/policygroups/ubuntu/
  * '''template''' - automatically set to '''ubuntu-sdk''' if not specified. See `aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-templates` (using the appropriate vendor version) for a list of other templates
  * '''policy_vendor''' - automatically set to '''ubuntu'''
  * '''template_variables''' - automatically sets the following:
   * '''APPNAME''' - set to '''name''' from the toplevel click manifest (eg, '''"APPNAME": "com.ubuntu.developer.username.myapp"''')
   * '''APPVERSION''' - set to '''version''' from the toplevel click manifest (eg, '''"APPVERSION": "0.1"''')
Line 73: Line 91:
=== Use in Ubuntu ===
==== Click ====
Click packages in Ubuntu are required to run under application confinement and therefore the manifest file must contain a security section.
 * Required fields
  * JSON profile object (ie, the profile name key and its corresponding dictionary)
  * policy_vendor should be set to "ubuntu"
  * policy_version should be set. 1.0 is the first supported Ubuntu policy version. For other versions, see /usr/share/apparmor/easyprof/templates/ubuntu/ and /usr/share/apparmor/easyprof/policygroups/ubuntu/
  * binary - should be set as a recursive glob on the toplevel installation directory. Eg, if the app is installed to `/opt/com.ubuntu.developer/com.ubuntu.developer.username.myapp`, then binary should be set to `/opt/com.ubuntu.developer/com.ubuntu.developer.username.myapp/**`
  * template - defaults to 'default' which is a symlink to ubuntu-sdk. See `aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-templates` (using the appropriate vendor version) for a list of other templates
  * template_variables - the Ubuntu templates support setting the following variables:
   * APPNAME - typically the reverse domain (eg, com.ubuntu.developer.username.appname). This is used to differentiate application paths. Eg:{{{
 @{APPNAME}=com.ubuntu.developer.username.myapp
  These template variables are used to differentiate application paths. Eg, the resulting !AppArmor policy will have something like:{{{
 @{APPNAME}="com.ubuntu.developer.username.myapp"
 @{APPVERSION}="0.1"
Line 86: Line 95:
   /opt/com.ubuntu.developer/@{APPNAME}/** r,    /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/ r,
   /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/** r,
   /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/**/ r,
Line 88: Line 99:
  * policy_groups - these are used to grant permissions to the app, such as netowrking, online accounts, content picking, etc. Some policy groups might always be used, such as `qmlscene` while others will only be used by some apps (eg, `qmlscene-webview` for HTML5 apps). See `aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-policy-groups` for a complete list
 * Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates)
  * abstractions
  * read_path
  * write_path
Line 98: Line 104:
 * Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates)
  * abstractions
  * read_path
  * write_path
  * binary may be set as a recursive glob on the toplevel installation directory. Eg, if the app is installed to `/opt/com.ubuntu.developer/com.ubuntu.developer.username.myapp`, then binary could be legitimately set to `/opt/com.ubuntu.developer/com.ubuntu.developer.username.myapp/**`. Not typically necessary
Line 99: Line 110:
==== Traditional packaging ==== An example manifest for an Ubuntu click package might be:{{{
 {
   "name": "com.ubuntu.developer.username.myapp",
   "version": "0.1",
   "maintainer": "Your Name <your.name@example.com>",
   "title": "My Cool App",
   "framework": "ubuntu-sdk-13.10",
   "security": {
     "profiles": {
       "myapp.desktop": {
         "policy_groups": [
           "networking"
         ],
         "policy_version": 1.0
       },
       "myapp-camera.desktop": {
         "policy_groups": [
           "camera",
           "location"
         ],
         "policy_version": 1.0
       }
     }
   }
 }
}}}

== Traditional packaging ==
Line 101: Line 139:
 * the manifest file (only the security section is needed) is added to debian/  * the manifest file (only the security section is needed) is added to debian/. Because traditional packaging has different governance rules for including in a distribution, the manifest may contain any of the supported fields
Line 106: Line 144:
This is made easier with `dh_apparmor`. Create a manifest file following the above instructions then: The process is made easier with `dh_apparmor`. Create a manifest file following the above instructions for required fields (note that you must fill in the automatic ones yourself when not using click packaging) then:
Line 123: Line 161:
The remaining consideration is making sure that the app runs confined. If the application provides an executables (eg, ELF binary, executable python script), then specifying the 'binary' in the manifest is enough. If instead a helper is being used, such as qmlscene, then it is easier to update the .desktop file. Eg, instead of this:{{{
Exec=qmlscene <path to>.qml
}}}
Use this:{{{
Exec=aa-exec -p <profile name> qmlscene <path to>.qml
}}}
The remaining consideration is making sure that the app runs confined. You'll know you have it right if when the application is running, the output of `aa-status` shows that the application is confined. If the application provides an executable (eg, ELF binary, executable python script), then specifying the 'binary' in the manifest is enough. If instead a helper such as qmlscene is being used, there are several choices:
 * use the new Ubuntu application lifecycle and start the application via an Upstart job (preferred, pending but not available as of 2013/07/02)
 * add `XCanonicalAppArmorProfile=<profile name>` to the .desktop file until Ubuntu application lifecycle is finished (not available as of 2013/07/02)
 * update the .desktop file so use `aa-exec -p <profile name> ...` in the Exec line. Unfortunately there is an issue using aa-exec in .desktop files, which may be related to glib
 * Create a shell script to use `aa-exec -p <profile name> ...` and have the .desktop file use `Exec=<path to shell script>`
Line 130: Line 167:
This last step should not be required if the application uses the new Ubuntu application lifecycle and is started via Upstart jobs. = Bugs =
When filing bugs dealing with the manifest file or resulting permissions, please use one of the below and use the 'application-confinement' tag:
 * [[https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+filebug|Bugs against AppArmor policy for SDK applications]]
 * [[https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug|General bugs against aa-easyprof]]
 * [[https://bugs.launchpad.net/ubuntu-qtcreator-plugins/+filebug|Policy bugs that should be resolved in the SDK]]

Manifest file - security (draft)

http://bazaar.launchpad.net/~click-hackers/click/trunk/view/head:/doc/file-format.rst discusses the manifest file format for click packages in general. This page discusses the security section of the JSON manifest. Click packages will contain the toplevel 'security' key, and the 'security' object is a dictionary with currently only one key defined: 'profiles'. The profiles object is a dictionary each of its keys being the name of a profile object (also a dictionary). The aa-easyprof tool is used to parse the security section of the manifest and generate an AppArmor profile. aa-easyprof will be used by click via a hook to install AppArmor policy. For more details on aa-easyprof, see man 8 aa-easyprof. An example manifest representing all possible keys is:

{
  "name": "Name used by click (reverse domain name)",
  "version": "Version used by click",
  "maintainer": "Your Name <your.name@example.com>",
  "title": "Display name (translatable)",
  "framework": "Framework used by click",
  "security": {
    "profiles": {
      "com.example.foo": {
        "abstractions": [
          "audio",
          "gnome"
        ],
        "author": "Your Name",
        "binary": "/opt/foo/**",
        "comment": "Unstructured single-line comment",
        "copyright": "Unstructured single-line copyright statement",
        "name": "My Foo App",
        "policy_groups": [
          "networking",
          "user-application"
        ],
        "policy_vendor": "somevendor",
        "policy_version": 1.0,
        "read_path": [
          "/tmp/foo_r",
          "/tmp/bar_r/"
        ],
        "template": "user-application",
        "template_variables": {
          "APPNAME": "foo",
          "APPVERSION": "0.1",
          "VAR1": "bar",
          "VAR2": "baz"
        },
        "write_path": [
          "/tmp/foo_w",
          "/tmp/bar_w/"
        ]
      }
    }
  }
}

Security keys

aa-easyprof is a general purpose tool and all of the keys within a profile object are optional.

  • profile name: keys to the 'profiles' dictionary are the profile names for each profile object. Therefore in the above example, "com.example.foo" is the profile name and the contents of the "com.example.foo" dictionary represent the profile. The profile name may specify the normalized absolute path to the binary (with AARE (see apparmor.d(8)) or an name that consists only of lower case letters (a-z), upper case letters (A-Z), digits (0-9), plus (+) and minus (-) signs, periods (.), colons (:) and tildes (~) (essentially a combination of the allowed characters for Ubuntu package names and versions)

  • binary: path to binary for this policy when using path-based attachment. Should not be specified when the profile name is an absolute path

  • author: author of the policy

  • comment: comment for the policy

  • copyright: copyright of the policy

  • name: name of policy. If not specified, use the name of the binary. Note, this is not the AppArmor profile name.

  • policy_vendor: vendor of policy groups and templates ([a-zA-Z_0-9\-\.])

  • policy_version: version of the vendor policy (float)

  • template: template to use ([a-zA-Z_0-9\-\.])

  • template_variables: list of template variable assignments. Supported template variables are template-specific

  • abstractions: list of AppArmor abstractions to include (typically from /etc/apparmor.d)

  • policy_groups: list of AppArmor policy groups to include ([a-zA-Z_0-9\-\.])

  • read_path: list of paths to allow read access

  • write_path: list of paths to allow write access

Use in Ubuntu

Click

Click packages in Ubuntu are required to run under application confinement and therefore the manifest file must contain a security section. When a click package is installed, a hook will be invoked on the package to process the manifest file and output an AppArmor profile. This hook will setup some aa-easyprof fields automatically (such as policy_vendor). As such, some fields are required, some handled automatically, some unused and some are technically supported but dangerous and will red flag the package for manual review.

  • Required fields for each profile object in the profiles dictionary of the security object:
    • JSON profile object (ie, the profile name key and its corresponding dictionary). In click on Ubuntu, the profile name should specify the name of the desktop that launches the program that this profile is meant to protect. The only exception is if the profile name is used to specify path-based attachment (where the version of the app is expected to be part of the absolute path)

    • policy_groups - these are used to grant permissions to the app, such as networking, online accounts, content picking, etc. See aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-policy-groups for a complete list

    • policy_version should be set. 1.0 is the first supported Ubuntu policy version. For other versions, see /usr/share/apparmor/easyprof/templates/ubuntu/ and /usr/share/apparmor/easyprof/policygroups/ubuntu/

    • template - automatically set to ubuntu-sdk if not specified. See aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-templates (using the appropriate vendor version) for a list of other templates

    • policy_vendor - automatically set to ubuntu

    • template_variables - automatically sets the following:

      • APPNAME - set to name from the toplevel click manifest (eg, "APPNAME": "com.ubuntu.developer.username.myapp")

      • APPVERSION - set to version from the toplevel click manifest (eg, "APPVERSION": "0.1")

      These template variables are used to differentiate application paths. Eg, the resulting AppArmor policy will have something like:

       @{APPNAME}="com.ubuntu.developer.username.myapp"
       @{APPVERSION}="0.1"
       ...
         /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/    r,
         /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/**  r,
         /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/**/ r,
  • Unused/ignored
    • name
    • author
    • comment
    • copyright
  • Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates)
    • abstractions
    • read_path
    • write_path
    • binary may be set as a recursive glob on the toplevel installation directory. Eg, if the app is installed to /opt/com.ubuntu.developer/com.ubuntu.developer.username.myapp, then binary could be legitimately set to /opt/com.ubuntu.developer/com.ubuntu.developer.username.myapp/**. Not typically necessary

An example manifest for an Ubuntu click package might be:

 {
   "name": "com.ubuntu.developer.username.myapp",
   "version": "0.1",
   "maintainer": "Your Name <your.name@example.com>",
   "title": "My Cool App",
   "framework": "ubuntu-sdk-13.10",
   "security": {
     "profiles": {
       "myapp.desktop": {
         "policy_groups": [
           "networking"
         ],
         "policy_version": 1.0
       },
       "myapp-camera.desktop": {
         "policy_groups": [
           "camera",
           "location"
         ],
         "policy_version": 1.0
       }
     }
   }
 }

Traditional packaging

Traditional packaging can also leverage aa-easyprof, but the process is slightly more involved. In general, the following need to happen (see man dh_apparmor for details):

  • the manifest file (only the security section is needed) is added to debian/. Because traditional packaging has different governance rules for including in a distribution, the manifest may contain any of the supported fields
  • aa-easyprof is given the manifest file to generate a profile
  • the profile is installed into a package
  • the postinst loads the AppArmor policy into the kernel

The process is made easier with dh_apparmor. Create a manifest file following the above instructions for required fields (note that you must fill in the automatic ones yourself when not using click packaging) then:

  1. put the manifest file in debian/manifest.json
  2. adjust debian/control to Build-Depends on dh-apparmor >= 2.8.0-0ubuntu14

  3. update debian/rules to call dh_apparmor. Eg:

    override_dh_install:
            dh_apparmor -p<deb binary> --profile-name=<profile name from the manifest> --manifest=manifest.json
            dh_install

    and then to clean up:

    override_dh_clean:
            dh_clean
            rm -rf debian/apparmor
  4. install the files. Eg, add to debian/<deb binary>.install:

    debian/apparmor/<profile name> etc/apparmor.d

The remaining consideration is making sure that the app runs confined. You'll know you have it right if when the application is running, the output of aa-status shows that the application is confined. If the application provides an executable (eg, ELF binary, executable python script), then specifying the 'binary' in the manifest is enough. If instead a helper such as qmlscene is being used, there are several choices:

  • use the new Ubuntu application lifecycle and start the application via an Upstart job (preferred, pending but not available as of 2013/07/02)
  • add XCanonicalAppArmorProfile=<profile name> to the .desktop file until Ubuntu application lifecycle is finished (not available as of 2013/07/02)

  • update the .desktop file so use aa-exec -p <profile name> ... in the Exec line. Unfortunately there is an issue using aa-exec in .desktop files, which may be related to glib

  • Create a shell script to use aa-exec -p <profile name> ... and have the .desktop file use Exec=<path to shell script>

Bugs

When filing bugs dealing with the manifest file or resulting permissions, please use one of the below and use the 'application-confinement' tag:

SecurityTeam/Specifications/ApplicationConfinement/Manifest (last edited 2014-03-17 13:57:55 by jdstrand)