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

[Rob Meijer]

Great. What will be the notation for allowing /proc/self without
allowing /proc/\d+ for anything not pointed to by /proc/self?

I've just started my first baby steps with the MinorFs rewrite on
github (https://github.com/pibara/MinorFs2).

An other question: I'm seriously thinking of piggybacking the
'persistence-id' dbus service configuration on the AppArmor profiles.
That is, adding specially formatted config lines inside of profile
definitions. Would this be a good idea? If it is, do you have any
pointers with respect to processing and parsing all the AppArmor
profiles from Python?


Tnx,

Rob

2011/9/6 John Johansen <john.johansen at canonical.com>:
> 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.
>