[Apparmor-dev] AppArmor and interpreters, AppArmor and config namespaces?

[Rob Meijer]

On Tue, February 12, 2008 01:07, John Johansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rob Meijer wrote:
>> I am currently working on a fuse based project (MinorFs), that should
>> implement some object cap like functionality for filesystem access using
>> password capabilities and private views. I would like MinorFs (to be
>> able
>> to) work as closely as possible together with AppArmor.
>> I have two questions with respect to this:
>>
>> 1) In MinorFs, a fuse based tool run as an unpriviledged user I parse
>>    /proc/<$PID>/maps in order to determine what executable is running.
>>    For normal executables this works fine, and now after some tweaking
>>    the mono stuff also works ok. However for java, perl, shell etc,
>>    I end up with the interpreter instead of the interpreted.
>>    Given that AppArmor solves this, is it possible to supply this
>>    information (mapping pids to the relevant executable, even
>>    if this is an interpreted executable like a perl script) to
>>    user space tools like MinorFs.
>>
> It only partial solves this problem, it bases the profile attachment
> based off of the specified executable name, before the kernel loader
> determines whether it needs an interpreter or not, so essentially
> argv[0] but before the application runs.
>
> so if a script is invoked by name
>> myscript
>
> the attachment is correct but if the script is launched through the
> interpreter
>> bash myscript
>
> the attachment will be the bash profile
>
> It is possible to parse the command line and figure out a different
> attachment, but that isn't the type of code I would want to put in the
> kernel, as it has to be per interpreter and it might be raceable
> (I would have to look at it a lot closer).  The other problem with
> basing policy off of parsing the arg vector is you need different
> parsers per interpreter, something I would rather do in user space
> (perhaps when/if we put in the hooks to call out to a user space
> daemon).
>

I've been looking into solving it all user space (within the user space
file system for starters) parsing information from the /proc/<PID>/cmdline
and /proc/<PID>/environ, and at first it appeared doable.
A major problem with doing it purely user space however is that the
process may change its relevant environment before the userspace process
gets to it. The same problem is there I believe for the command line
arguments.

For me the time window is currently a bit bigger than need be, as
the timewindow process creation -> filesystem access may be very large,
but even with a dedicated process, while minimizing the timewindow, there
does seem to be a problem with a userspace process simply parsing
commandline and enviroment using the /proc/<PID>/environ etc.

Wouldn't it be somehow possible to provide a 'startup time' snapshot of
cmdline and environ to a userspace daemon? Maybe using some kind of named
pipe mechanism?
If you feel this would be the right track, I could start by creating a 3
daemon approach,
1) one daemon polling /proc and filling the pipe
2) one daemon reading the pipe parsing the commandline and enviroment
   and reporting to 3.
3) A simple UDP server keeping a map of pid -> exe/script/java-ap etc.

MinorFs could than consult 3, and 2 could also report to AppArmor. In
future releases of AppArmor you could than replace 1 with a kernel level
solution
(getting rid of the race condition problems for environ and cmdline) and
make use of the information from 2. Possibly 3 could also be droped in
term,
so that MinorFs would consult AppArmor.

Let me know what you think.

Rob Meijer