[apparmor] Any plans for something like @{PROC}/@PID/ or @{PROCSELF} ?

[John Johansen]

On 09/14/2011 02:57 PM, Seth Arnold wrote:
> On Wed, Sep 14, 2011 at 12:53 PM, John Johansen
> <john.johansen at canonical.com> wrote:
>> On 09/14/2011 11:56 AM, Christian Boltz wrote:
> 
>>>>> @{PIDS}=[0-9][0-9]?[0-9]?[0-9]?[0-9]?[0-9]?[0-9]?
>>>>> @{MYPID}= @{PIDS} until @{__KERNEL_PID__} is available
>>>
>>> Sounds like a good way, but are 7-digit PIDs really used out there?
> 
> /proc/sys/kernel/pid_max makes it very easy to change the max pid, we
> might as well support those installations. (Especially since the uglyness
> is hidden in a variable.)
> 
>> Unlikely it sounds like a case for exposing better access to the regex
>> engine.  And doing something more like the pcre re
>>  [0-9]{1,7}
> 
> I wished for that feature for a second :) but it _is_ just syntactic
> sugar. Time feels better spent elsewhere.
> 
err, it is currently but it actually won't necessarily be under the eHFA
which will be able to control for state explosion.  First step will be
kernel vars but the same mechanism will work for counting constraints,
back references, and sub dfas.

>> exactly it really it has to be supported. Beyond the "wait" parts there
>> are all kinds of situations where there is either a mix of old kernel
>> and new policy, or new policy and old kernel.  The system state
>> immediately after an upgrade is just one such case.
> 
> Good point. Should the parser "export" its own variables, reflecting
> kernel capabilities?
> 
> if(__kernel_has_pid_variable__) {
> 	@{MYPID}=@{__KERNEL__PID__}
> } else {
> 	@{MYPID}=@{PIDS}
> }
>
possible or something else

> Any variables the kernel understands can be listed in the
> /sys/kernel/security/apparmor/features file; any
> __kernel_has_foo_variable__ could return false by default (regardless of
> 'foo', to make it easily extensible), but return true when the kernel
> _can_ support the tighter-integration?
> 
> (The long-awaited profile lint could report potentially mispelled
> variables...)
> 
>> two further points.
>> do you want the variable name capitalized?  @{MYPID} vs. @{mypid}
> 
> Hrm. I thought I wanted it capitalized, since @{HOME} feels so natural,
> but we don't need our profiles to be shouty. Either way. :)
> 
>> there is also the whole issue of pid vs tid.  In some cases you want
>> one, and not the other and in others you want both.
> 
> I thought about the tid too, but currently glibc doesn't export a syscall
> for gettid(2), so it doesn't feel very common for a program to generate
> its own tid as a filename anywhere -- it isn't as easy to get as $$ in
> shell or some scripting languages.

except we use it in our own api, aa_getcon, aa_changehat, aa_changeprofile ..