[apparmor] environment variables

[John Johansen]

On 11/09/2011 04:25 PM, Seth Arnold wrote:
> 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.
> 
Right, I think generally we can get away with pattern matching on env
vars, where the args I am just not so sure of.  If we can get an env
var solution that is acceptable then we can start looking at the args.

> Our discussion about _filtering_ vs _forcing_ environment variables is an
> awful lot like the POSIX.1e draft capabilities support -- the capabilities
Oh dear $*! no, the complexity, my eyes!, my brain!  ...

> 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.
> 
true enough

> 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.)
> 
ugh, now you are talking about tracking and mediating unconfined to some
degree.

> 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
yes, and so are profiles in general

> 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).
> 
hrmm, not so much, at least not unless kernel vars are being used.  Its
more static, it would be more like each rule (way of invoking) is a hardlink
to the executable and you could store setcap per hardlink

> 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
hence the above comment when you mention the .1e draft :)

> desired different aspects of how environment variables could be mediated
> that we've nearly covered all the capabilities semantics.
> 
possibly, but hopefully we can come up with something at least a little
cleaner.

> (And we decided that AppArmor _forcing_ capabilities is more likely to lead
> to trouble than help any admin...)
> 
well yes and no.  It was more of a this is problematic and we need to be
very careful with it.  It has to be full developed and evaluated first.
We don't have time for that right now, so drop it.

There are still places it could be useful, but atm its not worth the risk

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

Right, that was my initial reaction, I couldn't see doing the filtering
kernel side going upstream.  However filtering does appear to be a better
solution than just matching.  I also don't see keeping it siloed in
apparmor being much different to the rest of the kernel than sticking it
in a binfmt_misc handler.

So the worst that can happen is we try and they say no, and we revise and
try again, or choose an alternate approach like using binfmt_misc

The problem is that I don't see doing it in user space as viable, unless
you can guarantee every binary is linked against your modified loader.
Actually I have thought of implementations where the kernel modifies what
loader is used to guarantee that but uh, that seems worse than just
filtering the environment variables directly

> 
> If the tool is written correctly it could even have a usefulness outside
> of AppArmor. It'd involve some compromises (like having AppArmor emit
yep

> policy language for the other tool rather than controlling it directly),
yep

> 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.
It could be, a lot of it comes down to the implementation.  If its just
filtering its a little less useful than say filter/set/modify. Obviously
I am thinking of using regexs, which means I would like to use our regex
engine for a fast match.

At which point it becomes a question of is that acceptable for other
lsms.  Are they going to want to compile the regexs in userspace and
load them as part of the policy?  If not what would be acceptable for
them.  Get it too abstract and we are back to the lsm hook we have
now, so there is no point.

I am not opposed to making our matching engine more generic, but it
certainly needs more work both in both user and kernel space, and
I doubt that others will want it.