[apparmor] [PATCH 0/12] Move aa_{match, features, kernel_interface, policy_cache} APIs

Tyler Hicks tyhicks at canonical.com
Fri Dec 12 20:39:15 UTC 2014


On 2014-12-12 11:25:12, Seth Arnold wrote:
> On Wed, Dec 10, 2014 at 04:12:21PM -0600, Tyler Hicks wrote:
> > This set of patches moves the previously proposed[1] APIs to
> > libapparmor. It feels a little like jumping the gun since the proposed
> 
> > 	if (aa_policy_cache_new(&policy_cache, features,
> > 				"/etc/apparmor.d/cache", false) == -1) {
> > 		perror("Failed to find a valid AppArmor policy cache");
> > 		goto out;
> > 	}
> > 
> > 	if (aa_policy_cache_replace_all(policy_cache, NULL) == -1) {
> > 		perror("Failed to reload cached AppArmor policies");
> > 		goto out;
> > 	}
> 
> With the recent-ish move to multiple profile caches (at least on Ubuntu)
> for different purposes, I'm curious how these caches will interact with
> each other when using this library. One thing our init script has done in
> the past is remove profiles from the kernel when their corresponding
> source files have been deleted from the source directories.
> 
> I suspect that mechanism is no longer a good idea for the library (or
> initscript); I'm curious if there are similar issues.
> 
> I haven't looked through the API enough yet to ask intelligent questions,
> but I wanted to make sure I didn't forget entirely...

That's a good thought.

An aa_policy_cache object is specific to a single cache directory. You
have to pass in the cache directory when calling aa_policy_cache_new().
So, to adapt the above example to what we would need in Ubuntu, it would
look something like this:

aa_features_new_from_kernel(&features);

aa_policy_cache_new(&etc_policy_cache, features,
		    "/etc/apparmor.d/cache", false);
aa_policy_cache_replace_all(etc_policy_cache, NULL);

aa_policy_cache_new(&var_policy_cache, features,
		    "/var/cache/apparmor", false);
aa_policy_cache_replace_all(var_policy_cache, NULL);

aa_policy_cache_unref(var_policy_cache);
aa_policy_cache_unref(etc_policy_cache);
aa_features_unref(features);

In theory, there should be no problem creating multiple aa_policy_cache
items for each policy cache.

What I haven't given much thought to is concurrent operations on a
single object, whether that object is an aa_features, aa_policy_cache,
or aa_kernel_interface. Internal locking may be something that we want
to add soon.

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20141212/1745208f/attachment.pgp>


More information about the AppArmor mailing list