[apparmor] File rule question

[John Johansen]

On 03/12/2012 10:58 AM, Steve Beattie wrote:
> On Sat, Mar 10, 2012 at 05:50:38PM -0800, John Johansen wrote:
>> So in 2.8 the ability to specify all files via
>>
>>   file,
> 
> (As an aside, I missed when this syntactic sugar went in, I think. I'd
> actually prefer the syntax to be a little more explicit and add an
> 'all' keyword, e.g. file all, capability all, network all, etc. I
> realize this isn't quite in alignment with how our existing network
> rules work, but they're an intermediate step that we eventually hope
> to replace someday.)

Well the goal with that replacement has been to be compatible with the
current syntax, just extending it.

The syntax in general has been that if a component is not specified
that it means match any.

  network inet stream,  # as specific as the current syntax gets
  network inet,         # any packet type under inet
  network stream,       # any af that is recognized to support stream (inet, inet6, ...)
  network,              # any network type

This same general syntax/semantic has carried over to mount rules, and
with the syntactic sugar patches to file and capability

  mount -> /mntpnt,
  mount type=procfs,
  mount,
  
  file,
  capability,

I can understand wanting the 'all' keyword but at the same time the
current syntax does have a pattern to it that 'all' would break.

If we are to make such a change we would have to do it now, before 2.8
releases, otherwise everything will be using such syntax.  As it is now
we would have to have network rules support both, and we could work
towards updating policy over the next few releases.

I am indifferent to which syntax to use, but there is already a cost to
switching and I am not sure it is worth it.  And I think if it doesn't
happen now it definitely won't be worth doing.

> 
>> 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.

  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