Bug 1000811

Summary: upgrade to Fedora 20 show various selinux errors
Product: [Fedora] Fedora Reporter: Michael S. <misc>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: dominick.grift, dwalsh, lvrabec, mgrepl, misc, rlpowell, tflink, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 13:12:48 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 Flags
screenshot of my vm in openstack none

Description Michael S. 2013-08-25 14:37:39 UTC
Created attachment 790096 [details]
screenshot of my vm in openstack

After running fedup to upgrade a VM from Fedora 19 to Fedora 20, I see some AVC but I only have secreen shot of it.

It seems to be related to ldconfig and the directory used by dracut

However, the system boot fine.

Comment 1 Dominick Grift 2013-12-06 22:46:25 UTC
Interesting

I suspect it is the %postrans script (new-kernel-pkg/rpm_script_t) running a file with type initrc_exec_t and transitioning to initrc_t, that process seems to run a dracut related command which seems to create /vat/tmp/dracut*, and then later runs ldconfig which does stuff inside the dracut dir.

Might be this:
/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.11.9-200.fc19.x86_64 || exit $?

Wondering whether it would be worth trying to figure out what init script it may be, I don't have anything that seems related inside my /etc/rc.d/init.d

Wondering if it even makes sense to for initrc_t to transition to ldconfig_t

I guess there are a few options:

1. just allow this as is
2. remove the transition from initrc_t to ldconfig_t
3. figure out which init script the kernel package %posttrans runs exactly and see whats going on in there

Comment 2 Miroslav Grepl 2013-12-09 08:16:56 UTC
I think we have two issues here. Labeling issue and pipe issue.

What does

# rpm -q kernel --scripts

Do you have s-c-kdump installed?

Also try to run 

# fixfiles check

to see mislabeled files.

Comment 3 Michael S. 2013-12-09 08:56:34 UTC
I no longer have the vm, but I can try to get it. But since fedup is running in a mode with selinux being permissive, so that's likely not a big issue.

I think I didn't have s-c-kdump installed, that was just a default install.

Comment 4 Robin Powell 2014-06-01 09:14:03 UTC
I'm having a similar problem as well, on two machines now; it's *quite* severe.

Let me know if it's not the *same* problem and I'll open a new bug.  Note that, as usual, my systems have unconfined disabled.

To give you sense of scale:

root@stodi# sudo restorecon -Rv /usr/bin/
restorecon reset /usr/bin/screen context staff_u:object_r:bin_t:s0->staff_u:object_r:screen_exec_t:s0
restorecon reset /usr/bin/zsh context staff_u:object_r:bin_t:s0->staff_u:object_r:shell_exec_t:s0
restorecon reset /usr/bin/ksu context staff_u:object_r:bin_t:s0->staff_u:object_r:su_exec_t:s0
restorecon reset /usr/bin/traceroute context staff_u:object_r:bin_t:s0->staff_u:object_r:traceroute_exec_t:s0
restorecon reset /usr/bin/tmux context staff_u:object_r:bin_t:s0->staff_u:object_r:screen_exec_t:s0
restorecon reset /usr/bin/stunnel context staff_u:object_r:bin_t:s0->staff_u:object_r:stunnel_exec_t:s0
restorecon reset /usr/bin/dash context staff_u:object_r:bin_t:s0->staff_u:object_r:shell_exec_t:s0
restorecon reset /usr/bin/irssi context staff_u:object_r:bin_t:s0->staff_u:object_r:irc_exec_t:s0
restorecon reset /usr/bin/teamd context system_u:object_r:bin_t:s0->system_u:object_r:NetworkManager_exec_t:s0
restorecon reset /usr/bin/start-puppet-agent context system_u:object_r:bin_t:s0->system_u:object_r:puppetagent_exec_t:s0
restorecon reset /usr/bin/nmap context staff_u:object_r:bin_t:s0->staff_u:object_r:traceroute_exec_t:s0
restorecon reset /usr/bin/newrole context staff_u:object_r:bin_t:s0->staff_u:object_r:newrole_exec_t:s0
restorecon reset /usr/bin/start-puppet-master context system_u:object_r:bin_t:s0->system_u:object_r:puppetmaster_exec_t:s0
restorecon reset /usr/bin/mandb context staff_u:object_r:bin_t:s0->staff_u:object_r:mandb_exec_t:s0
root@stodi#

I had to setenforce 0 to get *anything* done.  Including sudo, which when attempted resulted in this: sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted

Output of the rpm -q thing: http://paste.fedoraproject.org/106239/40161104

I have no GUI, so no s-c-kdump

Besides those listed above, here's the rest of what fixfiles said:

 http://paste.fedoraproject.org/106241/61377714

(that's assuming the " Warning no default label" things are un-interesting; the *full* file is at https://gist.githubusercontent.com/rlpowell/71ebc0ac52d86407174d/raw/fixfiles.txt )

Comment 5 Robin Powell 2014-06-01 19:13:11 UTC
Today I discovered that sshd can't startup because: 

type=AVC msg=audit(06/01/2014 11:59:47.297:204864) : avc:  denied  { getattr } for  pid=4825 comm=sshd-keygen path=/etc/ssh/ssh_host_rsa_key dev=vda2 ino=263395 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:sshd_key_t:s0 tclass=file

In response and out of desperation I tried:  sudo yum reinstall '*selinux*'

I had previously tried sudo yum reinstall selinux-policy

The list of packages this time was:

Installed:
  libselinux.x86_64 0:2.2.1-6.fc20                libselinux-python.x86_64 0:2.2.1-6.fc20               libselinux-ruby.x86_64 0:2.2.1-6.fc20               libselinux-utils.x86_64 0:2.2.1-6.fc20
  selinux-policy.noarch 0:3.12.1-166.fc20         selinux-policy-devel.noarch 0:3.12.1-166.fc20         selinux-policy-doc.noarch 0:3.12.1-166.fc20         selinux-policy-targeted.noarch 0:3.12.1-166.fc20


And now it's fine.  So, yay?, and maybe that's the workaround?, but still a pretty unfortunate upgrade situation.

Comment 6 Daniel Walsh 2014-06-09 11:56:54 UTC
selinux-policy-targeted package is the one you had to reinstall.

Not sure why it was not working on an upgrade.

Comment 7 Miroslav Grepl 2014-06-09 13:12:48 UTC
Yes, an upgrade issue. Lets close this bug for now to see if we get more issues like this.

Comment 8 Red Hat Bugzilla 2023-09-14 01:49:36 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days