Bug 1054515
| Summary: | denials while running anaconda in Enforcing mode | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Brian Lane <bcl> | ||||
| Component: | filesystem | Assignee: | Ondrej Vasik <ovasik> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Milos Malik <mmalik> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.0 | CC: | bcl, degts, dwalsh, mmalik | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-02-01 09:10:39 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Brian Lane
2014-01-17 00:22:24 UTC
Created attachment 851360 [details]
log of denials while running anaconda with Enforcing mode
(In reply to Brian C. Lane from comment #1) > Created attachment 851360 [details] > log of denials while running anaconda with Enforcing mode Are these with the default anaconda labeling? (In reply to Miroslav Grepl from comment #3) > (In reply to Brian C. Lane from comment #1) > > Created attachment 851360 [details] > > log of denials while running anaconda with Enforcing mode > > Are these with the default anaconda labeling? Yes. When I relabel them with livecd_exec_t the only one I get is the NetworkManager one in comment #1 and then a timeout traceback. We seem to have dropped the ball on this one. Miroslav lets change the label and allow networkmanager to communicate with livecd_t. Could you please re-test it with the latest el7 policy build which is available from brew. selinux-policy-3.12.1-137.el7 is a big improvement.
anaconda and anaconda-yum now have system_u:object_r:install_exec_t and I don't have any problems running the installation.
But I am still seeing a pile of errors from passwd, useradd, and groupadd.
eg.
Mar 14 14:23:24 localhost.localdomain setroubleshoot[27019]: dbus avc(node=localhost.localdomain type=AVC msg=audit(1394832202.307:831): avc: denied { read } for pid=27017 comm="passwd" name="run" dev="dm-1" ino=72 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=lnk_file
node=localhost.localdomain type=SYSCALL msg=audit(1394832202.307:831): arch=c000003e syscall=42 success=no exit=-13 a0=18 a1=7fff607dfc80 a2=6e a3=7faababd57b8 items=0 ppid=27016 pid=27017 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="passwd" exe="/usr/bin/passwd" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null) node=localhost.localdomain type=EOE msg=audit(1394832202.307:831):) called: 1 Connections
A minimal install disk image boots fine as far as I can tell, but a desktop install gets stuck.
This looks like you have a lnk file run that is labeled default_t? ls -lZ /run Not on the host, but when the install starts it has the wrong labels on /mnt/sysimage/var/run and /mnt/sysimage/var/lock lrwxrwxrwx. root root unconfined_u:object_r:default_t:s0 lock -> ../run/lock lrwxrwxrwx. root root unconfined_u:object_r:default_t:s0 run -> ../run The actual directories look ok: drwxr-xr-x. root root system_u:object_r:var_run_t:s0 run drwxr-xr-x. root root system_u:object_r:var_lock_t:s0 lock These are created very early in the install, by the filesystem package. The host system has selinux-policy-3.12.1-137.el7.noarch installed, but at the time filesystem is installed the chroot hasn't installed selinux yet. AFAIK there is a bug for this issue. (In reply to Miroslav Grepl from comment #10) > AFAIK there is a bug for this issue. And it should be already fixed in the filesystem pkg. (In reply to Miroslav Grepl from comment #11) > (In reply to Miroslav Grepl from comment #10) > > AFAIK there is a bug for this issue. > > And it should be already fixed in the filesystem pkg. With filesystem-3.2-18.el7 I am still seeing the symlinks with the wrong labels as described in comment 9. The host is using selinux-policy-3.12.1-147.el7.noarch Mirek/Milos, what do you expect to be done in filesystem? I already run restorecon in posttrans in 7.0GA package. Is this supposed to be TestOnly bugzilla? Should I move it to ON_QA? It seems that everything under /mnt/sysimage is not labeled correctly. Would it be possible to assign correct labels to the file-system mounted in /mnt/sysimage before anaconda starts to install things into the file-system? For example using file context equivalences: semanage fcontext -e ... No, as I pointed out in comment 12 almost all of it is working correctly, it's just those symlinks that are an issue. I just reran my test with: anaconda-19.31.98-2 selinux-policy-targeted-3.13.1-2.el7.noarch And everything looks like it is labeled correctly now. Thanks! So can we close this bug? Let's close it worksforme, unless there is clear what should be done in filesystem package. I don't see anything - restorecon on the symlinked directories is called in filesystem package (as posttrans, otherwise restorecon is not installed yet at the time of filesystem installation). |