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

[John Johansen]

-----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).

The current alternative is to replace the interpreter with a wrapper
that handles the command line parsing, and uses
change_hat/change_profile to set up the correct profile and then
calls the actual interpreter.  We don't do this currently but it is
possible.

> 2) MinorFs will also need a simple profile for executables. This
>    profile simply defines if the the processes for a given executable
>    path get private storage or not. It would be great if I could simply
>    piggyback this information on the AppArmor profiles. Are there, any
>    constructs that would allow me to do so?
> 
I am not sure I understand the question?  Are you asking for a way to
see if the profile provides private storage.  Or a way to specifying
if a profile transitions to private storage.

an app can look at the profile on a process throught the
/proc/<pid>/attr/current file.  There isn't currently a way to
introspect the loaded policy but with the up coming AppArmor 2.3
release you can use profile namespaces to provide and annotation.

you could set up two sets of policy, private_storage and default (the
standard profile namespace as seen currently).

eg. proc confined by default namespace policy
> cat /proc/123/attr/current
/usr/bin/myscript

eg. proc confined by private_storage policy
> cat /proc/456/attr/current
private_storage:/usr/bin/myscript


As for other constructs, I am not sure.  It would be easy to include
extra information in a profile through includes and variables.  And
with AppArmor 2_3 there is a very basic in kernel conditional rules
based on uid.

If these aren't sufficient what kind of constructs are you looking
for?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHsOM/i/GH5xuqKCcRAm/cAKClbaS8Oa++HUcIliv8w7QZC7Ot+ACffw3f
UAgnOMmSGz/nI4p+9nHix9w=
=rf8A
-----END PGP SIGNATURE-----