[apparmor] Initial thoughts on profiling with signal and ptrace

John Johansen john.johansen at canonical.com
Tue Mar 25 04:05:45 UTC 2014


On 03/24/2014 08:46 PM, Jamie Strandboge wrote:
> On 03/24/2014 08:40 PM, John Johansen wrote:
>> On 03/24/2014 05:58 PM, Jamie Strandboge wrote:
>>

<< snip >>

>> 3 is easy. We "preseed" the variable substitution routine with a hard coded
>> check that returns the current profile name.  That may not be the ideal solution
>> long term but it can be done with just a few lines of code.
>>
>> We just need to setting on what the variable name needs to be.
>>
> It sounds like this was all discussed rather extensively and the current
> behavior is consistent with MAC systems and within itself. That's fine, we can
> address the behavior in documentation.
> 
Hrmm I don't know about settled. It was discussed and the general tone was to
make it explicit and see what it was like, and then re-eval if needed.

The thing with keeping it explicit atm, is that it is always easier to loosen
the behavior than it is to tighten it, if we decide the change is necessary.

> I would like to have us setup the variable though, cause that will make it
> easier for people and especially for libvirt since we can distro-patch the
> libvirt-qemu abstraction to have a rule referencing this variable. Ubuntu can
> then effectively leverage signal mediation for libvirt in 14.04.
> 
Okay, any votes on a name

@{current_profile}
@{profile_name}
@{profile}
@{this}
@{self}
something else?

lower case vs upper case letters?

Note: I would rather avoid @{label} because profile is not necessarily equivalent
to the label. The label is a runtime thing that may be a profile or the dynamic
composition of profiles.




More information about the AppArmor mailing list