On 12/12/2016 11:56, Jean-Marc Lasgouttes wrote:
Le 12/12/2016 à 11:50, Guillaume Munch a écrit :
AppArmor profiles are meant to be based on white lists instead of
black lists. But I agree with you that writing a white list is going to
be complicated,
yes, that was the major issue: whitelisting doesn't seem trivial, but it
may be possible just trying out all the converters we have one by one, and
checking what fails (AA reports any blocked file access, so that can be used
to ascertain whether the current rules are blocking smth or not).
I prefer the white list approach too. I propose for now to have a profile that
whitelists only what is required for the converters we ship with.
sounds reasonable to me, provided we make sufficient testing on a few different
distros/versions, to check whether anything broke.
Note: the current rules say converters can read $HOME/, except where it's
explicitly denied, and anyway they cannot write to it so they cannot screw up
users' contents (e.g., the classical unlikely threat of rm -rf). Reading users
files might be useful if I need, in my gnuplot / R / matematical toolchain
access to data files based on which I'm plotting a graph or outputting a table,
something that can be made to work (AFAIK) by referring to the input file/data
via absolute path in a user's home dir (as the script is always invoked on temp
files in /tmp/lyxtmp.*/...)
If we go for the whitelisting approach, that would mean:
- deny read of any $HOME/.*
- only allow reading of $HOME/.gnuplotrc, etc....
I'm quite sure there will be scripting languages that would try at least to
write a history file a'la .bashrc, and they would complain if they cannot write
it, we need to try them out to see if any issue like that comes out.
Does apparmor allow to extend a white list in a different file? Meaning, can a
user add a separate file to some apparmor.d/ directory to make a particular
converter work?
I just tried to have two profiles in different files applying to the same
executable, and it takes one of them who knows based on what. The behavior
changed when I swapped just the two file names in /etc/apparmor.d/, so these
are not combined/merged, just (I guess) the first or last parsed profile when
doing apparmor restart, will be applied.
I presume that we have no way to have apparmor profiles apply only to
converters marked as needauth, right?
actually, that's possible: for now, the patch applies lyxwrap restrictions to all spawned
converters for enhanced security (e.g., think of maliciously crafted images that let your system
explode when opened/parsed through some buggy library), so it's orthogonal to needauth, but we
could apply restrictions to needauth converters only, or apply different restrictions to needauth
vs regular converters. Other things that can easily be done include applying different profiles for
different things: this can be done simply through multiple wrappers with different executable names
(can even be the same executable with hardlinks), or it could even be done by exploiting the
"child profiles" feature, by which you can catch a process when it's launched as a child
of another process (so that, e.g., ImageMagick "convert" would run with no restrictions
when launched by the user, but it would run under a AA profile when spawned by LyX). Albeit I
didn't try this way yet, it might be a way to even get rid of the lyxwrap launcher.
T.
