On Tue, Nov 10, 2009 at 4:46 PM, Eamon Walsh <ewalsh@xxxxxxxxxxxxx> wrote:
On 11/10/2009 06:54 PM, Larry Ross wrote:
[snip]
>There are additional "constrain" statements in the policy that can
> I have seen this before, and I find it confusing, I get denials:
>
> Nov 10 15:03:43 localhost kernel: type=1400 audit(1257894223.988:43):
> avc: denied { transition } for pid=3799 comm="mysql"
> path="/usr/bin/mysqld_safe" dev=dm-1 ino=460035
> scontext=app_dbadm_u:app_dbadm_r:initrc_t:s0
> tcontext=app_dbadm_u:system_r:mysqld_safe_t:s0 tclass=process
> I run that denial through audit2allow and I get this:
> #============= initrc_t ==============
> allow initrc_t mysqld_safe_t:process transition;
> That rule is already present in the policy:
> allow initrc_t mysqld_safe_t:process transition;
> Can anyone tell me why this happens? Am I missing something? Is
> audit2allow confused? Is the rule not being honored for some reason?
override allow rules. They are in the "policy/constraints" file in the
policy source. In this case, I think you are hitting the following
constraint:
constrain process { transition noatsecure siginh rlimitinh }
(
r1 == r2
or ( t1 == can_change_process_role and t2 == process_user_target )
or ( t1 == cron_source_domain and t2 == cron_job_domain )
or ( t1 == can_system_change and r2 == system_r )
or ( t1 == process_uncond_exempt )
);
Which says you can't transition unless the new role is the same as the
old role (first line) or your type meets one of four exceptions
(remaining lines). audit2allow does get confused here because the AVC
message doesn't indicate that it's because of a constraint violation.
This is a known problem.
Eamon,
Thank you for this, it helps a lot.
In the denial above, the source context is initrc_t but running in the
app_dbadm_r role. I think you want to already be in the system_r role
when you are running as initrc_t. Which is what the last three lines of
Dominick's snippet do:
# When app_dbadm_t runs the mysql init script, change to initrc_t
init_labeled_script_domtrans(app_dbadm_t, mysqld_initrc_exec_t)
I had this wrong I had this instead (obviously I misunderstood the arguments to that interface):
init_labeled_script_domtrans(mysqld_safe_t, mysqld_safe_exec_t)
# Exempt app_dbadm_t from the role-change constraint (to system_r only)
domain_system_change_exemption(app_dbadm_t)
# When app_dbadm_r runs the mysqld init script, change to system_r:
role_transition app_dbadm_r mysqld_initrc_exec_t system_r;
allow app_dbadm_r system_r;
Found it. I had written rules to transition into the initrc_t domain type when executing files with the type initrc_exec_t. This was happening before the execution of mysqld_safe.
So the timeline was:
service mysql start
- calls /etc/init.d/mysql
(initrc_exec_t, causes transition into initrc_t)
- calls /usr/bin/mysqld_safe
(mysqld_safe_exec_t, causes transition into mysqld_safe_t, attempts to transition into system_r and fails)
so it had tranisitoned into the initrc domain before getting to where I thought the problem was.
Thank you everyone for your insight, I learned a lot.
Larry
If you do have this policy in place, check the label on the
/etc/init.d/mysql script and make sure it corresponds to the one in the
policy.
--
Eamon Walsh
National Security Agency
