Tetsuo Handa
from-****@I-lov*****
Fri Dec 24 23:02:04 JST 2010
Jamie Nguyen wrote: > I would just like to check my understanding of both TOMOYO and uuid module. Welcome. > At the moment, TOMOYO is able to restrict access to /proc as long as > the process does not need to communicate with other processes. Thus, > it can be limited with something like: > > file execute proc:/self/exe > file read proc:/self/\* Yes. That's why TOMOYO provides special handling for /proc/self/ case. > However, if a process needs to communicate with other (e.g. child) > processes, then this policy must be specified: > > file read proc:/\$/\* path1.uid!=0 > > This therefore gives it read access to /proc files as long as they are > not owned by root. I am not sure in this case how to allow (when using > just TOMOYO) to read /proc files only with uid of the current process. file read proc:/\$/\* path1.uid=task.uid or file read proc:/\$/\* task.uid=path1.uid > uuid module provides a method to limit access to /proc (and ptrace, > kill etc.) which is controlled by writing uuid to /proc/uuid . Yes. Especially for limiting communication with other processes running with the same uid. > I'm not familiar with using libvirt, but I think if my understanding > is correct, chromium browser might be a suitable candidate for the > uuid module. Currently, chromium is designed to sandbox as much as > possible. Each tab is run in it's own process. The domain sequence is: > /usr/bin/chromium (launcher script) > /usr/lib/chromium/chromium (core browser) > /usr/lib/chromium/chromium-sandbox (sandbox) > /usr/lib/chromium/chromium (process for each tab) > I have specified in exception policy: > initialize_domain /usr/bin/chromium > keep_domain any from <kernel> /usr/bin/chromium OK. > chromium-sandbox requests read/write access to /proc/self/oom_adj as > well as /proc/XXXX where XXXX is pid of each of the > /usr/lib/chromium/chromium processes. Thus, I need to specify the > following in domain policy: > > file write proc:/\$/oom_adj path1.uid=0 I see. > (the other option is to grant specific pid in real time using ccs-queryd). Yes, that will also be possible. > chromium does not need capability SYS_PTRACE so this is protected > against by TOMOYO (I assume libvirt requires this capability and so > requires uuid module). The reason I designed uuid module is that libvirtd launches all qemu-kvm processes with the same uid. This means that if one of qemu-kvm processes was hijacked, all other qemu-kvm processes will be attacked as well. In the enterprise world, people tend to run multiple qemu-kvm processes on a single machine and therefore they want to isolate each qemu-kvm processes. > However, the above policy allows access to > oom_adj of all processes not owned by root. uuid module would > therefore allow this access to be limited to only chromium processes > if the launch script is modified to add uuid to /proc/uuid before each > chromium process is run. Yes. By entering into uuid jail, chromium processes will not be able to access other process's information. > I have a feeling that my understanding is a little fuzzy here, and I > may not be using TOMOYO correctly. Is my understanding somewhere close > to reality? Yes. How powerful user you are!
TOMOYO
Fork