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

[John Johansen]

On 09/10/2011 02:33 AM, Rob Meijer wrote:
> Great. What will be the notation for allowing /proc/self without
> allowing /proc/\d+ for anything not pointed to by /proc/self?

Good question, there is a working assumption that we will use a
variable for pid/tid but the design has never been formalized.

We need to lock down the design asap though so we can start updating
policy to use it.  The first pass would just be replacing the
current regex with a variable.
  @{PID]=[0-9]*
or what ever the regex we are currently using, and when kernel
vars support comes online the definition will go away and everything
should just work.

I had been working on the assumption that we would use two variables
@{PID}, @{TID}, or possibly @{pid}, @{tid} this way it becomes
available else where as well if needed.  The proc case would then
be
  /proc/@{PID}/

with that said @{self} would also work for the tid, and we could
do
  /proc/@{self}/
which would make a lot of sense

Rob, jamie, steve, kees, christian what are your thoughts?  So we can
lock it down and begin updating the policy.

> 
> 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?
> 
Hrmm I think I need more information about the 'persistence-id' config
before I can say.  However there is a little more information that may
help you decide.  Along with the kernel vars spec, will come some
generic variables that can be loaded and twiddled from userspace.  So
that some parts of policy can be dynamically updated without having
to recompile and reload the policy.

The variables will have two forms, booleans, and value variables.
The first iteration of value variable will not be allowed to have
regular expressions, though our updated matching engine should be
able to handle that and that may become available in the future.

What hasn't been speced out is the scope of these variables, whether
they are per namespace, per profile or both.


But as to parsing the policy in Python there isn't any good way yet,
I am working on splitting the parser into a parsing library, a
regex library, a compiler, a loader, and the traditional parser
front end, but its been baby steps towards that goal.

I am hoping to have a parsing library split out in the next month
or so.  So that we can begin using it in an update to genprof/logprof
but we will see how that goes, as I don't have a lot of time to put
into it.