After the most recent (post-FC2t2) updates to the policy package, staff_r (and, I am guessing, user_r too) can not run rpm - even "rpm -q" or "rpm -V". This is IMO wrong. If there is a desire to prohibit staff_r from running rpm_exec_t files (which is probably a good idea), then the /usr/lib/rpm/rpmi should be marked as rpm_exec_t, while /bin/rpm should become an ordinary bin_t (and should then always call rpmi for actual rpm installs/upgrades).
Actually, *everyone* should be able to run rpm -q ; anything else should be a tunable.
I am not seeing this. What avc messages are you getting? Dan
That's the thing - I am not getting any, just the "Permission denied". % rpm -q rpm bash: /bin/rpm: Permission denied % ls -l /bin/rpm -rwxr-xr-x 1 rpm rpm 75760 ÐÐ°Ñ 16 09:10 /bin/rpm % ls -lZ /bin/rpm -rwxr-xr-x+ rpm rpm system_u:object_r:rpm_exec_t /bin/rpm % id -Z aleksey:staff_r:staff_t % ls -lZ /usr/bin/yum -rwxr-xr-x+ root root system_u:object_r:rpm_exec_t /usr/bin/yum % yum bash: /usr/bin/yum: /usr/bin/python: bad interpreter: Permission denied % sudo rpm -q policy-sources policy-sources-1.9.1-2
Could you do a setenforce 0 Then execute the rpm -q command and see if you get any messages. Are you on the #selinux chat room? Dan
security_compute_sid: invalid context aleksey:staff_r:rpm_t for scontext=aleksey:staff_r:staff_t tcontext=system_u:object_r:rpm_exec_t tclass=process
For some reason you are attempting to transition to rpm_t. You should not be, for the staff user while not in unlimitedUsers. Could you check to see if you have a domain_trans for staff_t to rpm_t? Dan
Ah, I do have unlimitedUsers set.
role staff_r types rpm_t; If you want to run in unlimitedUsers you need to add the above line to rpm.te where the transition code is. I will fix this in the next policy. The unlimitedUsers role will be turned off in the next policy, as we attempt to tighten up the security, in policy.
OK, I brough my tunable.te closer to the one currently distributed (including commenting out the unlimitedUsers) and the problem went away. Thanks!
Fixed in policy-1.9.1-4