Using paths in avrules

CSP provides support for referencing an object by its path instead of type when used in a type enforcement AV rule. This works by matching paths in avrules against a reference policy (by default, the file_contexts from the loaded policy).

Motivation

The motivation for allowing the use of paths in avrules comes from the positive response that AppArmor's profiles received in comparison to the general approach in SELinux policy of referring to the type directly. Hopefully it should reduce the barrier of entry for software developers wishing to write policy for their applications.

Drawbacks and limitations

There are some drawbacks to using paths in avrules. For example, it is unreliable for customizable types. This is an issue that the compiler can make the policy author aware of. However, in some cases the compiler can infer what the type of objects and make a suggestion about the permissions allowed to a particular type. Since referring to types directly is preferred, the compiler will emit a warning about path usage and prompt the policy author to replace paths with their respective types.

Using paths is also limited by the file contexts which are used by the compiler. If a policy author specifies the 2 following path-based avrules:

allow process "/path/to/test/a" files:manage;
allow process "/path/to/test/b" files:read;

When only the following file context specification is available:

file_context "/path/to/test(/.*)?" sys.id:sys.role:sys.type;

Then the compiler will emit an error suggesting that the policy author create more specific file context specifications.

Example

The path syntax is supported both in extended avrules and single avrule statements.

/// A namespace which holds references to executable file
/// types and provides a template for creating new policy
/// modules for executable programs.
namespace program {

    /// A set of object types which are executable files.
    type_attribute executables;

    abstract namespace template {
        type process;
        type entrypoint;
        type_alias subject = process;

        macro create_transition_from(type src) {
            allow src subject process:transition;
            type_transition src entrypoint : process subject;
        }
        
        allow process entrypoint file:entrypoint;
    }
}

namespace system_daemon {

    /// A set of subject types which are system daemon processes.
    type_attribute processes;

    /// A template to be used when writing policy for
    /// system daemons which are started by the init 
    /// process
    abstract namespace template extends process.template {
        processes += subject;
        role_type sys.role subject;
        
        /// The config and data template namespaces
        /// are templates which provide type declarations
        /// and macros for associating avrules with those
        /// types.
        namespace config extends data.config.template;
        namespace data extends data.generic_data.template;
        namespace runtime extends data.runtime.template;
        
        create_transition_from(init.subject);
    }
}

/// An example system service which is started by the init daemon
/// and can only create pidfiles / read its own config / manage its 
/// data.
namespace test_system_daemon extends system_daemon.template {
    file_contexts {
        "/var/lib/test_system_daemon(/.*)?" test_system_daemon.data.context;
        "/etc/test_system_daemon(/.*)?" test_system_daemon.config.context;
        "/var/run/test_system_daemon(/.*)?" test_system_daemon.runtime.context;
    }

    allow process {
        "/var/lib/test_system_daemon" files:common;
        "/etc/test_system_daemon" files:read;
        "/var/run/test_system_daemon" files:common;
    }
}