ejabberd and name_bind
by Randy Barlow
Greetings!
The ejabberd Fedora package has its own SELinux policy module that it
ships[0]. A user has reported an issue with an SELinux denial with the
default ejabberd config[1].
I spent some time trying to modify the policy to allow the name_bind on
the port, but it seems that my attempts result in it still being
denied:
allow ejabberd_t unreserved_port_t:udp_socket name_bind;
As I commented on the ticket, I also found that setting the nis_enabled
bool on my system to true would solve the problem.
However, I think it would be ideal if I could adjust the ejabberd
module to do this on the users' behalf, as it is not obvious to the
average user (or even to me) that this boolean could be the solution to
the problem.
Is there something I could adjust in the ejabberd policy that would
resolve this issue? Thanks.
[0]
https://src.fedoraproject.org/rpms/ejabberd/blob/rawhide/f/ejabberd.te
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1901466
1 year, 9 months
- 2
- 2
machinectl not working
by Louis Seubert
Hello there,
I'm trying to start a new systemd-container with machinectl which gives me an error like:
Job for systemd-nspawn(a)fedora-33-dev.service failed because the control process exited with error code.
See "systemctl status systemd-nspawn(a)fedora-33-dev.service" and "journalctl -xeu systemd-nspawn(a)fedora-33-dev.service" for details.
In the journal is nothing really interesting just:
Aug 12 09:27:08 desktop-louis systemd-nspawn[4937]: Failed to register machine: Access denied
Aug 12 09:27:08 desktop-louis systemd-nspawn[4940]: Parent died too early
Now if I set se linux to permissive, it work without any problems but I get the following if I lookup the selinux logs:
SELinux is preventing systemd-machine from search access on the directory 4940.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that systemd-machine should be allowed search access on the 4940 directory 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:
# ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine
# semodule -X 300 -i my-systemdmachine.pp
Additional Information:
Source Context system_u:system_r:systemd_machined_t:s0
Target Context system_u:system_r:unconfined_service_t:s0
Target Objects 4940 [ dir ]
Source systemd-machine
Source Path systemd-machine
Port <Unknown>
Host <Unknown>
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch
Local Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name desktop-louis
Platform Linux desktop-louis 5.13.8-200.fc34.x86_64 #1 SMP
Wed Aug 4 19:59:54 UTC 2021 x86_64 x86_64
Alert Count 1
First Seen 2021-08-12 09:27:08 CEST
Last Seen 2021-08-12 09:27:08 CEST
Local ID 0ded547d-2c08-4e48-a664-159ec9c9675b
Raw Audit Messages
type=AVC msg=audit(1628753228.555:412): avc: denied { search } for pid=846 comm="systemd-machine" name="4940" dev="proc" ino=65001 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=0
Hash: systemd-machine,systemd_machined_t,unconfined_service_t,dir,search
If I then look up the (presumably inode number 4940) with sudo find / -inum 4940, I get the following:
/sys/kernel/tracing/events/compaction/mm_compaction_kcompactd_wake/hist
/sys/kernel/debug/tracing/events/compaction/mm_compaction_kcompactd_wake/hist
/sys/fs/cgroup/user.slice/user-1000.slice/user(a)1000.service/init.scope/cgroup.events
/sys/firmware/acpi/interrupts/gpe13
/usr/share/app-info/icons/fedora/64x64/org.fedoraproject.google-noto-serif-fonts.png
Now here comes my question, how should I continue with this problem and where should I report this problem to.
Ps. Sorry if I made something wrong fist time using a mailing list.
Thanks
Louis
1 year, 9 months
- 1
- 0
- ← Newer
- 1
- Older →