[apparmor] Draft proposal for new apparmor virtual file system

[Kees Cook]

Hi John,

On Thu, Nov 04, 2010 at 05:41:48PM -0400, John Johansen wrote:
> apparmorfs/
> 	.load
> 	.replace
> 	.remove

I'm fine with these here, but I also wonder if maybe .replace and .remove
should instead live under the target profile itself? (Hmm, I guess not,
since you can do multiple profiles at once.)

> 	features/
> 		file			# can we sneak having a multi entry file listing permissions types in :)

Maybe call it "stamp" or something?

> 		network
> 		namespaces		# version supported
> 		capability		# set of capabilities, capability mask???
> 		rlimits

These would contain specific limits/masks?

> 		change_hat
> 		change_hatv
> 		change_profile
> 		change_onexec

There would be boolean?

> 	policy/
> 		profiles_max
> 		profiles_count
> 		namespaces_max
> 		namespaces_count
> 		memory_max
> 		memory_allocated

Wouldn't this require additional tracking that doesn't currently exist
in the apparmor kernel source?

> 		owner

For uid? This is new also?

> 		namespaces/		#directory of subnamespaces
> 			namespace1/
> 				policy/	#nested policy dir
> 			namespace2/
> 				policy/
> 		profiles/
> 			usr.bin.evince/
> 				mode
> 				flags
> 				is_dynamic
> 				name                            # actual name may be same as attachment pattern
> 				attachment			# /usr/bin/evince   ??? do we need dir for multiple entries

I guess technically they could have linefeeds in them, but if those are
escaped on display, one per line seems good enough.

> 				sha1				# hash of profile

I haven't looked, but will this trigger a dependency on crypto? We're
currently, I think, free of that. Not that I really mind.

> 				size				# how big the profile is
> 				dfa_file			# binary access to loaded file dfa
> 				dfa_network

Why separate? Just based on how they're used internally?

> 				hats/				# could be called profiles again

I prefer "hats", but I'm trying to think if there might be value in calling
it "profiles" for some kind of recursive benefit to userspace parsers. I
think "hats" would lead to less confusion, though.

> 					hat1/			# just like profile
> 						mode
> 						....
> 			profile.unattached/

What this last thing? Just a random example?

Does it make sense to have "unconfined" show up?

I assume all the null-profile profiles would show up in the tree too?

Looks great! Thanks for writing it up.

-Kees

-- 
Kees Cook
Ubuntu Security Team