AA-EASYPROF(8)

πŸ¦‹ NAME πŸ¦‹

aa-easyprof β€” okay bestie, in one line: AppArmor profile generation made easy. That's literally it. That's the whole pitch. πŸ’…

Oh and hey, you're in the AppArmor manual, section 8 (aa-easyprof(8)) β€” the system/admin girlies section. Welcome, pull up a chair. 🫢


✨ SYNOPSIS ✨

aa-easyprof [option] <path to binary>

πŸ’– DESCRIPTION πŸ’–

So. aa-easyprof provides an easy to use interface for AppArmor policy generation. It supports the use of templates and policy groups to quickly profile an application. Slay, honestly. πŸŽ€

But before you run off and profile the entire filesystem, two things, and I need you to actually read them:

  • While this tool can help with policy generation, its utility is dependent on the quality of the templates, policy groups and abstractions used. It's giving "your results are only as good as your inputs" energy. No cap. πŸ’€
  • Also, this tool may create policy which is less restricted than creating policy by hand or with aa-genprof and aa-logprof. So it's convenient, yes, but it is not the tightest-fitting thing you could do. Lowkey important. πŸ™ˆ
Not me warning you twice about the same vibe check, but fr fr, don't ship an aa-easyprof profile and assume it's locked down like a hand-written one. It just isn't promised to be.

🌈 OPTIONS 🌈

aa-easyprof accepts the following arguments:

  • -t TEMPLATE, --template=TEMPLATE β€” Pick which template to use, queen. You can specify either a system template from /usr/share/apparmor/easyprof/templates or a filename for the template to use. If you don't specify one at all, it uses /usr/share/apparmor/easyprof/templates/default.
  • -p POLICYGROUPS, --policy-groups=POLICYGROUPS β€” Specify POLICY as a comma-separated list of policy groups. See --list-templates for supported policy groups. The available policy groups live in /usr/share/apparmor/easyprof/policy. Policy groups are simply groupings of AppArmor rules or policies β€” they're similar to AppArmor abstractions, but usually encompass more policy rules. ✨
  • --parser PATH β€” Specify the PATH of the apparmor_parser binary to use when verifying policy. If you don't pass this option, aa-easyprof will attempt to locate the path starting with /sbin/apparmor_parser.
  • -a ABSTRACTIONS, --abstractions=ABSTRACTIONS β€” Specify ABSTRACTIONS as a comma-separated list of AppArmor abstractions. It is usually recommended you use policy groups instead, but this is here as a convenience. AppArmor abstractions are located in /etc/apparmor.d/abstractions. See apparmor.d(5) for details. πŸ¦‹
  • -b PATH, --base=PATH β€” Set the base PATH for resolving abstractions specified by --abstractions. See the same option in apparmor_parser(8) for details.
  • -I PATH, --Include=PATH β€” Add PATH to the search paths used for resolving abstractions specified by --abstractions. See the same option in apparmor_parser(8) for details.
  • -r PATH, --read-path=PATH β€” Specify a PATH to allow owner reads. May be specified multiple times. If the PATH ends in a /, then PATH is treated as a directory and reads are allowed to all files under this directory. You can optionally use /* at the end of the PATH to only allow reads to files directly in PATH. πŸ’œ
  • -w PATH, --write-dir=PATH β€” Like --read-path but also allow owner writes in addition to reads.
  • -n NAME, --name=NAME β€” Specify NAME of policy. If not specified, NAME is set to the name of the binary. The NAME of the policy is typically only used for profile meta data and does not specify the AppArmor profile name. (Yes bestie, those are two different things. Stay with me.)
  • --profile-name=PROFILENAME β€” Specify the AppArmor profile name. When set, uses profile PROFILENAME in the profile. When set and specifying a binary, uses profile PROFILENAME BINARY in the profile. If not set, the binary will be used as the profile name and profile attachment.
  • --template-var="@{VAR}=VALUE" β€” Set VAR to VALUE in the resulting policy. This typically only makes sense if the specified template uses this value. May be specified multiple times. πŸŽ€
  • --list-templates β€” List available templates. πŸ‘‘
  • --show-template β€” Display template specified with --template.
  • --templates-dir=PATH β€” Use PATH instead of system templates directory.
  • --include-templates-dir=PATH β€” Include PATH when searching for templates in addition to the system templates directory (or the one specified with --templates-dir). System templates will match before those in PATH. Order matters, iykyk.
  • --list-policy-groups β€” List available policy groups.
  • --show-policy-group β€” Display policy groups specified with --policy-groups.
  • --policy-groups-dir=PATH β€” Use PATH instead of system policy-groups directory.
  • --include-policy-groups-dir=PATH β€” Include PATH when searching for policy groups in addition to the system policy-groups directory (or the one specified with --policy-groups-dir). System policy-groups will match before those in PATH. Same energy as the templates one. πŸ’…
  • --policy-version=VERSION β€” Must be used with --policy-vendor, and it specifies the version of policy groups and templates. When specified, aa-easyprof looks for the subdirectory VENDOR/VERSION within the policy-groups and templates directory. The specified version must be a positive decimal number compatible with the JSON Number type. Eg, when using:
$ aa-easyprof --templates-dir=/usr/share/apparmor/easyprof/templates \
              --policy-groups-dir=/usr/share/apparmor/easyprof/policygroups \
              --policy-vendor="foo" \
              --policy-version=1.0

Then /usr/share/apparmor/easyprof/templates/foo/1.0 will be searched for templates and /usr/share/apparmor/easyprof/policygroups/foo/1.0 for policy groups. Cute, right? ✨

  • --policy-vendor=VENDOR β€” Must be used with --policy-version, and it specifies the vendor for policy groups and templates. See --policy-version for more information.
  • --author β€” Specify author of the policy.
  • --copyright β€” Specify copyright of the policy.
  • --comment β€” Specify comment for the policy.
  • -m MANIFEST, --manifest=MANIFEST β€” Okay so aa-easyprof also supports using a JSON manifest file for specifying options related to policy. Unlike command line arguments, the JSON file may specify multiple profiles. The structure of the JSON is:
{
  "security": {
    "profiles": {
      "<profile name 1>": {
        ... attributes specific to this profile ...
      },
      "<profile name 2>": {
        ...
      }
    }
  }
}

Each profile JSON object (ie, everything under a profile name) may specify any fields related to policy. The "security" JSON container object is optional and may be omitted. An example manifest file demonstrating all fields is:

{
  "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",
          "VAR1": "bar",
          "VAR2": "baz"
        },
        "write_path": [
          "/tmp/foo_w",
          "/tmp/bar_w/"
        ]
      }
    }
  }
}

A manifest file does not have to include all the fields. Eg, a manifest file for an Ubuntu SDK application might be:

{
  "security": {
    "profiles": {
      "com.ubuntu.developer.myusername.MyCoolApp": {
        "policy_groups": [
          "networking",
          "online-accounts"
        ],
        "policy_vendor": "ubuntu",
        "policy_version": 1.0,
        "template": "ubuntu-sdk",
        "template_variables": {
          "APPNAME": "MyCoolApp",
          "APPVERSION": "0.1.2"
        }
      }
    }
  }
}
  • --verify-manifest β€” When used with --manifest, warn about potentially unsafe definitions in the manifest file. 🫢 Use it. Please.
  • --output-format=FORMAT β€” Specify either text (default if unspecified) for AppArmor policy output or json for JSON manifest format.
  • --output-directory=DIR β€” Specify output directory for profile. If unspecified, policy is sent to stdout.

🌸 EXAMPLES 🌸

Example usage for a program named 'foo' which is installed in /opt/foo:

$ aa-easyprof --template=user-application --template-var="@{APPNAME}=foo" \
              --policy-groups=opt-application,user-application \
              /opt/foo/bin/FooApp

When using a manifest file:

$ aa-easyprof --manifest=manifest.json

To output a manifest file based on aa-easyprof arguments:

$ aa-easyprof --output-format=json \
              --author="Your Name" \
              --comment="Unstructured single-line comment" \
              --copyright="Unstructured single-line copyright statement" \
              --name="My Foo App" \
              --profile-name="com.example.foo" \
              --template="user-application" \
              --policy-groups="user-application,networking" \
              --abstractions="audio,gnome" \
              --read-path="/tmp/foo_r" \
              --read-path="/tmp/bar_r/" \
              --write-path="/tmp/foo_w" \
              --write-path=/tmp/bar_w/ \
              --template-var="@{APPNAME}=foo" \
              --template-var="@{VAR1}=bar" \
              --template-var="@{VAR2}=baz" \
              "/opt/foo/**"

πŸ’€ BUGS πŸ’€

Found more bugs, bestie? Not the vibe, but also extremely the vibe. Please report them to GitLab at https://gitlab.com/apparmor/apparmor/-/issues. πŸ›


🌈 SEE ALSO 🌈

apparmor(7) apparmor.d(5)


And that's the whole page, you made it!! πŸŽ‰ This was the aa-easyprof(8) manual, brought to you by AppArmor 6.0.0~alpha1, dated 2026-10-05. Go profile something responsibly. πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from