On 3/30/2017 5:52 PM, Tetsuo Handa wrote:

Casey Schaufler wrote:

quoted

On 3/30/2017 4:09 AM, Tetsuo Handa wrote:

quoted

Even though TOMOYO uses per "struct task_struct" blob, TOMOYO can
start running with any other LSM modules by applying below change.
What are you worrying about?

Until such time as a blob sharing scheme, either the one
I've been working on, yours below or something else, is
adopted, and until another module starts using the task
blob, you could use TOMOYO with any other module. The
existing model for choosing a "major" module does not
allow for TOMOYO+AppArmor. Ignoring the blob management
issue, how would you suggest enabling TOMOYO+AppArmor? 

Changing

-#define SECURITY_NAME_MAX       10
+#define SECURITY_NAME_MAX       64

 int __init security_module_enable(const char *module)
 {
-	return !strcmp(module, chosen_lsm);
+	return strstr(chosen_lsm, module) != NULL;
 }

This will fail if a module name is a substring of
another. "joselinux", "kissysmacker", "parm", "yam"
and "botomoyodoho" would all be names that would
result in confusion. You'd have to do more serious
parsing.
 

and passing

  security=tomoyo,apparmor

to the kernel boot command line option, with checking for currently conflicting
choices like an example below.

	pr_info("Security Framework initialized\n");
+	if (IS_ENABLED(CONFIG_SECURITY_SELINUX) && IS_ENABLED(CONFIG_SECURITY_SMACK) && security_module_enable("selinux") && security_module_enable("smack"))
+		panic("Selected combination is not supported\n");

This is easy enough to handle in Kconfig.

quoted

quoted

If we want per LSM module per "struct task_struct" blob before
TOMOYO is converted to use per "struct task_struct" blob, I'm ready to
propose that part (picked up from below change) first.

I suggest that the best thing to do regarding the task blob
is to adopt a general blob sharing scheme that is useful for
all of the blobs rather than inventing a special one for TOMOYO.

Since we are already receiving proposals of new modules which want to
use the task blob, I think priority of sharing (isolating ?) the task
blob (in other words, allow multiple modules to call task_alloc/task_free
hooks) is higher than enabling SELinux+Smack.

I agree. Mr. Moore wants to see the complete "solution" before
he's willing to endorse intermediate steps, and he has a point.
There is good reason to hold off on introducing a mechanism
that isn't known to hold up long term.

We could introduce infrastructure blob management (as opposed
to the current every-module-for-itself scheme) independently
of dealing with the /proc/.../attr, secid and networking issues.
But if we're not sure the path gets us all the way it would be
foolish to start making changes of that magnitude.

I *think* I have acceptable answers to all those issues in
the works. Once there's conceptual sign-off on those I would
be very much in favor of a staged approach, with the blob
management being the first step.

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html