[apparmor] profile naming and attachment

[John Johansen]

On 11/19/2010 01:13 PM, Steve Beattie wrote:
> On Wed, Nov 17, 2010 at 05:19:17PM -0800, John Johansen wrote:
<< snip >>

>> = multiple attachment specification for profiles =
>> This one has been discussed in the past and I don't believe it is needed
>> anymore.  The idea was to allow a profile to have multiple names.  So it
>> could attach to multiple programs.
>>
>> ie.  /bin/foo /usr/bin/foo {  }
>>
>> however it then introduced the problem of what to do with replacements and
>> removals.  Was the first name the handle that would be used to replace and
>> remove the profile, or would the profile be removed on a per name bases.
>> What if the profile was split in user space and reloaded etc ...
>>
>> With profiles names now allowing pattern matching I believe we have a better
>> solution.  We retain single name behavior and the multiple attachment is
>> handled by the pattern matching.
>>   /{bin/foo,usr/bin/foo} { }
>>
>> combined with the first proposal of allowing profile names separate of the
>> attachment and we get a nice clean profile name to work with and multiple
>> attachment
>>
>>   profile foo /{bin/foo,usr/bin/foo} { }
> 
> I'm okay with supporting this syntax; however, to me it's a less than
> ideal way to enumerate multiple binaries that we want to apply the same
> profile to. I have a vague recollection of you and I discussing a way of
> specifying mappings, though I don't recall any specific syntax. But to
> get the general gist across, something like:
> 
>   map /usr/bin/foo -> profile foo
>   map /bin/foo -> profile foo
> 
>   profile foo { ... }
> 
> Are you no longer interested in supporting this kind of language?
>
Hrmmm, I'm not opposed to it per say, its just has become lower priority
for me as we have a way of specifying it even if it isn't ideal.  I always
thought the multiple profile names directly attached to the profile was
a problematic solution and liked the idea of providing explicit mappings
better.

> (At a meta level, this discussion makes clear to me that what we have
> is an implicit profile for the unconfined state, and our profile
well hrmm, implicit in its creation.  The is actually an explicit unconfined
profile per namespace since karmic.

> definitions are the px permission rules for it. Conceptually, maps
yep.  and ux is a named transition to unconfined

> thus would be cx statements for unconfined. It's interesting to me
> to think about things this way, anyway.)
> 
hrmm no it would be a named transition.  cx is doing the lookup against
the local profiles and hats in the unconfined profile.  Basically every
profile defines its own "local namespace" that cx does its lookup against,
while px always lookups again the profile namespace.

The difference being the visibility of the namespace, with the local profile
namespace, the parent profile namespace is visible where in regular profile
namespaces the parent namespace isn't visible.

>> = conditional profile attachment =
>> The final idea I want to raise is making conditional rules available to profile
>> attachment.  This one is a little further off and needs some more thought.
>>
>> Currently we have the single conditional of file ownership
>> ie.
>>    owner /foo/bar r,
>>
>> and soon it will expand to allow things more like
>>    owner=(jj smb)  /foo/bar r,
>>
>>
>>
>> I think it is worth making this functionality available to profile attachment
>> as well.
>>    eg.
>>      profile confined_user user=guest /bin/bash { }
> 
> (As an aside, I'm glad that you dropped re-using the owner keyword
> in your proposal here, as I think it unnecessarily confuses things.)
> 
ah yeah that was actual a mistake, though you could use owner as well
it just has different semantics.

  owner /foo/bar   asserts that the object uid (oid) == fs(uid)
  owner=(jj smb)   asserts that the object uid (oid) matches one of
                   the values for jj or smb

  user=(jj smb) asserts that euid (need to think about reuid, ..)
                matches one of the values for jj or smb

there are actually multiple conditionals that will be made accessible
to at least some of the rules.  Eg create will be able to be conditional
on the type of file, pipe, fifo etc being created.


>> Thus only attaching the profile for specific users, etc.
>>
>> this could some what replace pam_apparmor but I am not sure at this time
>> that we would want to or what would be the best uses for this functionality.
>> Eg. using pam with the proposed change_onexec extension would allow updating
>>     what users get the confinement without having to reload policy
>>
>> Basically the ability will be present in the enforcement engine its just
>> a matter of where/when we choose to expose it.  Also just because we
>> choose to expose it doesn't mean we have to use it in a given situation.
> 
> I appreciate the desire for flexibility, but I would like to see a
> stronger use case scenario than pam-free systems (though I acknowledge
> they do exist), and I think we have higher priorities.
> 
yep agreed, I just wanted to throw it out there and have some discussion about it
as there is some pam_apparmor work going on right now.