Description of problem:
Switched to strict policy in permissive mode (selinux-policy-2.2.36-2.fc5)
rebooted and system was relabeled. (FC5 Desktop, Gnome, all updates)
After a while I needed to switch back to targeted.
SELinux security gui - changed to targeted, enforcing - gui would not close.
...changed to targeted, permissive - gui closed.
reboot issued in term. Accessed denied, then system disk ramped up doing a
relabel. It ran for 5 minutes, I pressed the power off button, system when into
shutdown and shutdown ok.
powered up and system came up ok, no relabel message.
checked SELinux security - was set to targeted, permissive.
changed to targeted,enforcing.
touch /.autorelabel
reboot
system rebooted - no relabel done, SELinux in targeted, enforcing.
Opened evolution e-mail - after up and running, accessed denied on
/home/username/.evolution/temp/spool... would not red new mail.
in term at / issued ls -halZ
cd /home
ls -halZ
cd /home/username
ls -halZ
At all of these levels were unlabeled_t types
interm issued fixfiles restore /home
files , sub dir's changed to user_home_t
evolution e-mail worked correctly.
cd /
touch /.autorelabel
reboot
system rebooted and came up, no relabel done.
Version-Release number of selected component (if applicable):
selinux-policy-2.2.36-2.fc5
How reproducible:
don't know
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
expect relabel every time /.autorelabel is present.
expect relabeling to happen after rebooting not before rebooting.
expect system and home to be relabeled completely.
expect to swith policy with having to do a permissive stage(d) boot.
Additional info:

Sorry about not getting back to you. This bugzilla got lost.
I have no idea why autorelabel would not run the relabeling code. Do you see
any error messages when it tries to relabel?
We have never seen a problem with autorelabel and it has been done many times.
Have you updated to the latest SELinux tool chain and policy?

Hi Daniel,
Yes, I have updated and the last 2 policies have cleaned up many of my issues.
I have not tried strick since then but I will do so in a day or so.
The one issue of touch /.autorelabel was still present a few days ago when I was
dealing with squid errors. I have a thoery but I don;t know how touch works or
how .autorelabel is handled by the bootup.
If .autorelabel does NOT exist then the new file is created and all is well,
relabeling occurs.
If .autorelabel exists, touch makes a .autorelabel(2) of some sort.
The reboot sees the original and does nothing but deletes it.
Next time touch creates a new orginal and relabels and deletes it?
When something gets out of whack leaving a .autorelabel the cycle repeats?
May be a good idea to OWN any form of .autorelabel and delete them all?
I'll test that out just before trying the strict.
thank you,
Darwin

When switching to strict you need to boot in permissive mode in order for the
relabeling to work. Then reboot in enforcing mode. There is no other way to
handle this, since strict policy treats shared libraries differently then targeted.

done, strick was enabled
root account was not available for any system changes - is this now a sudo
setting or do I need a role change?
I had no way to get out of strict, so I had to boot into another system and
mount / to change /etc/linux to targeted, permissive and add an .autorelabel
Rebooted into FC and it went back to targeted, changed to enforcing.
How is root operated under strict?
Darwin

No you should be able to log in as root. Then you need to newrole to sysadm_r
if you want to do the things you normally could do as root
newrole -r sysadm_r
strict has not gotten much testing lateley so there could be some major bugs.

All of these bugs should be fixed in FC6, You could attempt to use the FC6
policy on FC5 or upgrade. Or you could use
audit2allow -M mypolicy -i /var/log/audit/audit.log
and build local customized policy

Note

You need to
log in
before you can comment on or make changes to this bug.