[apparmor] RAppArmor: AppArmor for R

[Seth Arnold]

On Mon, Jul 23, 2012 at 2:59 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote:
> Dear AppArmor users/developers,
>
> I am planning on introducing AppArmor to the R community. R is a GNU
> project for statistical computing, widely popular in academia, however
> security is a long standing issue. I wrote an R package containing
> some interfaces to AppArmor [1][2] accompanied by a paper for the
> Journal of Statistical Software [3] introducing some functionality
> that could potentially be useful for R.

> [1] https://github.com/jeroenooms/RAppArmor
> [2] https://github.com/jeroenooms/RAppArmor/raw/master/paper/RAppArmor-manual.pdf
> [3] https://github.com/jeroenooms/RAppArmor/raw/master/paper/document.pdf

Excellent, I'm glad all your work is leading to something that looks
_incredibly useful_.


The only high-level thing that worries me is that aa_change_hat() and
aa_revert_hat() may not be very useful under RAppArmor. Consider
removing them -- or the documentation in the JSS article -- as it
represents significant additional complexity that won't be useful to
most readers. (And may even prove dangerous if misunderstood.)

I see aa_change_hat() being useful IFF you modify R's code
loading/executing to automatically change hat when executing code
provided by CRAN modules to prevent malicious CRAN modules from
scribbling over your data or sending your private data to centralized
servers. Using aa_change_hat() from R code is probably less likely to
be useful as the token must be stored in R-accessible variables...


Some thoughts on the API document:

- You've got e.g. aa_find_mountpoint() and aa_getcon() documented
before the immensely more useful eval.secure(). If this guide is
simply an alphabetical listing of functions, then I suppose it's the
way it ought to be, but I have trouble seeing what use
aa_find_mountpoint() would be to the typical R user. (aa_getcon() is
at least potentially a useful debugging aide...)

- The eval.secure() documentation mentions that the current R session
should not be influenced by the execution, but the RLIMIT_NPROC limits
all processes owned by that user account. Once the "child" process is
done, the limit is _still_ in place. I'm not sure if this is Good or
Bad; it just Is, and I believe it should be documented both in the
eval.secure() function and the more specific rlimit_nproc() function.

- The rlimit_memlock() description should probably point out that
"locked" memory is really intended for use for keys or passwords or
other secrets that should not be saved to disk via swap; it isn't
intended as a general "optimization" mechanism. (Does R expose
mlock(2) or similar interfaces for user programs? Or would it only be
useful from C- or C++-based modules? (Or FORTRAN??))

- rlimit_nice() would sure be nice to have an example; the "20 -
limit" is a bit awkward -- and I'm curious what it does for the
current 'nice' value if the limits are set such that the current value
is illegal. (From what I can read of the kernel code, it leaves the
current 'nice' value alone; it looks like this rlimit only influences
the nice(2) and setpriority(2) calls.

- The setuid() interface is very sparse; the documentation mentions a
way to get the current id, but 'getuid()' isn't documented here.
You'll probably also want wrappers for seteuid(2), setreuid(2),
setresuid(2); setegid(2), setregid(2), setresgid(2); setgroups(2),
getgroups(2); and the Linux-specific setfsuid(2) and getfsuid(2).
(Maybe including all these is asking for more trouble than it is
worth?)

- eval.secure() probably _also_ needs some way to manage the
supplementary groups; some security problems have come about because
child processes had supplementary groups across an exec() that they
should not have had. This could be a huge annoyance, but some
mechanism to at least clear all existing supplementary groups might be
most useful. (Of course, someone building an R application server will
need to think this through carefully, same as anything else.)


Some thoughts on the JSS paper:

I've attached a git diff of some of the changes I suggest making to
the JSS paper; most are pretty small and hopefully self-explanatory.
I've trimmed the profiles slightly to remove redundant rules (such as
/etc/resolv.conf -- covered via <abstractions/nameservice>; and
/usr/share/ca-certificates/** r, -- covered via the previous
/usr/share/** r, line.)

Do note that @HOME does not expand to /home/jeroen/ -- it expands
to_all_ user's home directories (yes, even /root/). I don't know if
this detail is important enough to document here, but it is an
important detail. If you want to ensure your users cannot share data
or code via /home/foo/R/ then you should also include the 'owner' rule
prefix.

I've made _some_ changes for \proglang{Java}, etc. but I tired of this
and thought it'd be better to just mention that some standardization
would be ideal. Even making new commands \Java for \proglang{Java}, \R
for \proglang{R}, etc., would go a long way to getting them all
correct. (But sometimes R is a language specification and sometimes it
is a specific executable tool. Does it matter which is which?)

Thanks again, this looks fantastic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: document.diff
Type: application/octet-stream
Size: 18093 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20120723/20dc4b23/attachment-0001.obj>