Bug 191108
Summary: | Switching from strict to targeted is incomplete | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Darwin H. Webb <thethirddoorontheleft> |
Component: | selinux-policy-strict | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED NEXTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | dwalsh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-02-14 15:16:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Darwin H. Webb
2006-05-08 22:33:11 UTC
Taht s/b expect to swith policy withOUT having to do a permissive stage(d) boot. 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 This is interesting ..??? $ su - Password: [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 /]# 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 rebooting 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 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. This bug can be closed as new SELinux policy has changed. I will try strick on a newer release in the future. Darwin 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 |