[apparmor] environment variables

Seth Arnold seth.arnold at gmail.com
Thu Nov 10 00:25:10 UTC 2011


I've wanted something like environment filtering for ages but have trouble
seeing how an implementation would be upstreamed. But, that aside, a few
thoughts:

> certainly but argv filtering is something that can be considered
> separately from env filtering.

On the one hand, they are nearly identical -- methods of passing
information (whether benign or malicious) to a new process. On the other
hand, environment variables follow enough rules that it is far easier
to talk about them.

Our discussion about _filtering_ vs _forcing_ environment variables is an
awful lot like the POSIX.1e draft capabilities support -- the capabilities
are more obviously powerful than environment variables but both grant a
certain amount of power to a new child that it might not have expected --
and the admin might not like.

Do all three of effective, permitted, and inheritable make sense with
environment variables? I think so; at least, I can imagine that we might
want to force a specific environment variable (effective), we might want
to allow a specific environment variable if its value (or colon-separated
sub-values) meet some requirements, and that we might want to allow
an environment variable to be passed to a child process, but not _its_
children. (This is the weakest one in my mind -- but perhaps you want to
limit SSH_AUTH_SOCK to the immediate Ux program but none of its children.)

If the environment variable policy is stored in the profile it is an
awful lot like the setcap(8)/cap_set_file(3) file capabilities. If the
environment variable policy is related to the execution line of a calling
profile is an awful lot like handling the 'inheritable' capabilities
set on execve(2).

The complexity of the POSIX.1e draft capabilities is much maligned so
perhaps this isn't the best starting point -- but it feels like we've
desired different aspects of how environment variables could be mediated
that we've nearly covered all the capabilities semantics.

(And we decided that AppArmor _forcing_ capabilities is more likely to lead
to trouble than help any admin...)

> Right, just trying to reiterate the objection to it, secure exec relies on
> the loader implementing it so it seems broken by design to me.

I have to admit that I'm skeptical of a kernel implementation ever being
mainlined. Perhaps a new binfmt_misc handler could work? It does require
some more effort (mounting the binfmt_misc filesystem during early boot)
but does keep all the logic out of the kernel while still keeping a
trusted execution environment.

If the tool is written correctly it could even have a usefulness outside
of AppArmor. It'd involve some compromises (like having AppArmor emit
policy language for the other tool rather than controlling it directly),
but I think it'd be feasible enough to write a generic tool that
knows how to filter / set / modify environment variables when given a
from_domain and to_domain in a manner that would be useful to the other
LSM implementations.



More information about the AppArmor mailing list