Ask Your Question
0

How do I get rid of these SElinux errors on reboot?

asked 2015-11-21 03:24:25 -0600

dcrdev gravatar image

I've just updated to Fedora 23 from F22 Server Edition, this has mostly gone smoothly except one or two issues around selinux. Firstly a lot of services failed to start because of selinux denials, for some reason alot of the selinux bools I'd set before needed to be set again. OK that's not difficult, but I'd kind of like to know why incase there's an underlying issue?

Secondly I have a problem that is persisting and I can't seem to get to the bottom of it. I'm getting a a further selinux denial relating to incorrect labelling:

failed to retrieve rpm info for /dev/shm/lldpad.state
SELinux is preventing mdadm from getattr access on the file /dev/shm/lldpad.state. For complete SELinux messages. run sealert -l a7110687-2ca5-49cc-8d57-4fec455834a3

So running the troubleshooter it suggests running:

/sbin/restorecon -v /dev/shm/lldpad.state

On reboot the error returns - I thought maybe a full relabelling might do the trick i.e. "touch /.autorelabel ", but no dice.

Can anyone help me?

edit retag flag offensive close merge delete

Comments

Depending on what you are doing with your server you may just want to set selinux to permissive. It can cause a lot of headaches.

MetaNova gravatar imageMetaNova ( 2015-11-21 14:17:43 -0600 )edit

Yeah thanks, I do not want to do that.

dcrdev gravatar imagedcrdev ( 2015-11-21 14:25:57 -0600 )edit

Hi, What about changing /dev/shm type label from tmpfs_t to tmp_t ?

casep gravatar imagecasep ( 2015-11-25 04:54:38 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2015-11-27 06:09:49 -0600

steeve gravatar image

I'm finally trying to figure out these selinux alerts (rather than setting to permissive and hoping for the best). No doubt it's an uphill struggle. I get this alert too but since this is a temp filesystem the suggested fix only works until the next reboot. but then how are we supposed to know that this is not a suspicious file or process? Well, in my case it seems to be systemd-logind that is being denied access and that seems to be something that should be allowed.

This was in the details for the report,

If you believe that systemd-logind should be allowed getattr access on the lldpad.state file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep systemd-logind /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

so I ran the two commands at the bottom. But really, this is a bug and should be reported to fedora's bugzilla.

So that's what I'll do now, go over and check at bugzilla.redhat.com for this policy issue.

edit flag offensive delete link more

Comments

Already filed as a bug: https://bugzilla.redhat.com/show_bug....

But no ones really interested, sigh.

dcrdev gravatar imagedcrdev ( 2015-11-30 16:16:16 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2015-11-21 03:24:25 -0600

Seen: 1,864 times

Last updated: Nov 21 '15