Bug 191108 - Switching from strict to targeted is incomplete
Summary: Switching from strict to targeted is incomplete
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict   
(Show other bugs)
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-05-08 22:33 UTC by Darwin H. Webb
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-14 15:16:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Darwin H. Webb 2006-05-08 22:33:11 UTC
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
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
system rebooted and came up, no relabel done.

Version-Release number of selected component (if applicable):

How reproducible:
don't know

Steps to Reproduce:
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:

Comment 1 Darwin H. Webb 2006-05-08 22:37:08 UTC
Taht s/b 

expect to swith policy withOUT having to do a permissive stage(d) boot.

Comment 2 Daniel Walsh 2006-10-05 14:24:13 UTC
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?

Comment 3 Darwin H. Webb 2006-10-05 23:33:27 UTC
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,


Comment 4 Darwin H. Webb 2006-10-05 23:53:59 UTC
This is interesting ..???

$ su -
[root@Jade-38 ~]# dir -h
anaconda-ks.cfg  install.log  install.log.syslog  scsrun.log
[root@Jade-38 ~]# cd /
[root@Jade-38 /]# dir -h
bin   dev  home  lost+found  misc  net  proc  sbin     srv  tmp  var
boot  etc  lib   media       mnt   opt  root  selinux  sys  usr
[root@Jade-38 /]# touch /.autorelabel
[root@Jade-38 /]# dir -h
bin   dev  home  lost+found  misc  net  proc  sbin     srv  tmp  var
boot  etc  lib   media       mnt   opt  root  selinux  sys  usr
[root@Jade-38 /]# cd /home
[root@Jade-38 home]# dir -h
darwinhwebb  lost+found
[root@Jade-38 home]# cd /
[root@Jade-38 /]# dir -h
bin   dev  home  lost+found  misc  net  proc  sbin     srv  tmp  var
boot  etc  lib   media       mnt   opt  root  selinux  sys  usr
[root@Jade-38 /]# locate .autorelabel
[root@Jade-38 /]# 

Comment 5 Darwin H. Webb 2006-10-06 00:01:49 UTC
 yet it is there ...
# ls -halZ
drwxr-xr-x  root root system_u:object_r:root_t         .
drwxr-xr-x  root root system_u:object_r:root_t         ..
-rw-r--r--  root root system_u:object_r:etc_runtime_t  .autofsck
-rw-r--r--  root root user_u:object_r:etc_runtime_t    .autorelabel
drwxr-xr-x  root root system_u:object_r:bin_t          bin
drwxr-xr-x  root root system_u:object_r:boot_t         boot
drwxr-xr-x  root root system_u:object_r:device_t       dev
drwxr-xr-x  root root system_u:object_r:etc_t          etc
drwxr-xr-x  root root system_u:object_r:home_root_t    home
drwxr-xr-x  root root system_u:object_r:lib_t          lib
drwx------  root root system_u:object_r:lost_found_t   lost+found
drwxr-xr-x  root root system_u:object_r:mnt_t          media
drwxr-xr-x  root root system_u:object_r:autofs_t       misc
drwxr-xr-x  root root system_u:object_r:mnt_t          mnt


Comment 6 Darwin H. Webb 2006-10-06 00:48:55 UTC
ok, the .autorelabel works twice in a row.

I change to strick policy and rebooted.

I got kernel panaic on init loading libseplo.so.1 
avc: access denied (execute) comm=init name=libsepol.so.1
scontext=system_u:system_r:init_t:so tcontext=system_u:object_r:lib_t:so
tclass=file /bin/init: error while loading shared libraries: libsepol.so.1 :
failed to map segment from shared object: access denied


Comment 7 Daniel Walsh 2006-10-06 15:31:43 UTC
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.

Comment 8 Darwin H. Webb 2006-10-17 00:18:35 UTC
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?


Comment 9 Daniel Walsh 2006-10-17 12:12:41 UTC
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.

Comment 10 Darwin H. Webb 2007-01-25 21:35:14 UTC
This bug can be closed as new SELinux policy has changed.
I will try strick on a newer release in the future.


Comment 11 Daniel Walsh 2007-02-14 15:16:29 UTC
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.