 Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags. |
AppArmor and ROS
Description: This tutorial explains how AppArmor can be used with ROS.Keywords: SROS, AppArmor, Linux Security Module
Tutorial Level: INTERMEDIATE
Next Tutorial: SROS/Tutorials/InstallingAppArmorProfilesForROS
Overview
This tutorial will introduce you AppArmor and how it can be applicable to ROS. First, let us familiarize ourselves with the AppArmor project itself.
What is AppArmor
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). wikipedia.org/wiki/AppArmor
AppArmor is an effective and easy-to-use Linux application security system. AppArmor proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good behavior and preventing even unknown application flaws from being exploited. AppArmor security policies completely define what system resources individual applications can access, and with what privileges. A number of default policies are included with AppArmor, and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours. wiki.apparmor.net
How can AppArmor be used with ROS
As mentioned above, we can leverage AppArmor to protect as well as quarteen ROS process. This helps us to ensure that malicious or dysfunctional nodes are restricted in the degree of disruption they may inflict upon the host systems and fellow nodes.
For example, one may wish to reserve a dedicated bus to specific IMU node type, and would like prevent any other nodes from clobbering the same serial port. In this case we could amend the policy profile for specific node executable as to be only permitted node capable of reading and writing to the reserved device.
The same could also be done for say motor controller devices, networked camera/scanner peripherals, log or audit directories, estop process signals, etc... This can help developers safeguard their robotic subsystems from unexpected behavior or bad actor exploits.
