[apparmor] Fwd: environment variables

[Tetsuo Handa]

John Johansen wrote:
> >> A dumb extension of secure exec does not seem to be a viable solution
> >> either, as some environment variables need to be set for applications
> >> to work, eg. the dbus session bus address, and yet we would like to be
> >> able to control the value or range of values a variable could have.
> > 
> > Although TOMOYO provides ability to check combination of environment variables
> > (i.e. AND logic) like
> > 
> >   file execute /path/to/program exec.envp["PATH"]="/sbin:/bin:/usr/bin" exec.envp["TERM"]="linux"
> > 
> I assume by and logic, here you me both the execute path and the environment
> variable TERM="linux" correct (sorry I need to reread the tomoyo documentation).

Above example allows execve("/path/to/program", argv, envp) only when envp
includes "PATH=/sbin:/bin:/usr/bin" and "TERM=linux" entries.

TOMOYO's environment variable check consists with two steps. First step is
checked with current security context (security context that is used for
execve() request). Second step is checked with proposed security context
(security context that will be used if execve() succeeded). This is because
I considered that environment variables that should be acceptable to the new
program should be listed from the point of view of the new program.

The first step

  file execute

is blacklisting (i.e. checks only environment variables that are listed within
the line, and causes denial of execve() request if listed environment variables
did not match).

The second step

  misc env

is whitelisting (i.e. causes denial of execve() request if environment
variables that did not match "misc env" are found).

By splitting into two steps, policy writers can enumerate list of programs that
should be allowed to be passed to execve() request, without worrying
possibility of dangerous environment variables.



> > The complexity of these combination may exceed what in-kernel logic can handle.
> > Therefore, TOMOYO 1.8 also provides execute handler (in short, EH).
> > 
> I am curious on this, is it because its more rules than you want to load into
> the kernel or is there a different limitation.  Not that using an EH might not
> be the better solution when doing complicated comparisons.

This is mainly for dealing with its difficulty of allocating continuous memory
in the kernel space.

While argv[] and envp[] are '\0'-terminated array of string until
copy_strings_kernel(), argv[] and envp[] are stored into PAGE_SIZE'd memory
blocks when LSM hooks receive "struct linux_binprm" for checking environment
variables. Unfortunately, PAGE_SIZE'd memory blocks are not continuous.
This means that you can't access envp[i] as a '\0'-terminated string without
temporarily allocating kernel memory and copy. At this point, kmalloc() (or
even vmalloc()) can fail if envp[i] is very very long.

Therefore, TOMOYO only checks up to first 4000 bytes for each argv[]/envp[]
entry. TOMOYO asks policy writers to use execute handler if they want to check
argv[]/envp[] entry longer than 4000 bytes.

By borrowing userland program's help, we can audit/add/modify/remove
argv[]/envp[] easily (and moreover (e.g.) manipulating /proc/self/fd/ entries
is possible) without worrying memory allocation failure in the kernel space.



> >     How does AppArmor represent non-printable characters in the policy
> >     configuration? I guess AppArmor does something like "\ooo for representing
> >     non-printable characters".
> > 
> yeah we provide for \x00 and \000 escaping

OK.

> >     How does AppArmor represent literal * character in the policy configuration?
> >     I guess AppArmor does something like "use \\ for representing literal \
> >     character" and "use \* for representing literal * character".
> > 
> yes

OK. Then, the problem for me is that I must learn all characters that will be
interpreted as wildcards before writing policy.