Jamie Nguyen wrote:
> If we use concatenated, can we then forget about the problem you
> mentioned here? :
I think you answered yourself "yes". ;-)
| I think it is true that concatenated is simpler, reduces number of
| files, reduces possibility of human error, and is backwards
| compatible. We can also ignore problems caused by "/" within
| $namespace, and do not have to change directory layout of /etc/ccs.
The backwards incompatible point is that we can no longer sort
exception_policy profile and manager using /bin/sort utility because
these files become stateful like domain_policy .
> By the way, how are you planning to manage profile.conf and
> manager.conf? Each namespace will of course need to have their own
> section within domain_policy.conf and exception_policy.conf, but they
> don't really need their own section in profile.conf,
Insert a special line that tells start of a new namespace.
For example, manager.conf will look like
namespace <kernel>
/usr/sbin/ccs-editpolicy
/usr/sbin/ccs-loadpolicy
namespace <apache>
/usr/sbin/ccs-loadpolicy
namespace </path/to/some/app>
/path/to/some/manager-app
by introducing namespace.
> as it may become
> very confusing if profile=3 in <kernel> namespace is not the same as
> profile=3 in <apache> namespace.
The purpose of having its own section is to avoid interference across
namespaces. It is normal if profile=3 in <kernel> namespace is not the same as
profile=3 in <apache> namespace. Which mode to assign to which profile is up to
policy developers. For example, profile 3 in <kernel> namespace enforces only
file related operations whereas profile 3 in <apache> namespace enforces both
file related operations and network related operations.
In order to avoid accidentally inheriting "use_profile"/"use_group" setting
when jumping to a different namespace, I allow only transition to the root
domain of the new namespace where the domain was already created and was
assigned a profile.
> > (Umm, I can't remember how many times did I typo "namescape" today...)
>
> Moved to a new desktop last week after using a laptop for so long, and
> I'm struggling to get used to the keyboard...
>
Also, I frequently typo "whilelisting" (of course, I mean "whitelisting")
because I use "while" in C programs.
> On an unrelated note, I have noticed that ccs-queryd will pick up
> "misc env" access requests that have been rejected, but these will not
> be picked up by ccs-auditd. Is this intended behaviour?
OK, you found a bug. "misc env" permission is checked using next domain's
profile
ee->r.type = CCS_MAC_ENVIRON;
ee->r.mode = ccs_get_mode(ccs_current_domain()->profile,
CCS_MAC_ENVIRON);
but I forgot to update ee->r.profile . As a result, permission is checked
because ee->r.mode was set to "enforcing mode" but the audit log is not
generated using next domain's profile number because ee->r.profile was not
updated. I think
--- a/security/ccsecurity/domain.c (revision 4960)
+++ b/security/ccsecurity/domain.c (working copy)
@@ -643,8 +643,8 @@
/* printk(KERN_DEBUG "start %d %d\n", argv_count, envp_count); */
int error = -ENOMEM;
ee->r.type = CCS_MAC_ENVIRON;
- ee->r.mode = ccs_get_mode(ccs_current_domain()->profile,
- CCS_MAC_ENVIRON);
+ ee->r.profile = ccs_current_domain()->profile;
+ ee->r.mode = ccs_get_mode(ee->r.profile, CCS_MAC_ENVIRON);
if (!r->mode || !envp_count)
return 0;
arg_ptr = kzalloc(CCS_EXEC_TMPSIZE, CCS_GFP_FLAGS);
will fix it.
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
