[apparmor] [PATCH] aa-easyprof updates, take 2

[Seth Arnold]

On Tue, Jul 09, 2013 at 10:09:00PM -0500, Jamie Strandboge wrote:
> I used 'rk' with --read-path because I thought that was what you guys
> wanted and I thought it was reasonable considering the above and since
> --write-path already had 'k'.

Ah, I figured --write-path would be mostly the application's private
data, and thus relatively small, but --read-path might legitimately be
nearly anything on the system.

> We could add --lock-path, but that is adding more complexity, and to
> what end?  Yes, it is more fine-grained, but if people are going that

Now that I know that --read-path will be the extreme rare end of things,
it feels more appropriate to me to add 'k' to --read-path as well. I was
worried about it being applied to nearly every OS-provided file, or
more..

Of course, someone could do the same with a --lock-path, but since none
of these are allowed in our (tentative) plans for converged device
application confinement, it's not really an issue one way or another.

I'm not sure it's worth the effort to back out the patch, nor am I sure
it's worth the effort to keep it. :)

Up to you.

> > Our problem is different of course, but it did strike me that the
> > parser and kernel interface have one set of constraints on legal
> > profile names, attachment paths, etc., but the json output has
> > different sets of name constraints. We have the hex-encoding
> > mechanism to allow "difficult" characters in attachment paths but
> > those are somewhat specific to the parser and potentially not needed
> > in the json -- but the json representations might need different
> > constraints.
> 
> FYI, I don't really care about the json input-- I figured that is what
> json.loads() is for. If it croaks, we raise an exception. If the
> structure isn't what we expect, we raise an exception. Of course, we
> do other input validation to make sure things are sane for us.

I was more concerned about the json output -- I figured the input could
probably take care of itself, as you've pointed out.

> I was quite strict on profile names because I know that we are quite
> limited on the profile name in terms of what the kernel can use (ie,
> 'profile fθθ {}' is not allowed (along with all the other UTF-8
> characters, so our Asian friends are already out of luck)). I also
> then went quite strict based on click package

Aha, this was news to me, I thought it'd happily do UTF-8, just via hex
encoding representations...

> valid_path() itself is considerably less strict and is expected to
> handle the full gamut of allowed characters in a filename with one
> exception: '"'. You could say I punted on this, but I don't mind
> admitting that-- to support this correctly would take considerable
> work and there are bigger fish to fry atm.  Perhaps I should add it to
> KNOWN BUGS that '"' is not allowed in the path at this time.

Punting makes sense. aa-easyprof is supposed to make life easy. :) No
one puts a " into a filename intentionally -- except for users. I
presume their filenames will be covered with a * or ** and be content.

Maybe even a KNOWN DESIGN LIMITATIONS  :)

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