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

[John Johansen]

On 09/14/2011 11:56 AM, Christian Boltz wrote:
> Hello,
> 
> Am Mittwoch, 14. September 2011 schrieb Jamie Strandboge:
>> On Tue, 2011-09-13 at 17:15 -0700, Seth Arnold wrote:
>>> When I read the first proposal here, this was my exact thought; my
>>> initial guess on what to do about it involved _two_ variables:
>>>
>>> @{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?
> 
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'm not convinced about migration issues, as policy currently needs
>> to be changed to use @{MYPID} -- people just have to wait until it
>> is available (I could be missing something).
> 
> I'd say the migration path is needed for people who use new aa-tools 
> and/or new profiles on an old kernel, and doesn't hurt too much.
> 
> Without the migration path, we'll get quite some delay because of 
> dependencies - 1. push into kernel - 2. wait until major distros use 
> this kernel version - 3. update parser (and profiles) - 4. wait until 
> distros update to new parser and profiles.
> 
> With the migration fallback, you can remove the "wait" parts from the 
> previous paragraph.
>
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.

>> Why are we forcing this syntax:
>> @{PROC}/@{MYPID}
>>
>> Instead of just:
>> @{MYPID}
> 
> It's more flexible - @{MYPID} could also be used for something like 
> /tmp/ssh-*/agent.@{MYPID} (that's the socket for ssh-agent, however I'm 
NOT to mention @{MYPID} for /proc doesn't make sense.  Perhaps @{PROCPID}

> not sure if it's really the PID that is used)
> 
most of those types of files really do use the pid and its another
potential use for @{MYPID}

>> I also am not sure of the benefit of @{PROCSELF} since the path is
>> unchanging (ie @{PROC}/self). 
> 
> I'd say @{PROCSELF} is superfluous. 
> Additionally, most programs use @{PROC}/[0-9]*/, only sbin.dhclient uses 
> @{PROC}/self/ according to the profiles in bzr.
> 
well that is because /proc/self is a symlink and apparmor mediates accesses
post symlink.  The only reason /proc/self would show is the application
tried to directly stat, or access the symlink.

so we could is @{SELF} instead of @{MYTID} eg. /proc/@{SELF}

two further points.
do you want the variable name capitalized?  @{MYPID} vs. @{mypid}

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.