linux-kernel - Re: A basic question about the security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200912271302.JBH64754.JtLMFQVOSOFFHO@I-love.SAKURA.ne.jp>
Date:	Sun, 27 Dec 2009 13:02:54 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	serge@...lyn.com
Cc:	serue@...ibm.com, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: A basic question about the security_* hooks

Serge E. Hallyn wrote:
> Well, according to Mimi's email this is essentially what was
> decided upon for IMA.  So I think workable guidelines would
> be that anything which can't possibly be expected to interfere
> with other LSMs can be added like that.
>
> More generally, the flaw in the approach is that the hooks for
> several permutations of LSMs might interfere with each other.
> So for instance the cap_inode_setxattr() hook should always
> be called if selinux is not enabled, but should not be called
> for security.selinux namespace xattrs if selinux is enabled.

May I do opportunistic question regarding TOMOYO?

I'm distributing SELinux+TOMOYO kernels (since Fedora Core 3) and
AppArmor+TOMOYO kernels (since openSuSE 10.1), but I didn't encounter problems.
TOMOYO can use similar approach which disablenetwork uses (i.e. adding
dedicated variable to task_struct and not using "void *security" and not using
LSM hooks for allocating/freeing "void *security" and not using xattr of
filesystems).

@@ -1557,6 +1559,10 @@ struct task_struct {
 		unsigned long memsw_bytes; /* uncharged mem+swap usage */
 	} memcg_batch;
 #endif
+#ifdef CONFIG_CCSECURITY
+	struct ccs_domain_info *ccs_domain_info;
+	u32 ccs_flags;
+#endif
 };

I believe TOMOYO can safely coexist with other security modules.
Why TOMOYO must not be used with SELinux or Smack or AppArmor?
What interference are you worrying when enabling TOMOYO with SELinux or Smack
or AppArmor?

Regards.
--
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/