lkml.org 
[lkml]   [2009]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: A basic question about the security_* hooks
From
Date
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.

\
 
 \ /
  Last update: 2009-12-27 05:05    [W:0.094 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site