CentOS 7 Selinux Policy Bug

Home » CentOS » CentOS 7 Selinux Policy Bug
CentOS 4 Comments

Hi, folks,

CentOS 7.1. Selinux policy, and targetted, updated two days ago.

May 28 17:02:41 python: SELinux is preventing /usr/bin/bash from execute access on the file /usr/bin/bash.#012#012***** <...>
May 28 17:02:45 python: SELinux is preventing /usr/bin/bash from execute access on the file /usr/bin/uname.#012#012***** <...> May 28
17:02:45 python: SELinux is preventing /usr/bin/uname from execute_no_trans access on the file /usr/bin/uname.#012#012***** <...>
May 28 17:02:47 python: SELinux is preventing /usr/bin/bash from execute access on the file /usr/bin/mailx.#012#012***** <...>

I did do an ll =Z /usr/bin, and everything looks correct
(system_u:object_r:bin_t:s0). Given that, looks to me like a policy bug. No? Yes? File a bug report?

mark

4 thoughts on - CentOS 7 Selinux Policy Bug

  • I saw the same behaviour this morning, however the labels changed to
    “unlabelled” for a number of programs; e.g. /etc/ssh/sshd_config,
    /etc/shadow, /etc/pam/* and a few others. I saw this after I was not able to login to my laptop, login to single user mode and saw tonnes of SELinux errors and changed it from enforcing to permissive and then I was able to restore the labels.

    Most certainly believe its a bug.

  • What is your environment set up for? Is this just straight out of the box, or have you harden the systems any?

    —–Original Message—

  • Conley, Matthew M CTR GXM wrote:
    Straight out of the box policy. I’ve just looked, and I don’t think I’ve even created any local policies to shut up selinux for things my users might do.

    I can tell, since I always create the local policies in /root. Luckily, we’re in permissive mode – these aren’t production servers, they’re work machines, compute nodes or research.

    mark “one of my annual goals: shut up selinux babble”