Tetsuo Handa wrote:
>> 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.
OK, sounds good.
>> 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.
Thanks. I've applied this to ccs-patch 1.8.1p1 and it works as expected now:
diff -uNr linux-2.6.38.orig/security/ccsecurity/domain.c
linux-2.6.38/security/ccsecurity/domain.c
--- linux-2.6.38.orig/security/ccsecurity/domain.c 2011-04-11
01:00:00.000000000 +0100
+++ linux-2.6.38/security/ccsecurity/domain.c 2011-05-02
19:45:35.429994536 +0100
@@ -673,8 +673,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);
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
