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

[John Johansen]

On 09/06/2011 12:24 AM, Rob Meijer wrote:
> I've just started with the design for a rewrite of MinorFs that aims
> to be multi granular. My (still fluid) thoughts on MinorFs2:
> 
> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2
> 
> One of my main thoughts is to isolate the determination of a
> 'persistence-id' in a dbus service running as root, in such a way that
> this may in term eventually move to kernel space. I'm also in this
> same line looking at piggy-backing that part of the MinorFs
> configuration
> into AppArmor profiles.
> 
> One issue with the old AppArmor/MinorFs combination seems to remain
> still is the fact that also the new MinorFs2 as I envision it
> will rely on the proc sub dir pointed to by /proc/self being process
> private. The most trivial way this could be enabled would be for
> AppArmor profiles to support a notation like @{PROC}/@PID/  or
> @{PROCSELF} in its profiles. Is such a thing still anywhere on
> the road map? If not, is there any other way of allowing a profile to
> mark a process its /proc/$PID as private that is planed for any
> future version of AppArmor?
> 
Hey Rob,

yes this is still on the roadmap and there has actually been a fair bit
of work put into supporting this, it is just not completed yet.  It will
require an updated kernel and userspace but old policy using supported
variables, which are currently defined by a regex, will just work.

I am hoping to finish up the work on this for the next release after
the coming 2.7 release

Another point of interest is that there has been work to patch dbus
to cooperate with apparmor so that if you have a dbus with apparmor
support you will be able to control dbus messages within policy.

I should be able to get the experimental version of this up either
this week or at the latest next when I get back from plumbers conf.

Also coming down the pipe, but not as far along, is an Xace plugin
for controlling X.