RE: multiple output file context types?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2009-05-14 at 18:01 -0700, Brian Ginn wrote:
> Thanks for the info!
> 
> I chose to use setfscreatecon().
> I had it working on Monday.  It worked through this afternoon, 
> Then all the sudden it stopped working.
> 
> Audit2why reported:
> type=AVC msg=audit(1242347675.070:837): avc:  denied  { create } for  pid=14914 comm="myapp" name="myapp.seclog" scontext=root:system_r:myapp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:myapp_sec_log_t:s0 tclass=file
>         Was caused by:
>                 Constraint violation.
>                 Check policy/constraints.
>                 Typically, you just need to add a type attribute to the domain to satisfy the constraint.
> 
> Audit2allow shows a line that is already in the myapp.te file:
> allow myapp_t myapp_sec_log_t:file create;
> 
> I finally rebooted - and it works again.
> 
> Does SELinux on RHEL5.3 have any known "flakyness" that reboots normally solve?

It wasn't merely the reboot, but rather the SELinux user identity on the
process vs. the file.  If you look at the denial, you'll see that your
process was running with the "root" identity in the scontext, and the
file was labeled with the "system_u" identity in the tcontext.  That
violates a policy constraint on the ability to create or relabel files
with a different SELinux user identity.

Unfortunately, if you manually restart a service, it will run with your
user identity rather than system_u and thus can sometimes cause this
problem.  The "run_init" helper program was written to help avoid this
as well as other issues, e.g. run_init /etc/init.d/myapp restart.

Alternatively, you may wish to add the type attribute to myapp_t that
allows it to create files with a different SELinux user identity.  This
can be done via:
domain_obj_id_change_exemption(myapp_t)
which simply expands to:
require {
	attribute can_change_object_identity;
}
typeattribute myapp_t can_change_object_identity;

This then satisfies the constraint in policy/constraints:
constrain dir_file_class_set { create relabelto relabelfrom }
(
        u1 == u2
        or t1 == can_change_object_identity
);
which means:
Only allow the { create relabelto relabelfrom } permissions if the user
identity of the source context (u1) equals the user identity of the
target context (u2) or if the TE type of the source context (t1) is part
of the set of types associated with the can_change_object_identity type
attribute.

Welcome to a dark corner of SELinux...

-- 
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux