Tetsuo Handa
from-****@I-lov*****
Wed Jun 8 10:10:43 JST 2011
TOMOYO
ForkTetsuo Handa wrote:
> Horvath Andras wrote:
> > What i'm trying to do is to create rules for an already running
> > process, but i'd like to transit it from its original domain to a new
> > domain on-the-fly if possible.
> >
> > Let's say i have a domain like this:
> >
> > <kernel> /sbin/init /bin/bash /bin/myprog
> > use_profile 0
> >
> > I'd like to have a domain like this by formerly specifying
> > "initialize_domain /bin/myprog" in exception_policy, then in
> > domain_policy:
> >
> > <kernel> /bin/myprog
> > use_profile 1
> >
> > I know that after creating this domain, the process will start in this
> > domain if i restart the process. My question is, is there a way to avoid
> > to have to restart the process to have my new domain? Is there a
> > possibility to transform it from the old domain to the new domain
> > on-the-fly?
>
> Currently there is no way to do so.
>
But speaking of TOMOYO 1.8, there is a way. Writing
select <kernel> /sbin/init /bin/bash /bin/myprog
task auto_domain_transition <kernel> /bin/myprog
to /proc/ccs/domain_policy will let the process in the
"<kernel> /sbin/init /bin/bash /bin/myprog" domain to transit to
"<kernel> /bin/myprog" domain upon next permission check.
But, this method will unlikely be implemented in TOMOYO 2.x. TOMOYO 2.x is
using copy-on-write credentials mechanism. Despite the "copy-on-write" naming,
doing so is prohibited in the section between override_creds() and
revert_creds(). This is an annoying limitation for TOMOYO.
To implement "task auto_domain_transition" method in TOMOYO 2.x, I think we
need to choose one from below choices.
(1) Revive security_task_alloc()/security_task_free() and stop using
credentials so that "void *security" field is guaranteed to be always
writable. TOMOYO 1.x and AKARI are using this approach.
(2) Let "struct cred"->security manage list of "struct task_struct *" and
"struct tomoyo_domain_info *" pairs so that "struct tomoyo_domain_info *"
in the "const struct cred" is always writable. This is an encapsulation of
(1) in order to allow kfree() at security_cred_free().
(3) Let TOMOYO omit permission checks if current->cred != current->read_cred
so that TOMOYO can always call prepare_creds()/commit_creds() during
permission check.
David, which one is acceptable for you?