[apparmor] apparmor query interface spec and changes

[John Johansen]

On 02/09/2015 05:44 AM, Christian Boltz wrote:
> Hello,
> 
> I have some feedback and questions before the meeting tomorrow ;-)
> 
> Am Freitag, 6. Februar 2015 schrieb John Johansen:
>> Anyways profiles in the unconfined mode show up as
>>   profile (unconfined)
>>
>> while the current behavior of the unconfined profile, which is the
>> standard default profile remains as
>>   unconfined
> 
> Can both ways (one process in state "foo (unconfined)" and another one 
> just "unconfined") exist at the same time on a system? Or will programs 
> executed with an Ux rule also get "foo (unconfined)"?
> 
That is a good question. I believe the consensus was that ux becomes
the default transition, and we may want to move away from ux to
a more appropriate naming scheme.

The idea behind the default profile is to allow for easier total
system confinement, and allowing somethings to escape into unconfined
is problematic.

Of course we also have that problem with policy.

Currently the unconfined profile name is used, and there is a special
mapping of anything in unconfined mode into this for policy purposes.
I think this is something that is going to have to change as well

>> this was done for backwards compatibility with tools but could be
>> changed for consistency unconfined (unconfined)
> 
> Well, for real backwards compability, having just "unconfined" would be 
> even better ;-)
>  
right, that is the current state which was done for backwards compatibility

the question was do we want to change it to
  unconfined (unconfined)

to be consistent with everything else having a mode

>> I don't think there is really a need, unless anyone objects, we just
>> need to make sure the tools are updated to handle the new unconfined
>> mode.
> 
> Right.
> 
> BTW: Do you know of external tools that read the proc interface (and 
> could possibly break)?
> 
I know the lxc stuff has been poking at it directly, and there are a few
other things that have as well. Whether they still are, I am not sure

>> we could report the full mode names but that would result in longer
>> mode strings, leaving less remove for the profile names, and actually
>> require more work to update the parsing of our userspace tools.
>> Keeping it short also has benefits for none apparmor specific tools
>> (eg. ps -Z)
> 
> Agreed, the short mode is better for various reasons and also easier to 
> parse.
> 
>> the third issue to make sure we nail down is around namespace
>> visibility. With stacking it becomes possible to have profiles from
>> different namespaces confining a task simultaneously. For example the
>> host might want to limit what an lxc container can access, and the
>> lxc container being run as a virtual OS may have its own policy on
>> the processes that are running.  So for a host using the confinelxc
>> profile on lxc, and an lxc process running apache inside a policy
>> namespace of containerA, when queried from the host we could have
>> something like
>>    confinelxc//&:containerA://apache (EE)
>> and when queried from in the container, only
>>    apache (enforce)
>>
>> that is the interface is virtualized along the namespace hierarchy, a
>> task can only see anything at or below its current namespace. The
>> question is, is this the default that we want for the proc interface
>> or should it only report the profiles from the current namespace? ie.
>> for the above example, either
>>      confinelxc (enforce)
>>    or
>>      apache (enforce)
>> dependent on who does the querying
> 
> In the interest of backwards compability, I'd vote to only report the 
> profile from the current namespace in the proc interface.
> 
I wouldn't really call it a backwards compatibility issue. Today's
situation is a single level stack, and most no one has seen otherwise
because they just haven't used the feature.

Note that even if we go single NS visible that doesn't prevent a
stack of profiles showing up on the interface, because it is possible
to stack profiles within the NS.

>> If we decide to make the proc interface show only the current
>> namespace profiles we would need to add to the apparmorfs interface a
>> way to query the hierarchy, as it does have its uses.
> 
> Yes. The good thing is that we can do everything we need without 
> breaking something, because that will be a new interface.
> 
> BTW: Will/should the "child" namespace be able to get information about 
> its parent, or should only the "parent" know about the child? 
> (I'm wondering if allowing to see the child that it's running inside 
> lxc/$whatever brings any security concerns.)
> 
The child theoretically* does not know about its parent. When a task
is inside the child it is virtualized and believes it is the root NS.

The parent however has a full view of its children, and can restrict
the number and size of profiles, seed the namespace with profiles, or
even destroy it.

*This is of course only theoretical atm because there are information
sources that have not been properly virtualized (eg. the audit log).


>> Now to the writable end
>> currently apparmor uses all potential character including embedded
>> \000 characters as part of its interface, ideally we don't want to
>> change this (for backwards compatibility reasons) but if it becomes
>> necessary so there can be better unified LSM interfaces we need to
>> start pondering what could be done. I don't have any specific issues
>> or recommendations, I just want to point it out as a potential issue
>> and that you might want to look into the LSM discussion (mentioned
>> above)
> 
> As long as the interface understands the "old" \000 and the "new" way 
> (however that looks), I don't see a real compability problem. We "just" 
> need to extend the AppArmor code so that it understands both, and that 
> the "new" way is easily distinguishable from the "old" way.
> 
Well, we can do that. The point being we may loose the old way so that
the LSM interface can be common. Whether that means carrying a compat
patch, or Kconfig, or what I don't know.

At the moment nothing is decided, it is just trying to suss out the
options as there is some discussion happening now.