[apparmor] Apparmor rules for dconf confinement

[Seth Arnold]

On Wed, May 27, 2015 at 01:22:16PM -0400, William Hua wrote:
> We need to make some small changes to the Ubuntu kernel for this due
> to the internal workings of dconf. When the application starts, dconf
> needs to know on the full list of readable/read-writable paths, so the
> aa_query_label() function and its kernel implementation don't quite
> fulfil this need.

Thanks for working on this; I'm going to limit feedback to just what I see
here, on the assumption that the overall design has been discussed to
John's satisfaction.

>  /* fn's in lib */
>  char *aa_split_fqname(char *args, char **ns_name);
> -char *aa_splitn_fqname(char *fqname, size_t n, char **ns_name, size_t *ns_len);
> +const char *aa_splitn_fqname(const char *fqname, size_t n,
> +			     const char **ns_name, size_t *ns_len);
>  void aa_info_message(const char *str);
>  void *__aa_kvmalloc(size_t size, gfp_t flags);

I think this would be easier to review if the const modifications had
been prepared separately. It may need to be separated for upstream kernel
inclusion, if that is our end goal.

> +struct aa_paths {
> +	size_t n;
> +	char **p;
> +};
> +
> +struct aa_dconf {
> +	struct aa_paths r;
> +	struct aa_paths rw;
> +	struct aa_paths ar;
> +	struct aa_paths arw;
> +};

This feels like a lot of memory allocations through the general purpose
memory allocator; if the kernel doesn't actually interpret these in any
way, and there are no plans to do so, would it make more sense to just
pass in a text blob for the kernel to hand back to userspace when
requested? That could reduce dozens of memory allocations per profile
down to the four access types.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20150527/6584d592/attachment.pgp>