Security Profile Library for AppArmor

[ruffsl]

Many software projects releasing for Linux ship with included AppArmor profiles to secure their applications at runtime. To enable ROS package developers to succinctly write and maintain similar app policies, I previously wrote an AppArmor library to pre-configure default tuneables and incluable permission abstractions to simplify authored profiles.

I’d like to suggest we package this AppArmor library for release in SROS2; perhaps calling sros_apparmor? This package would mainly serve as a delivery mechanism to install the necessary include files in /etc/apparmor.d/. Downstream ROS2 package developers could cite sros_apparmor as a runtime dependency so that the customer profiles they install to /etc/apparmor.d/ could include the required permission abstractions.

---

Background

AppArmor ("Application Armor") is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths. AppArmor supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control (MAC).
https://wikipedia.org/wiki/AppArmor

I initially started a profile library appstration for AppArmor back with SROS1. However, given the library had to be manually installed, adoption in ROS1 was rather limited:

https://github.com/ros-infrastructure/apparmor_profiles
http://wiki.ros.org/SROS/Tutorials/AppArmorAndROS

Progress

I’ve recently been updating the library for ROS2, and have cpp and python nodes working while under enforced profiles, such as this for the demo node examples shown here:
ros-infrastructure/apparmor_profiles#6

# opt.ros.distro.lib.demo_nodes_cpp
include <tunables/global>
include <tunables/ros>

profile demo_nodes_cpp/talker @{ROS_INSTALL_LIB}/demo_nodes_cpp/talker {
  include <ros/base>
  include <ros/node>
}

profile demo_nodes_cpp/listener @{ROS_INSTALL_LIB}/demo_nodes_cpp/listener {
  include <ros/base>
  include <ros/node>
}

Next steps

Going forward, I’d like to add more permission abstractions for other ROS2 primitives events, like process signal handling between launch tools or allowing shared memory access between nodes, while at the same time auditing the existing policy footprint: to verify which rulesets are truly necessary and where we may want to relax restrictions to generalize for common use case patterns. Iterating further by writing more example profiles for the rest of the ROS2 demos might useful for unearthing any remaining conor cases. I’d apprchate help from folks who may also be familiar either AppArmor debuging or testing advanced ROS2 features.

While rewriting the library, it may also be a good opportunity to re-license the tunables and abstraction files to coincide with the rest of ROS2’s development.

I’d like to eventually host this AppArmor library here with the rest of the sros2 packages, so that downstream users can redaly install it and build on top of it. Perhaps packaging the installer (mostly copying files to /etc/apparmor.d/) using CMake would be enough of a start?

[mikaelarguedas]

That's great!

I’d like to eventually host this AppArmor library here with the rest of the sros2 packages,

That would be good. The only thing to be aware of is that will be a Linux only package in this repo. We'd need to make sure the CMake code checks the platform and skips the package / prints a message if not Linux and that the doc reflects it. We can also host it in a different repo if we don't want to mix platform agnostic vs platform specific packages.

while at the same time auditing the existing policy footprint: to verify which rulesets are truly necessary and where we may want to relax restrictions to generalize for common use case patterns

👍 that auditing will be valuable before recommending it to users

I'll comment directly on ros-infrastructure/apparmor_profiles#6 for the details

[ruffsl]

That would be good. The only thing to be aware of is that will be a Linux only package in this repo. We'd need to make sure the CMake code checks the platform and skips the package / prints a message if not Linux and that the doc reflects it.

Are there any other packages that exemplify switching install behaviors based upon host OS craitera? Or how about installing/removing files outside /opt/ros/<distro>? I'm not sure how this translated when blooming(?) a debian release.

We can also host it in a different repo if we don't want to mix platform agnostic vs platform specific packages.

I have no strong feelings on where such a package is hosted, just that's easily available so that it may be a readable dependency. The idea being that downstream ros2 packages such as rviz, rqt, movit2, etc, could ship AppArmor profiles of their own for end users to start with.

+1 that auditing will be valuable before recommending it to users

I'd like to find some folks from the AppArmor team or Ubuntu who may be more up-to-date on that project, as Its been a while since I've read there docs and wiki (a lot has change and moved around since then).

[mikaelarguedas]

Are there any other packages that exemplify switching install behaviors based upon host OS craitera?

An example of package doing this is rttest

The idea being that downstream ros2 packages such as rviz, rqt, movit2, etc, could ship AppArmor profiles of their own for end users to start with.

In general low level dependencies are in somehow standalone repos to allow downstream repositories to be released early (as bloom acts on a per repo basis). In this case I expect sros2 to be released within ros_core so it's no blocker as it'll always be released early. So IMO it's fine either way 👍