AppArmor

AppArmor protects systems from insecure or untrusted processes by running them in restricted confinement, while still allowing processes to share files, exercise privilege and communicate with other processes. AppArmor is a Mandatory Access Control (MAC) mechanism which uses the Linux Security Module (LSM) framework. The confinement's restrictions are mandatory and are not bound to identity, group membership, or object ownership. The protections provided are in addition to the kernel's regular access control mechanisms (including DAC) and can be used to restrict the superuser. The AppArmor kernel module and accompanying user-space tools are available under the GPL license (the exception is the libapparmor library, available under the LGPL license, which allows change hat(2) and change profile(2) to be used by non-GPL binaries). For more information, you can read the techdoc.pdf (available after building the parser) and by visiting the web site. Please send all complaints, feature requests, rants about the software, and questions to the AppArmor mailing list. Bug reports can be filed against the AppArmor project on GitLab or reported to the mailing list directly for those who wish not to register for an account on GitLab. See the wiki page for more information. The AppArmor security project respects users privacy and data and does not collect data from or on its users beyond what is required for a given component to function. The AppArmor kernel security module will log violations to the audit subsystem, and those will be logged/forwarded/recorded on the user's system(s) according to how the administrator has logging configured. Again this is not forwarded to or collected by the AppArmor project. The AppArmor userspace tools do not collect information on the system user beyond the logs and information needed to interact with the user. This is not forwarded to, nor collected by the AppArmor project. While most of the kernel AppArmor code has been accepted in the upstream Linux kernel, a few important pieces were not included. These missing pieces unfortunately are important bits for AppArmor userspace and kernel interaction; therefore we have included compatibility patches in the kernel-patches/ subdirectory, versioned by upstream kernel (2.6.37 patches should apply cleanly to 2.6.38 source). Without these patches applied to the kernel, the AppArmor userspace will not function correctly. To build and install AppArmor userspace on your system, build and install in the following order. Some systems may need to export various python-related environment variables to complete the build. For example, before building anything on these systems, use something along the lines of: Note that, in general, the build steps can be run in parallel, while the test steps do not gain much speedup from being run in parallel. This is because the test steps spawn a handful of long-lived test runner processes that mostly run their tests sequentially and do not use make 's jobserver. Moreover, process spawning overhead constitutes a significant part of test runtime, so reworking the test harnesses to add parallelism (which would be a major undertaking for the harnesses that do not have it already) would not produce much of a speedup. Note that the empty local/ profile sniplets no longer get created by default. If you want them, run make local before running make check . [Note that for the parser, binutils, and utils, if you only wish to build/use some of the locale languages, you can override the default by passing the LANGS arguments to make; e.g. make all install "LANGS=en US fr".] Copy this tarball to the snapd tree and edit the source in the snapcraft.yaml file under build-aux/snap/ to reference the copied .tar.gz . Next, make sure that the version of libapparmor from the tarball matches the one on cmd/configure.ac under the snapd tree It may be convenient to use the spread tool to provision and run the test suite in an ephemeral vir