[apparmor] Draft proposal for new apparmor virtual file system

[John Johansen]

On 11/04/2010 06:40 PM, Kees Cook wrote:
> 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?
actually it was supposed to be a supported file mask.

It wouldn't hurt to have a stamp or some such file that is basically an auto generated hash of all the other features

> 
>> 		network
>> 		namespaces		# version supported
>> 		capability		# set of capabilities, capability mask???
>> 		rlimits
> 
> These would contain specific limits/masks?
yes, masks or limits as appropriate.  I don't imagine all these entries will exist on the first iteration but they are extra bits we can add, as we can get to them

> 
>> 		change_hat
>> 		change_hatv
>> 		change_profile
>> 		change_onexec
> 
> There would be boolean?
> 
yes I imagine so

>> 	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?
> 
why yes, glad you noticed.  These won't show up right away but are needed if a namespace is to be able to control what resources its children can consume.

>> 		owner
> 
> For uid? This is new also?
> 
Hrmm this was supposed to have some question marks following it.  Basically another potential future entry, when we have user profiles.
Basically it would be the uid and help control who can load profiles to the namespace.  But there are other ways to do this as well so it needs to be explored more.


>> 		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.
> 
right, I am happy with single file as all we support right now is single attachment and even if we support multiple it can be factored to single, or just output multiple entries.

>> 				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.
> 
Right any crypto dependencies would be a config option.  The sha1 or md5 of the profile would be nice to have to quickly verify what was loaded.

>> 				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?
> 
yep.  They are different tables internally, and this is just a raw data dump of the tables.

>> 				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.
> 
generally I think hats is fine I just worry it might confuse people who are using subprofiles and not hats.  They are the same thing with hats just having the hat flag set.  And I think any one advanced enough to be using subprofiles should know the difference but ...

>> 					hat1/			# just like profile
>> 						mode
>> 						....
>> 			profile.unattached/
> 
> What this last thing? Just a random example?
> 
yep.  Just showing how a profile that doesn't specify attachment might show up

> Does it make sense to have "unconfined" show up?
> 
Hrmm, maybe?  This one I am just not sure of

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