Re: [TOMOYO #12 (2.6.28-rc2-mm1) 06/11] Common functions for TOMOYOLinux.

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Tetsuo Handa (penguin-kernel@i-love.sakura.ne.jp):
> Hello.
> 
> Serge E. Hallyn wrote:
> > > I need to clarify reachability of "struct task_struct".
> > > 
> > > A process inside a virtualized environment cannot reach "struct task_struct"
> > > which belongs to outside the virtualized environment.
> > > 
> > > A process outside virtualized environments can reach "struct task_struct"
> > > which belongs to inside virtualized environments, can't it?
> > 
> > To be precise, there isn't a real 'inside' and 'outside' virtualized
> > environements.  Rather pid namespaces are hierarchical.
> > 
> So, processes which have non-topmost namespace cannot see processes which have
> topmost namespace (like chroot()).
> Then, it might be preferable if TOMOYO can prevent processes which have
> non-topmost namespace from modifying policy information.
> Do you think TOMOYO should do "current->nsproxy->pid_ns == &init_pid_ns"
> checking like below one?

Nah, I actually don't.  There is nothing to stop init or getty from
doing an unshare(CLONE_NEWNS|CLONE_NEWPID) so noone would be able to
make modifications.  The important thing is that the kernel won't
use another task than what userspace intended, so I think you're ok.

> static bool tomoyo_is_policy_manager(void)
> {
> 	struct tomoyo_policy_manager_entry *ptr;
> 	const char *exe;
> 	const struct task_struct *task = current;
> 	const struct tomoyo_path_info *domainname = tomoyo_domain()->domainname;
> 	bool found = false;
> 
> 	if (!tomoyo_policy_loaded)
> 	        return true;
> 	if (!tomoyo_manage_by_non_root && (task->cred->uid || task->cred->euid))

Now the point of LSM is to let you decide on your own policy, so this
is entirely up to you, but wouldn't it be nicer to use CAP_MAC_ADMIN's
presence like SMACK does?

> 	        return false;
> 	/* Don't allow modifying policy by processes not having init_pid_ns. */
> 	if (task->nsproxy->pid_ns != &init_pid_ns)
> 		return false;

No, I think it's far better to keep this out.  (Plus you'd have to use
task_nsproxy() under rcu_read_lock.)

I know at this point it might seem like I'm changing my mind left and
right (sorry), so here is the guiding principle:  pids are appropriate
for userspace to communicate to userspace and, if done right, to the
kernel.  But the kernel must not cache them internally.

(...and, if getting or sending them from/to user-space, must be careful
about the pidns, of course.)

So you're fine.

thanks,
-serge