[apparmor] File rule question

[John Johansen]

On 03/12/2012 12:38 PM, Steve Beattie wrote:
> On Mon, Mar 12, 2012 at 11:38:18AM -0700, John Johansen wrote:

<< snip >>

>>>> instead of having to do
>>>>
>>>>   /** rwlkmix,
>>>>
>>>> the question is should this short cut provide all those permissions or should
>>>> we separate out exec permissions.  It seems odd to me that saying you have
>>>> access to all files means you also can exec anything even if it remains
>>>> confined by the current profile.
>>>
>>> As Seth pointed out, with the exception of setuid/setgid binaries,
>>> it's not a significant extension over 'wm' in terms of abilities. So I
>>> think this is okay.
>>>
>>> I do wonder if Pix would be a more sane default.
>>>
>> I wondered about that myself, and then thought that maybe it should just be
>> separated out so we wouldn't have to figure that out.  Because depending on your
>> situation they could both be sane defaults, and making one the default precludes
>> the other because of x transitions conflicts.
> 
> Hrm. We don't have a way of expressing something globally like "when
> entering profile foo, transition to apparmor namespace bar". If we had
> that, you could make the Pix version emulate the ix version by having a
> forced transition to a namespace that contains no other profiles. But
> that's a technical hack to get around the core issue.
> 
Well hrmmm, stop reading my mind I wasn't ready send that email out yet.
Basically this problem exists on a larger scale and we do need to fix it.

Currently the unconfined profile transitions are defined by profile names
but we don't have any way to indicate the unconfined profile should do
for other potential domain transition points (chroot, pivotroot, ..)

This is why we need to revert the unconfined portion of the make profiles
chroot relative for this cycle.

chroot makes a transition but unconfined has no way of controling whether
that chroot should transition away from the current profile set.

So we do need a way to provide more information globally for profile and
namespace transitions, and switching the namespace when running a certain
executable say chroot is perhaps one way of doing this.

Anyways its something to think about more, and get a separate discussion
going but its not something that can land in the 2.8 time frame

>>   eg.  If ix is the default and I want Pix as the default I can not do
>>   file,
>>   /** Pix,
>>
>> As those will conflict, unless we add some extra sugar to let the compiler that
>> the file ix has a lower precedence.  That is doable but it strikes me as wrong.
>>
>> Of course I have never really liked the mixing of exec and file rules.  And
>> while I recognize that mr and ix are in many ways functionally equivalent. There
>> are reasons that m was added instead of just using ix, so semantically they
>> are a bit different
> 
> It's true that exec rules are different than other kinds of file
> accesses because in large part policy transitions (or lack thereof) are
> derived from the exec rules. I think it's that conflation that's the
> real issue, though I'm not sure how acknowledging that comes up with an
> improved solution here.
> 
yep.

> I could see something gross like allowing an optional mode to the file
> syntactic sugar rule that specifies the default type of x transition to
> use in the rule; i.e. we could decide ix is the default, and then if you
> want Pix or even some crazy cx rule, you'd write:
> 
>   file Pix,
> 
> or whatever. It's not all that semantically different from the mount
> options case.
> 

Hrmm, that works syntactically but not semantically, at least not with how the
other rules work.  When an element is specified that is what it grants/needs to
match
  file Pix,

would be only allowing file operations that do Pix, so no rw etc. And change it
so that in file case you are overriding just the x portion of the permissions
just feels like an inconsistency not worth having.

however we could allow for

  file Pixmrwlk,

and that would be consistent