Message-Id: <201505171253.DAJ51090.SOVOQOFJFtFHLM@I-love.SAKURA.ne.jp>
Date:	Sun, 17 May 2015 12:53:55 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	casey@...aufler-ca.com
Cc:	jmorris@...ei.org, james.l.morris@...cle.com,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmoore@...hat.com,
	john.johansen@...onical.com, sds@...ho.nsa.gov, eparis@...hat.com,
	keescook@...omium.org
Subject: Re: LSM: Basic module stacking infrastructure for security-next-Acked

Casey Schaufler wrote:
> > I would like to propose revival of security_task_alloc()/security_task_free()
> > hooks. I have several single function modules which want to use these hooks.
> >
> > 4 years ago, I wrote
> > http://osdn.jp/projects/akari/scm/svn/blobs/head/branches/uuid4.c
> > which is targeted for restricting qemu processes managed via libvirtd process
> > with operations in case bugs like VENOM: QEMU vulnerability (CVE-2015-3456)
> > are discovered, without making system administrators' heads explode by
> > enforcing SELinux. When isolating processes, use of per "struct task_struct"
> > blob saves a lot of unnecessary duplication of per "struct cred" blob.
> >
> > Another module which want to use security_task_alloc()/security_task_free()
> > is kportreserve, which does not need to distinguish users but wants to cache
> > current thread's executable path. In general, my LSM modules try to distinguish
> > not users but processes. Therefore, per "struct task_struct" blob is convenient
> > for me.
> >
> > I could not afford proposing this kind of single function modules for mainline
> > at that time. But now, if we wish to accept this kind of modules, I can update
> > them and propose for mainline. (If we wish to keep this kind of modules away in
> > order to avoid getting security/ directory bloated, I'm OK with only exporting
> > security_hook_heads; I'll continue managing as out-of-tree LSM kernel modules.)
> >
> > If security_task_alloc()/security_task_free() come back (and optionally
> > "void *security" in "struct task_struct" also comes back), we can run
> > {SELinux,Smack,AppArmor}+TOMOYO now, for what TOMOYO is designed to use as
> > security blob is "struct task_struct"->security than "struct cred"->security.
> >
> > Can I again propose security_task_alloc()/security_task_free() hooks for
> > these single function modules and TOMOYO?
> 
> Although I agree with you that it makes more sense to hang task data
> off of the task structure than off of the cred structure I don't like
> the notion of having both. I wasn't heavily involved in the cred split
> (and was not then and not now a fan of it) and missed the discussion
> about why the security blob is included in the cred. But, that's where
> it ended up. I would have no objection to moving the blob from the cred
> to the task, although I expect there are reasons for it to remain
> where it is.

My understanding is that "struct cred" was introduced in order to allow
switching all user-related attributes atomically, and "struct cred"->security
was introduced because it was one of user-related attributes which should be
switched among with other user-related attributes. Also, subjective / objective
creds distinction was introduced in order to allow overriding these
user-related attributes without affecting inter-process operations.

> 
> For now at least, I propose that we leave the security blob in the cred.

We can't move "struct cred"->security back to "struct task_struct"->security
because SELinux wants to switch all user-related attributes atomically. But
TOMOYO can't utilize "struct cred"->security well because it is not allowed
to modify "struct cred"->security when TOMOYO wants to use it as per
"struct task_struct" attributes.

Yama uses security_task_free() but does not need security_task_alloc()
because Yama does not need to inherit per "struct task_struct" entry to
fork()ed process. But TOMOYO needs security_task_alloc() to inherit it.
Even without reviving "struct task_struct"->security , TOMOYO can manage like
Yama's "struct ptrace_relation" if security_task_alloc() is available.

> I will be proposing mechanisms for dealing with that pesky "void *security"
> shortly. During the time I've been working on stacking I've identified
> a veritable plethora of ways to address the issue. I am putting together
> a menu of options and a set of arguments to help guide an open debate on
> which suits the current state and direction of the kernel best.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists