On 08/06/2017 05:32 PM, intrigeri wrote: > Moritz Mühlenhoff: >> If one of those profiles relies on features which are not upstreamed >> on the kernel end, how's that handled? > > Rules that are not supported by the running kernel are silently > ignored, i.e. the operation is allowed.
Is there at least a warning during the load of the profile? Consider a local sysadmin that creates an own profile for a specific service they run - and assume that AppArmor will confine it. But because the kernel doesn't support a specific thing yet the confinement will be incomplete. Which is probably better than not having AppArmor, and is probably also OK for profiles shipped with the distribution and / or upstream software - but not necessarily a good idea for something an admin touches themselves. Or, conversely, is there a possibility to add a flag to the AppArmor profile to say "fail to load it if something is not understood"? In that case all profiles shipped by Debian would not include that (for interoperability reasons) but it could be documented that as a best practice for admins they should use that flag so that they can be sure that all protections they specified are actually affected. Another thing to consider: if a profile is too restrictive, but the part that is too restrictive isn't in the upstream kernel yet, then things could break if you upgrade the kernel to a newer version from e.g. backports later on. How would you deal with that kind of breakage during the lifetime of a stable release? Regards, Christian
