[apparmor] Fwd: environment variables

[John Johansen]

On 11/12/2011 03:37 AM, Tetsuo Handa wrote:
> 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.
> 
ah thanks

> 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.
> 
yeah, this is similar to what we have hashed out so far.  We want the proposed
security context to list acceptable environment variables, and the exec rule
of the current context to be able to provide further screening.  The acceptable
set is the intersection of the two.

> 
> 
>>> 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.
> 
ah right, I wasn't thinking about the copying of the env string you are doing
to a temporary buffer.

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

Yes, at least if you are writing policy without the aid of tools.