[apparmor] Deprecation of #include

John Johansen john.johansen at canonical.com
Sun Mar 27 22:58:11 UTC 2011


On 03/27/2011 05:33 AM, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 27. März 2011 schrieb John Johansen:
>> On 03/26/2011 03:07 PM, Christian Boltz wrote:
>>> Am Samstag, 26. März 2011 schrieb John Johansen:
>>>> I would like to deprecate #include in favor of using include.
> 
>>>> Further more we may want to consider removing #include altogether
>>>> for v3 of the profile language.
>>>
>>> ... please don't do that. It will break old/existing profiles
>>> without a real need.
>>
>> well the problem is v3 will already break profiles because of
>> semantic changes. For example mount will require both cap mac_admin
>> and a mount rule.
> 
> What's the reason for this?
> My first thought is that the mount rule should be enough, and that it 
> doesn't really make sense to require two rules for one permission. 
> However I'm quite sure you have some good reasons for this change - so 
> please tell me what I'm overlooking ;-)
> 
Its really a limitation of the linux kernel.  Many capabilities are used
to cover multiple operation, and we get no context when these requests
are made.

When the LSM was added to the kernel it was done wrong (IMO).  What we
have now is calls to DAC (independent of the LSM), capabilities which
route through the LSM and then the finer grained LSM hook.

So instead of one security call into the LSM, we get a DAC check,
a call to capabilities and then a call to the LSM hook.  Where if it
had been right there would just be a call to the LSM hook and the hook
would have done DAC and capability.  Thus giving as much control,
and flexibility as possible.  It would also fix the problem we have
right now of only some of the checks being added.

So to add just a mount rule we would have to also implicitly add a
capability rule, because there kernel will make the request for that
capability, but we have no way to separate the capability request
that is made at the same time as the mount request, so implicitly
granting the capability also grants other operations covered by the
capability that may or may not be covered by their own lsm hooks.

So the only clean solution is to expose that both the capability and
the mount rule are needed in the profile.

I'm not happy about it but its what we are stuck with.

For backwards compatibility we did consider ways to have capabilities
map to the new rules.

One solution was to come up with a way to have old policy be forward
compatible.  Eg. Have capabilities map to all the new rules if a
new rule isn't specified.

so capability sys_admin,  would grant a generic mount rule as long
as an explicit mount rule was not specified in the profile.

But that really violates default deny, which is what profile are,
as you would have to explicitly deny mount if you didn't want to
allow it and adding a single rule changes the whole semantic of the
profile.

It just isn't a clean solution.

> That said: There's nothing wrong with changes in the profile syntax if 
> it brings some advantages.
> 
> I'm just saying that you should avoid changes that only bring 
> disadvantages, and removing #include is something I would put into this 
> category.
> 
the well goal isn't to remove include just the preprocessor semantic of
#include.  It may be that replacing #include with include isn't worth
the difficulty, but to me #include implies C preprocessor semantics
and can also be confusing to users as # is also the start of a comment.

>> So the current plan is that v3 profile will need a tag so that the
>> tools can distinguish between them, 
> 
> Yes, version tagging is a very good idea. I would already have loved it 
> when directory rules started requiring the / at the end... ;-)
yeah that was bungled

> (A migration tool that changes the profiles to the new version would 
> have been another option.)
> 
well I think its not so much another option as something that should
be done also.  I also think genprof should be able to do the conversion.

> BTW: I probably won't/can't honor the version tag in apparmor.vim which 
> means that I'll silently allow new rules in old-version profiles, and 
> that I will not mark #include as error for a long time.
> 
right, I realize there are limits to what we can do with the language
and the changes mostly need to be forward compatible at least in syntax

The big driver for v3 format is semantic changes that we can't get
around if we want to offer improved mediation abilities.

>> Of course nothing about v3 is set in stone yet, we are more than
>> willing to listen to ideas about how to extend the profile language
>> and allow for tighter confinement that is backwards compatible and
>> not kludgey.
> 
> Is there a list of all planned changes somewhere (except in your 
> head ;-) and the parts that were posted here)?
> 
Well I don't know that I have them all in my head even :)

There have been several parts posted, here there is stuff in the wiki
in the roadmap, work items and core policy language reference sections.

Some of the changes are at the profile level, many more at the kernel
tools and interface level which I won't cover here beyond saying
faster, smaller, and better access to information).

ipc
- rules governing how profiles can talk to each other, more on this to
  come

Extended rules breaking down the capabilities,
- mount, chroot, setuid, ...

improved variables
- some dynamic kernel side variable @{pid} etc allowing for much tighter
  rules in /proc/ etc.

improved network rules
- you will see more on this soon

delegation
- which covers delegating authority, which will allow for smaller tighter
  profiles, when you choose to use it.  AppArmor actually uses this for
  unconfined processes but has never offered with in a profile

Finer grained file rules
- eg. being able to specify chown at the per file level

Extended conditions
- eg.  owner=(jj smb fred) /foo/bar rw,

User space call out (not really a profile thing but useful to per rule
complain mode)
- this is mostly for learning tools and debugging, so that instead of
  dumping all the initial learning to the logs it can go directly to the
  tool.

Per rule complain
- allowing parts of the profile to be in complain mode instead of all
  of it.

Kill
- allowing rules/profiles to kill tasks instead of just deny

Explicit labeling (Hybrid model)
- this will allow for on disk labeling as directed by the profile, and
  it can be really useful some times.

Further extensions on profile specification

Profile stacking

Better resource control - integration with cgroups, finish missing rlimits


Some of the changes are mandatory because of semantics (ipc, breaking apart
capabilities), others are just pure extension (delegation, finer grained file
rules, better conditionals etc) that can be ignored if you don't want to
use them.

In general I think profiles will only need to be adjusted for ipc, and
capability entries.


Most of the work done lately hasn't been to add new features but to update
the base to be ready for their addition.  A base level of ipc and finer
capabilities has to come soon and together so that we break semantics once,
and then the rest are just extensions that can be added as we can get to
them.



More information about the AppArmor mailing list