systemctl status dbus-broker
● dbus-broker.service - D-Bus System Message Bus
   Loaded: loaded (/usr/lib/systemd/system/dbus-broker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-05-05 22:48:27 CEST; 2min 44s ago
     Docs: man:dbus-broker-launch(1)
  Process: 1355 ExecStart=/usr/bin/dbus-broker-launch --scope system --audit (code=exited, status=226/NAMESPACE)
 Main PID: 1355 (code=exited, status=226/NAMESPACE)

máj 05 22:48:30 hostname systemd[1]: Failed to start D-Bus System Message Bus.
máj 05 22:48:30 hostname systemd[1]: dbus-broker.service: Start request repeated too quickly.
máj 05 22:48:30 hostname systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
máj 05 22:48:30 hostname systemd[1]: Failed to start D-Bus System Message Bus.
máj 05 22:48:31 hostname systemd[1]: dbus-broker.service: Start request repeated too quickly.
máj 05 22:48:31 hostname systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
máj 05 22:48:31 hostname systemd[1]: Failed to start D-Bus System Message Bus.
máj 05 22:48:31 hostname systemd[1]: dbus-broker.service: Start request repeated too quickly.
máj 05 22:48:31 hostname systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
máj 05 22:48:31 hostname systemd[1]: Failed to start D-Bus System Message Bus.

Hi Marek, 

Could you please restart the dbus-broker and then run command:

# ausearch -m AVC -m USER_AVC -ts boot 

and paste here output from that command? 

Thanks,
Lukas.

Hello,

first time there was no match. After latest updates (including named) I got:

time->Mon May  6 21:26:40 2019
type=AVC msg=audit(1557170800.821:154): avc:  denied  { write } for  pid=2539 comm="named" name="named" dev="dm-2" ino=262151 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_zone_t:s0 tclass=dir permissive=0

Probably not related?

Marek

I have 3 machines available. Two of them have the problem. All of them
were upgraded using dnf distro-sync. I am thining about differences.
Maybe the working one was the latest installed (shortest upgrade path
- maybe since Fedora 28 or 29).

I upgrade fourth machine also with older upgrade history and it has no problem. Only the two mentioned.

Just upgraded one of my Raspberry Pi to 30 and got this error.  
Original Install was Fedora 27, Upgraded 27 ->29 and then just 29 to 30.


I did a 
setenforce 1
systemctl restart dbus-broker
setenforce 0
systemctl start dbus-broker


(which failed to start with enforcing) but only got these in response to the ausearch as above

time->Tue May 14 00:09:46 2019
type=USER_AVC msg=audit(1557806986.940:244): pid=717 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  received setenforce notice (enforcing=1)  exe="/usr/bin/dbus-broker" sauid=81 hostname=? addr=? terminal=?'
----
time->Tue May 14 00:09:50 2019
type=USER_AVC msg=audit(1557806990.765:247): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received setenforce notice (enforcing=1)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Two other machines which were installed as Fedora 29 then upgraded to 30 did not have this issue (they were both x86_64).

Hi All, 

Could you fix labels on your system after upgrading? Please run:

# restorecon -Rv / 


If this doesn't help, could you please turn on dontaudit rules by:

# semodule -DB 

and reproduce the issue? It should generate more SELinux denials and then attach output of:

# ausearch -m AVC,USER_AVC,SELINUX_ERR

Thanks,
Lukas.

Created attachment 1569013 [details]
Audit errors after fix labels and semodule -DB enforcing

I did the 
# restorecon -Rv / 

set enforcing again and rebooted -- did not help

Then per instructions I did

# semodule -DB 

then attempted to start dbus-broker again.  

Dates are April 26 because it's a Raspberry Pi and the dbus-broker start failure keeps the network down so it couldn't get the time via NTP.

Created attachment 1569014 [details]
Audit errors after fix labels and semodule -DB permissive

After the above I set the default back to permissive and rebooted.
and reran the ausearch -m AVC,USER_AVC,SELINUX_ERR  just in case you wanted to see that.

Hello,

I run
# setenforce 0
# semodule -DB
# systectl restart dbus-broker
# semodule -B
# ausearch -m AVC,USER_AVC,SELINUX_ERR

I cut the output for the todays lines:
time->Wed May 15 19:21:26 2019
type=USER_AVC msg=audit(1557940886.500:422): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received setenforce notice (enforcing=0)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
----
time->Wed May 15 19:21:26 2019
type=USER_AVC msg=audit(1557940886.500:423): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=2)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
----
time->Wed May 15 19:21:26 2019
type=AVC msg=audit(1557940886.522:424): avc:  denied  { mounton } for  pid=3732 comm="(r-launch)" path="/run/systemd/unit-root/dev" dev="dm-1" ino=393217 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

The only possibly relevant logs is the last one. Was it helpful?

Thanks
Marek

Hi Marek, 

This helped. Avc from comment#11 is dontaudited in SELinux policy. (Means that it's not allowed but also not recorded by audit daemon)

Could you please attach output of:

# ls -Z  /run/systemd/unit-root/dev

If the context is unlabeled, please run:

# restorecon -Rv /run/systemd/unit-root/dev

Thanks,
Lukas.

Hello Lukas,

there is no such file, there. Even on the working machines.

Moreover I found out that not only dbus-broker have the problem, but the same problem (failed to set up mount namespacing) have also logrotate.service, ModemManager and bluetoothd.

Marek

Hello Lukas,

could you, please, suggest next troubleshooting steps?

Thanks

Marek

Hello Lukas,

I found this:
https://hansdegoede.livejournal.com/20910.html

It fixed the problem.

I run:
mount -o bind / /mnt
cd /mnt
chcon -t device_t dev
chcon -t home_root_t home
chcon -t root_t proc sys
chcon -t var_run_t run
cd
umount /mnt

and voila.

Marek

There is even more complete list on https://ask.fedoraproject.org/t/fedora-30-selinux-enabled-things-fail-status-226-namespace/1516

chcon -t device_t dev
chcon -t home_root_t home
chcon -t root_t proc sys
chcon -t var_run_t run
chcon -t tmp_t tmp
chcon -t boot_t boot

Creating /.autorelabel as suggested later in the document is not sufficient since relabeling is run after the filesystems are mounted and thus labels are not changed. Morever /.autorelabel breaks also named-chroot service - see bug 1525641. Another restorecon -R -v /var/named/chroot is needed.

Marek

By inspecting current file_contexts probably the most accurate would be:

chcon -t device_t dev
chcon -t home_root_t home
chcon -t root_t proc
chcon -t sysfs_t sys
chcon -t var_run_t run
chcon -t tmp_t tmp
chcon -t boot_t boot

Marek

Hi Marek ,

Thanks for investigation. However, I don't understand what exactly you did to need this workaround? You just upgraded Fedora from 29 to 30 with SELinux in enforcing, or did also some migration? 

Dakujem,
Lukas.

Hello,

this is a long time history, so I do not remember what was the selinux state on this machine from the beginning. I do not remember the first fedora version installed. There were many upgrades maybe from early fedora releases. And I think the first ones with selinux disabled. On hardware upgrades there ware cpio copying to the new disks. But the second affected machine was first installed no more than 2 years back using the most recent fedora installation disk available. With selinux always on. So it could be Fedora 27 -> 28 -> 29 -> 30 or maybe starting from fedora 28. I always use dnf --releasever=${next-release} distro-sync. (Or yum --releasever=... upgrade or similar previously.) I am sure, I have not skipped any version on that machine. The result was I got many directories in the root directory, which were unlabeled. The second affected machine was an install on the external usb disk with uefi boot loader. Nothing special I can remember.

I recently discovered also /var was not labelel, so I labeled it var_t. I also noticed, on the second machine the user was unconfined_u, the rest of the machines had user system_u.

Also I found out the label of he /proc of the running system is proc_t. By the workaround found out I set up root_t on the real filesystem. Which one is more suitable? I found out there is no specification in file_contexts.

Therefore it is straightforward this is not a problem of selinux-policy. Which component should this problem be moved to? I think fixfiles on the root filesystem should be run prior to mounting other filesystems when .autorelabel file exists. So systemd should be the target?

Tiež ďakujem (also many thanks),

Marek.

(In reply to Marek Greško from comment #19)
> Hello,
> 
> this is a long time history, so I do not remember what was the selinux state
> on this machine from the beginning. I do not remember the first fedora
> version installed. There were many upgrades maybe from early fedora
> releases. And I think the first ones with selinux disabled. On hardware
> upgrades there ware cpio copying to the new disks. But the second affected
> machine was first installed no more than 2 years back using the most recent
> fedora installation disk available. With selinux always on. So it could be
> Fedora 27 -> 28 -> 29 -> 30 or maybe starting from fedora 28. I always use
> dnf --releasever=${next-release} distro-sync. (Or yum --releasever=...
> upgrade or similar previously.) I am sure, I have not skipped any version on
> that machine. The result was I got many directories in the root directory,
> which were unlabeled. The second affected machine was an install on the
> external usb disk with uefi boot loader. Nothing special I can remember.
> 

Okay, this should be fine. The issue is that I cannot reproduce your issue. 


> I recently discovered also /var was not labelel, so I labeled it var_t. I
> also noticed, on the second machine the user was unconfined_u, the rest of
> the machines had user system_u.
> 

Users by default are labeled as unconfined_u, objects on system should have system_u.

> Also I found out the label of he /proc of the running system is proc_t. By
> the workaround found out I set up root_t on the real filesystem. Which one
> is more suitable? I found out there is no specification in file_contexts.
> 
> Therefore it is straightforward this is not a problem of selinux-policy.
> Which component should this problem be moved to? I think fixfiles on the
> root filesystem should be run prior to mounting other filesystems when
> .autorelabel file exists. So systemd should be the target?
> 

You don't need to do it by yourself, it should be handled by policy. 

Please run:

# fixfiles -F onboot
# reboot

After reboot, everything should be working fine, if not, please let me know. 

> Tiež ďakujem (also many thanks),
> 

;) 
Lukas.


> Marek.

Hello Lukas,

with fixfiles -F onboot i get same results as when creating .autorelabel. The labels are not fixed since it is too late to run it. There are two possibilities:

1. Fix labels on root filesystems prior to mounting other filesystems
2. Run mount -o bind / /tmp/something, relabel it and umount.

Moreover, the bug 1525641 is also triggered. I have to run restorecon -R -v . in /var/named/chroot to fix it.

The steps to reproduce it:

mount -o bind / /mnt
cd /mnt
unlabel dev sys tmp var proc and other previously mentioned filesystems if possible - I am not aware how to unlabel - if not possible try to relabel to something which should cause problems
umount /mnt
reboot

Thanks

Marek

Hello,

when I run:
mount -o bind / /mnt
ls -Zd /proc
system_u:object_r:proc_t:s0 /proc
ls -Zd /mnt/proc
system_u:object_r:root_t:s0 /mnt/proc

Which one label is correct for /mnt/proc? Should I relabel to proc_t or leave it root_t?

Thanks

Marek

+1 ... might be related to #1663040

I'll mark this as depending on #1467103 because we clearly need a better way to do relabels.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.