Bug 1000811 - upgrade to Fedora 20 show various selinux errors [NEEDINFO]
upgrade to Fedora 20 show various selinux errors
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-25 10:37 EDT by Michael Scherer
Modified: 2014-06-09 09:12 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-09 09:12:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mgrepl: needinfo? (misc)


Attachments (Terms of Use)
screenshot of my vm in openstack (111.41 KB, image/png)
2013-08-25 10:37 EDT, Michael Scherer
no flags Details

  None (edit)
Description Michael Scherer 2013-08-25 10:37:39 EDT
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 17:46:25 EST
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 03:16:56 EST
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 Scherer 2013-12-09 03:56:34 EST
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 05:14:03 EDT
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 15:13:11 EDT
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 07:56:54 EDT
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 09:12:48 EDT
Yes, an upgrade issue. Lets close this bug for now to see if we get more issues like this.

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