Bug 1157143 - "SELinux is preventing yum from entrypoint access on the file /usr/bin/bash"
Summary: "SELinux is preventing yum from entrypoint access on the file /usr/bin/bash"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: livecd-tools
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1161517 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-25 09:42 UTC by Peter H. Jones
Modified: 2014-11-18 18:39 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-11-18 18:39:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
troubleshooter output (2.16 KB, text/plain)
2014-10-25 09:42 UTC, Peter H. Jones
no flags Details

Description Peter H. Jones 2014-10-25 09:42:52 UTC
Created attachment 950626 [details]
troubleshooter output

Description of problem:
SELinux alert updating selinux-policy-3.13.1-90.fc21 to selinux-policy-3.13.1-91.fc21 .

Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-90.fc21

How reproducible:
Tried only once.

Actual results:
SELinux alert

Expected results:
No alert

Additional info:
Troubleshooter info (attached). The restorecon command suggested there changed the context of /usr/bin/bash.

Comment 1 Miroslav Grepl 2014-10-25 19:18:14 UTC
Did you update only the policy?

What does

#restorecon -R -v /usr/bin

Comment 2 Peter H. Jones 2014-11-07 07:39:22 UTC
"ls -ldZ /usr/bin
+ ls -ldZ /usr/bin
dr-xr-xr-x. root root unconfined_u:object_r:root_t:s0  /usr/bin
/usr/sbin/restorecon -v /usr/bin
+ /usr/sbin/restorecon -v /usr/bin
/usr/sbin/restorecon reset /usr/bin context unconfined_u:object_r:root_t:s0->unconfined_u:object_r:bin_t:s0
ls -ldZ /usr/bin
+ ls -ldZ /usr/bin
dr-xr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/bin
/usr/sbin/restorecon -v /usr/bin
+ /usr/sbin/restorecon -v /usr/bin
ls -ldZ /usr/bin
+ ls -ldZ /usr/bin
dr-xr-xr-x. root root unconfined_u:object_r:bin_t:s0   /usr/bin"

This happens in a custom livece-creator kickstart script that uses selinux-policy-targeted-3.13.1-92.fc21 .

Comment 3 Miroslav Grepl 2014-11-07 10:43:51 UTC
*** Bug 1161517 has been marked as a duplicate of this bug. ***

Comment 4 Brian Lane 2014-11-07 20:47:53 UTC
I'm sorry, I can't make any sense of this.

If it's a policy problem then that's by definition a selinux issue. I don't see any logs from livecd-creator here, and from the troubleshooter output it looks like it is in permissive.

1. What are you running.
2. What is the actual problem? Please include logs, error output, a good detailed description of what you are doing, etc.

Comment 5 Peter H. Jones 2014-11-17 20:42:08 UTC
I'm creating a custom Xfce live spin targeted for FC21. livecd-tools-21.4-1.fc21.x86_64 is running on a FC20 system because there doesn't seem to be an FC21-targeting version  of syslinux in FC20. The latest on koji is syslinux-4.05-7.fc20.

Often, I can't log in. Accordingly, I have included setools-3.3.8-5.fc21 in order to be able to generate the additional selinux modules to permit logging in.

As you observed, I am using permissive mode to diagnose the problem. When I have a new build, I test it first with media testing, enforcing=0 and mode 3. I do a CTRL-ALT-F2 to get a TTY2 window and log in as root. I have a small script that scans /var/log/audit/audit.log and generates .te module source files for the next build. Also, it rolls over the audit.log file with a SIGUSR1 to the auditd process.

If no .te's were generated in the previous step, I reboot normally. I try logging in and out on TTY3 (terminal mode), and out and in on TTY1 (graphical mode). If any of these attempts fail, I use TTY2 to generate a .te for the next build.

Finally, I try disabling each custom module in turn and do the above login/out testing. If a failure occurs, I generate a .te and compare with the one I just disabled. If it's equivalent, I reenable that module and test the next. If the new module I generated is not equivalent, I keep both for the next round.

If I find I can disable a module and still log in and out, I consider that module possibly redundant. For the subsequent build, that module is installed and set to disabled during the build. If the module is not needed (can log in/out with it disabled), it is eliminated from the next build.

For the next build, I apply the modules and start the cycle over again. The goal is to not need any custom modules.

The bug as originally reported seems to have gone away. My build log contains:
"rpm -Uv /selinux-policy-3.13.1-96.fc21.noarch.rpm /selinux-policy-devel-3.13.1-96.fc21.noarch.rpm /selinux-policy-targeted-3.13.1-96.fc21.noarch.rpm^M
Preparing packages...^M
selinux-policy-3.13.1-96.fc21.noarch^M
selinux-policy-devel-3.13.1-96.fc21.noarch^M
selinux-policy-targeted-3.13.1-96.fc21.noarch^M
selinux-policy-targeted-3.13.1-92.fc21.noarch^M
selinux-policy-devel-3.13.1-92.fc21.noarch^M
selinux-policy-3.13.1-92.fc21.noarch^M
"
running the livecd-creator chroot environment.

So I think this bug can be closed, and if I find my custom modules are taking too long to become redundant with software updates, I can report the problem against selinux-policy.

Comment 6 Brian Lane 2014-11-18 18:39:27 UTC
FYI, there is a new syslinux, it was updated to 6.03 for f21 and requires some changes in livecd-tools which is one of the reasons you have to run the correct version.


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