Repeated selinux security alerts on dev="proc" + other selinux errors in logs (including setroubleshoot/audit_data.py error?) -> F42 with public facing web site (LAMP) with a Nextcloud server

[bockeman (Bob Warren)]

I get repeated SELinux alerts, as many as 20 a day, always in multiples of 4, sometimes 100s day.
I troubleshoot the alert and as advised do

ausearch -c 'admin' --raw | audit2allow -M my-admin
semodule -X 300 -i my-admin.pp

However, I have learned not to expect much from this because the affected files/folders are under /proc
and therefore transitory.

ausearch -c 'admin' --raw | tail -4
type=AVC msg=audit(1747062997.287:1829): avc:  denied  { search } for  pid=10235 comm="admin" name="13419" dev="proc" ino=67936 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=dir permissive=1
type=AVC msg=audit(1747063007.319:1830): avc:  denied  { read } for  pid=10235 comm="admin" name="comm" dev="proc" ino=67983 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=file permissive=1
type=AVC msg=audit(1747063007.319:1831): avc:  denied  { open } for  pid=10235 comm="admin" path="/proc/13419/comm" dev="proc" ino=67983 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=file permissive=1
type=AVC msg=audit(1747063007.319:1832): avc:  denied  { getattr } for  pid=10235 comm="admin" path="/proc/13419/comm" dev="proc" ino=67983 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=file permissive=1

This problem has persisted for many months, through several OS upgrades (F40,F41,F42), and program updates.
I have web searched for all related key words and attempted many “adjustments” and “tidy ups”, all to no avail.
The nearest I came to somethling relevant was

Repeated security messages from SELinux

Since the execheap issue is the only one remaining here (and we now know with high certainty that it is a separate issue), and since the execheap case is now mostly centralized in another topic, I suggest to consider this one solved and focus the execheap stuff in the other topic: People with execheap denials might follow there, primarily beginning with post 30 Thanks for making us aware and providing so much information @emanuc !

I have clearly not understood the root cause of the problem and I do not understand what the system log means.

/var/log/messages
  May 12 15:22:17 vericalm audit[10235]: AVC avc:  denied  { search } for  pid=10235 comm="admin" name="13419" dev="proc" ino=67936 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=dir permissive=1
  May 12 15:22:19 vericalm setroubleshootd[14399]: libsepol.context_from_record: invalid security context: "unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023"
  May 12 15:22:19 vericalm setroubleshootd[14399]: libsepol.context_from_record: could not create context structure
  May 12 15:22:19 vericalm setroubleshootd[14399]: libsepol.context_from_string: could not create context structure
  May 12 15:22:19 vericalm setroubleshootd[14399]: libsepol.sepol_context_to_sid: could not convert unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 to sid
  May 12 15:22:19 vericalm setroubleshoot[14399]: Unable to process audit event: cannot access local variable 'syslog' where it is not associated with a value
  May 12 15:22:19 vericalm setroubleshoot[14399]: Traceback (most recent call last):
  May 12 15:22:19 vericalm setroubleshoot[14399]:  File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 1106, in compute_avcs
  May 12 15:22:19 vericalm setroubleshoot[14399]:    avcs.append(AVC(audit_event, record))
  May 12 15:22:19 vericalm setroubleshoot[14399]:                ~~~^^^^^^^^^^^^^^^^^^^^^
  May 12 15:22:19 vericalm setroubleshoot[14399]:  File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 675, in __init__
  May 12 15:22:19 vericalm setroubleshoot[14399]:    self.derive_avc_info_from_audit_event(avc_record)
  May 12 15:22:19 vericalm setroubleshoot[14399]:    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  May 12 15:22:19 vericalm setroubleshoot[14399]:  File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 1027, in derive_avc_info_from_audit_event
  May 12 15:22:19 vericalm setroubleshoot[14399]:    raise AVCError(_("%s \n**** Invalid AVC: bad target context ****\n") % self.avc_record)
  May 12 15:22:19 vericalm setroubleshoot[14399]: setroubleshoot.audit_data.AVCError: node=vericalm type=AVC msg=audit(1747059737.265:964): avc:  denied  { search } for  pid=10235 comm="admin" name="13419" dev="proc" ino=67936 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=dir permissive=1
  May 12 15:22:19 vericalm setroubleshoot[14399]: 
  May 12 15:22:19 vericalm setroubleshoot[14399]: **** Invalid AVC: bad target context ****
  May 12 15:22:19 vericalm setroubleshoot[14399]: During handling of the above exception, another exception occurred:
  May 12 15:22:19 vericalm setroubleshoot[14399]: Traceback (most recent call last):
  May 12 15:22:19 vericalm setroubleshoot[14399]:  File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 1108, in compute_avcs
  May 12 15:22:19 vericalm setroubleshoot[14399]:    syslog.syslog(syslog.LOG_ERR, "%s" % e)
  May 12 15:22:19 vericalm setroubleshoot[14399]:    ^^^^^^
  May 12 15:22:19 vericalm setroubleshoot[14399]: UnboundLocalError: cannot access local variable 'syslog' where it is not associated with a value

My SELinux level is permissive. I am running several machines on F42, but the only machine affected is the
one which serves a public facing web site (LAMP) with a Nextcloud server. Everything is latest stable version.
I cannot think of a change that may have introduced the problem,
and I cannot even ascertain when the problem first started because of multiple much more severe problems.
This is a live system which is subject to a host of real world issues:

• Thousands of attempted hacks per day.
• Power outages (a handful per year).
• Hardware component failures (all recoverable because of redundancy).
• Corrupt databases and similar (again all recoverable).
• System administrator user error (yes, I’m the culprit, e.g. accidentally deleting a critical s/w component).

[bockeman (Bob Warren)]

Chris @py0xc3, you provided Emanuele with much help with their Related post
I wonder if you could guide me into changing the title, posting elsewhere, or anything else that could get me some help.
Thanks in advance.

[py0xc3 (Chris)]

I cannot invest much time at the moment, but at first glance, I don’t think your issue has a relation to the one you refer to. Especially the second output you mention looks to me that there is some issue that goes beyond average selinux policies. I would have considered a bug in a python script, but I think many more people would have experienced that. So my first guess would be that something has been misconfigured or damaged at some time or so (but that is a very implicit guess based on many unproven assumptions). Do you have external repositories? So third party repos? Or software/configurations installed by other means?

Can you provide a log of a corrupted boot? So a boot in which all the issues you refer to occurred. In order to save time, it would be good if you provide a link (provide a link to an external file with the data or put it into a code box, see the </> button → do not just copy/paste it!). I would need the outputs (separated files / code boxes) of the following to have a skim:
sudo journalctl -r --boot=0
sudo journalctl -r -k --boot=0
cat /proc/sys/kernel/tainted
→ if the corrupted boot is the current one, use --boot=0 in the above commands, but if the corrupted boot is the last boot, then use --boot=-1. This applies to all commands above.

Also, please explain what you mean with that:

@bockeman

This is a live system which is subject to a host of real world issues:

• Thousands of attempted hacks per day.
• Power outages (a handful per year).
• Hardware component failures (all recoverable because of redundancy).
• Corrupt databases and similar (again all recoverable).
• System administrator user error (yes, I’m the culprit, e.g. accidentally deleting a critical s/w component).

---

@bockeman

which serves a public facing web site (LAMP) with a Nextcloud server

Can you give details about that? What exactly is running on the very machine? What has been changed compared to defaults? That sounds like something that might has needed system changes that could have caused such issues.

---

I cannot make promises and cannot invest much more time, but maybe I see something that catches my eyes to indicate a direction or so. Btw, I presume you use F42 server edition?

---

In any case, a re-installation might be a worst case solution, and then check beginning from the default Fedora, change by change, when the issue starts to occur. Especially if external stuff (I could imagine the lamp/nextcloud stuff is external and not from Fedora repos?), there is a chance that the origin of the problem is not in Fedora, and that available experiences about it might be limited.

@bockeman

My SELinux level is permissive

Keep in mind that a major preventative security system is disabled that way, especially something you should keep in mind if a server provides services on the Internet or other untrusted networks.

[glb (Gregory Lee Bartholomew)]

@bockeman

I have clearly not understood the root cause of the problem and I do not understand what the system log means.

@bockeman

audit[10235]: AVC avc: denied { search } for pid=10235 comm="admin" name="13419" dev="proc" ino=67936 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=dir

In essence, the above message means SELinux thinks some process is doing (or attempting to do) something unusual. It might be that you intend your system to do something novel. Or it might be malware. Only you, as the system administrator, would be able to make that determination for sure.

The executable that is doing suspicious/unusual things is named admin and it appears to have been loaded into memory by the httpd daemon (your web server). I would start by running find <path-to your-website-content> -name 'admin' to see if you can locate the executable that is setting off SELinux.

[pg-tips (P G)]

@glb

In essence, the above message means SELinux thinks some process is doing (or attempting to do) something unusual.

At a guess, maybe this admin executable is trying to inspect all the running processes on the system? (This specific one highlighted in the messages results in an SELinux denial because the target process is of type gnome_atspi_t - something related to GNOME accessibility services - but I’d guess that admin is trying to look at all processes rather than selectively that one.)

[bockeman (Bob Warren)]

@py0xc3

I cannot invest much time at the moment, but at first glance, I don’t think your issue has a relation to the one you refer to. Especially the second output you mention looks to me that there is some issue that goes beyond average selinux policies. I would have considered a bug in a python script, but I think many more people would have experienced that. So my first guess would be that something has been misconfigured or damaged at some time or so (but that is a very implicit guess based on many unproven assumptions). Do you have external repositories? So third party repos? Or software/configurations installed by other means?

I much appreciate the time you have already spent on this and are able to going forward.

Thanks for broadening out the title, though I’d hope this could be made more succinct when the root cause is better understood.

I concur with your guess that something may have been misconfigured or damaged at some time. I’ve not knowingly messed with anything related to SELinux, on the basis of “If it’s not broken, don’t fix it”. But if I have accidentally caused this behaviour or some event outside my control, like a power cut, has damaged something, then this could happen to anyone. Hence I appreciate any suggestions to help debug and resolve this, as would others who may fall prey to similar.

I don’t think I have any unusual external repositories. Those like Adobe and NVIDIA are legacy from many years past and I doubt are related to this issue.

dnf repolist
repo id                                             repo name                                                      
adobe-linux-x86_64                                  Adobe Systems Incorporated                                     
fedora                                              Fedora 42 - x86_64                                             
fedora-cisco-openh264                               Fedora 42 openh264 (From Cisco) - x86_64                       
rpmfusion-free                                      RPM Fusion for Fedora 42 - Free                                
rpmfusion-free-updates                              RPM Fusion for Fedora 42 - Free - Updates                      
rpmfusion-nonfree                                   RPM Fusion for Fedora 42 - Nonfree                             
rpmfusion-nonfree-nvidia-driver                     RPM Fusion for Fedora 42 - Nonfree - NVIDIA Driver             
rpmfusion-nonfree-updates                           RPM Fusion for Fedora 42 - Nonfree - Updates                   
updates                                             Fedora 42 - x86_64 - Updates                                   
updates-archive                                     Fedora 42 - x86_64 - Updates Archive

Nextcloud is installed and upgraded outside dnf.

@py0xc3

Can you provide a log of a corrupted boot? So a boot in which all the issues you refer to occurred. In order to save time, it would be good if you provide a link (provide a link to an external file with the data or put it into a code box, see the </> button → do not just copy/paste it!). I would need the outputs (separated files / code boxes) of the following to have a skim:
sudo journalctl -r --boot=0
sudo journalctl -r -k --boot=0
cat /proc/sys/kernel/tainted

I don’t think the problem is boot related. I’ve rebooted several times in my futile attempts to narrow down the problem. Since last booting, I continually get setroubleshootd entries in /var/log/messages like that posted above.

journalctl -r --boot=0 | tee journalctl_r_250517.log | wc -l
  1222155
journalctl -r -k --boot=0 | tee journalctl_rk_250517.log | wc -l
  1471
cat /proc/sys/kernel/tainted
  512

journalctl_r_250517.log
journalctl_rk_250517.log

@py0xc3

Also, please explain what you mean with that:

This is a live system which is subject to a host of real world issues

The purpose of this statement was to not rule out anything from a possible cause. Your guess, above, about misconfiguration or damage, illustrates you have taken this on board.

@py0xc3

---

@bockeman

which serves a public facing web site (LAMP) with a Nextcloud server

Can you give details about that? What exactly is running on the very machine? What has been changed compared to defaults? That sounds like something that might has needed system changes that could have caused such issues.

That’s big ask, and I sure you don’t have the time to trawl lists of everything installed and all configurations on this machine. The big brush stroke is:

1. Initial install F30 in 2019

Software Selection
  Base Environment
    (*) Xfce Desktop
  Add-ons
    [ ] 3D Printing
    [ ] Cloud Management Tools
    [/] Applications for the Xfce Desktop
    [/] Extra plug-ins for the Xfce Panel
    [/] Multimedia support for Xfce
    [ ] Xfce Office
    ---
    [/] Administration Tools
    [ ] Ansible node
    [ ] Audio Production
    [ ] Authoring and Publishing
    [ ] Books and Guides
    [ ] C Development Tools and Libraries
    [ ] Cloud Infrastructure
    [ ] Compiz
    [ ] Container Management
    [ ] D Development Tools and Libraries
    [ ] Design Suite
    [ ] Development Tools
    [ ] Domain Membership
    [ ] Fedora Eclipse
    [ ] Editors
    [ ] Educational Software
    [ ] Electronic Lab
    [ ] Engineering and Scientific
    [ ] FreeIPA Server
    [ ] Games and Entertainment
    [/] Headless Management
    [ ] LibreOffice
    [ ] MATE Applications
    [ ] Medical Applications
    [ ] Milkymist
    [ ] Network Servers
    [ ] Office/Productivity
    [ ] Python Classroom
    [ ] Python Science
    [ ] Robotics
    [ ] RPM Development Tools
    [ ] Security Lab
    [ ] Sound and Video
    [/] System Tools (SMB, network monitoring)
    [ ] Text-based Internet
    [/] Window Managers

2. Install Nextcloud
3. Tweaks for NAS, etc.
4. Successive upgrades to F42 and Nextcloud

In other words, nothing more that a platform to serve Nextcloud.

Re re-installation: noted (but very very expensive)

Re SELinux permissive: noted.

[py0xc3 (Chris)]

It remains the question if you have third party repos or otherwise software installed from other soures than our default repos? I presume the Nextcloud stuff comes from somewhere else?

My guess is that Nextcloud/webserver-related stuff is not properly integrated into Fedora or something like that. Although it still makes me question your earlier output with regards to the python script, which looks to me to be a bit more than just a policy issue, plus the kernel issue in your logs (see below).

@bockeman

cat /proc/sys/kernel/tainted
  512

Your kernel has issued a warning (512). I expect this relates to this part of your logs:

May 13 00:15:11 vericalm kernel: ---[ end trace 0000000000000000 ]---
May 13 00:15:11 vericalm kernel:  </TASK>
May 13 00:15:11 vericalm kernel:  ret_from_fork_asm+0x1a/0x30
May 13 00:15:11 vericalm kernel:  ? __pfx_kthread+0x10/0x10
May 13 00:15:11 vericalm kernel:  ret_from_fork+0x34/0x50
May 13 00:15:11 vericalm kernel:  ? __pfx_kthread+0x10/0x10
May 13 00:15:11 vericalm kernel:  kthread+0xef/0x230
May 13 00:15:11 vericalm kernel:  ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
May 13 00:15:11 vericalm kernel:  cifs_demultiplex_thread+0x624/0x990 [cifs]
May 13 00:15:11 vericalm kernel:  cifs_handle_standard+0xbb/0x190 [cifs]
May 13 00:15:11 vericalm kernel:  cifs_check_trans2+0x58/0xe0 [cifs]
May 13 00:15:11 vericalm kernel:  <TASK>
May 13 00:15:11 vericalm kernel: Call Trace:
May 13 00:15:11 vericalm kernel: CR2: 0000560fbe8b6000 CR3: 00000007c482c004 CR4: 00000000001706f0
May 13 00:15:11 vericalm kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 13 00:15:11 vericalm kernel: FS:  0000000000000000(0000) GS:ffff8f5dbeb80000(0000) knlGS:0000000000000000
May 13 00:15:11 vericalm kernel: R13: ffff8f56dfd58000 R14: ffff8f56f722b800 R15: ffff8f56f722b800
May 13 00:15:11 vericalm kernel: R10: ffffffff9f936868 R11: 00000000ffffdfff R12: 0000000000002199
May 13 00:15:11 vericalm kernel: RBP: 0000000000002f00 R08: 0000000000000000 R09: ffffb99443e6fc28
May 13 00:15:11 vericalm kernel: RDX: ffff8f5dbeba1948 RSI: 0000000000000001 RDI: ffff8f5dbeba1940
May 13 00:15:11 vericalm kernel: RAX: 0000000000000000 RBX: 00000000000010cc RCX: 0000000000000027
May 13 00:15:11 vericalm kernel: RSP: 0018:ffffb99443e6fd80 EFLAGS: 00010246
May 13 00:15:11 vericalm kernel: Code: c7 c2 c8 62 3c c1 4c 89 ce 4c 89 5c 24 10 48 c7 c7 00 63 3c c1 4c 89 44 24 08 4c 89 0c 24 c6 05 08 24 04 00 01 e8 82 4f 12 dc <0f> 0b 4c 8b 5c 24 10 4c 8b 44 24 08 4c 8b 0c 24 e9 d7 fd ff ff 48
May 13 00:15:11 vericalm kernel: RIP: 0010:coalesce_t2+0x30e/0x4c0 [cifs]
May 13 00:15:11 vericalm kernel: Hardware name: Hewlett-Packard HP Compaq Elite 8300 SFF/3397, BIOS K01 v02.05 05/07/2012
May 13 00:15:11 vericalm kernel: CPU: 3 UID: 0 PID: 1535 Comm: cifsd Not tainted 6.14.5-300.fc42.x86_64 #1
May 13 00:15:11 vericalm kernel:  snd_seq_device snd_pcm pcspkr i2c_i801 i2c_smbus snd_timer mei_me pktcdvd snd e1000e mei lpc_ich soundcore tpm_infineon nfsd auth_rpcgss nfs_acl lockd grace nfs_localio sunrpc loop dm_multipath nfnetlink zram lz4hc_compress lz4_compress i915 polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 i2c_algo_bit drm_buddy ttm sha256_ssse3 drm_display_helper sha1_ssse3 serio_raw cec video wmi scsi_dh_rdac scsi_dh_emc scsi_dh_alua fuse
May 13 00:15:11 vericalm kernel: Modules linked in: snd_seq_dummy snd_hrtimer rpcsec_gss_krb5 nfsv4 nfs rpcrdma rdma_cm iw_cm ib_cm ib_core nls_utf8 cifs cifs_arc4 nls_ucs2_utils cifs_md4 dns_resolver netfs nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ebtable_nat ebtable_broute iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security nf_tables ip_set ebtable_filter ebtables ip6_tables qrtr iptable_filter ip_tables intel_rapl_msr intel_rapl_common mei_hdcp mei_wdt iTCO_wdt mei_pxp x86_pkg_temp_thermal snd_hda_codec_hdmi at24 intel_powerclamp intel_pmc_bxt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component coretemp rapl intel_cstate snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core hp_wmi snd_hwdep sparse_keymap snd_seq platform_profile wmi_bmof rfkill intel_uncore
May 13 00:15:11 vericalm kernel: WARNING: CPU: 3 PID: 1535 at fs/smb/client/smb1ops.c:364 coalesce_t2+0x30e/0x4c0 [cifs]
May 13 00:15:11 vericalm kernel: memcpy: detected field-spanning write (size 4300) of single field "data_area_of_tgt" at fs/smb/client/smb1ops.c:364 (size 0)
May 13 00:15:11 vericalm kernel: ------------[ cut here ]------------

Seems related to SMB. Looks to me that something related to smb causes trouble, but it is not clear at first glance that this is related to the SELinux denials. This could be a driver issue, can be related or not.

And of course the other issue of setsetroubleshoot:

May 17 12:05:56 vericalm setroubleshootd[653949]: libsepol.sepol_context_to_sid: could not convert unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 to sid
May 17 12:05:56 vericalm setroubleshootd[653949]: libsepol.context_from_string: could not create context structure
May 17 12:05:56 vericalm setroubleshootd[653949]: libsepol.context_from_record: could not create context structure
May 17 12:05:56 vericalm setroubleshootd[653949]: libsepol.context_from_record: invalid security context: "unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023"
May 17 12:05:56 vericalm setroubleshoot[653949]: UnboundLocalError: cannot access local variable 'syslog' where it is not associated with a value
May 17 12:05:56 vericalm setroubleshoot[653949]:     ^^^^^^
May 17 12:05:56 vericalm setroubleshoot[653949]:     syslog.syslog(syslog.LOG_ERR, "%s" % e)
May 17 12:05:56 vericalm setroubleshoot[653949]:   File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 1108, in compute_avcs
May 17 12:05:56 vericalm setroubleshoot[653949]: Traceback (most recent call last):
May 17 12:05:56 vericalm setroubleshoot[653949]: During handling of the above exception, another exception occurred:
May 17 12:05:56 vericalm setroubleshoot[653949]: **** Invalid AVC: bad target context ****
May 17 12:05:56 vericalm setroubleshoot[653949]: 
May 17 12:05:56 vericalm setroubleshoot[653949]: setroubleshoot.audit_data.AVCError: node=vericalm type=AVC msg=audit(1747479954.362:98180): avc:  denied  { open } for  pid=583724 comm="admin" path="/proc/13419/comm" dev="proc" ino=67983 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:unconfined_r:gnome_atspi_t:s0-s0:c0.c1023 tclass=file permissive=1
May 17 12:05:56 vericalm setroubleshoot[653949]:     raise AVCError(_("%s \n**** Invalid AVC: bad target context ****\n") % self.avc_record)
May 17 12:05:56 vericalm setroubleshoot[653949]:   File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 1027, in derive_avc_info_from_audit_event
May 17 12:05:56 vericalm setroubleshoot[653949]:     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
May 17 12:05:56 vericalm setroubleshoot[653949]:     self.derive_avc_info_from_audit_event(avc_record)
May 17 12:05:56 vericalm setroubleshoot[653949]:   File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 675, in __init__
May 17 12:05:56 vericalm setroubleshoot[653949]:                 ~~~^^^^^^^^^^^^^^^^^^^^^
May 17 12:05:56 vericalm setroubleshoot[653949]:     avcs.append(AVC(audit_event, record))
May 17 12:05:56 vericalm setroubleshoot[653949]:   File "/usr/lib/python3.13/site-packages/setroubleshoot/audit_data.py", line 1106, in compute_avcs
May 17 12:05:56 vericalm setroubleshoot[653949]: Traceback (most recent call last):
May 17 12:05:56 vericalm setroubleshoot[653949]: Unable to process audit event: cannot access local variable 'syslog' where it is not associated with a value

What could be an issue or an indication of one, but not sure about it, is this:

May 12 14:11:08 vericalm kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver?
May 12 14:11:08 vericalm kernel: ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20240827/utaddress-204)
May 12 14:11:08 vericalm kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver?
May 12 14:11:08 vericalm kernel: ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20240827/utaddress-204)
May 12 14:11:08 vericalm kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver?
May 12 14:11:08 vericalm kernel: ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20240827/utaddress-204)
May 12 14:11:08 vericalm kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver?
May 12 14:11:08 vericalm kernel: ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20240827/utaddress-204)

Plus the avc denials: so 4 things that could be up to 4 issues, or up to 4 manifests of the same thing. The ACPI thing is something that I would off the cuff presume to be not related (though worth to get reviewed maybe). I also would not off the cuff presume that the (driver) issue of the kernel is related to the SE issue. But always keep them in mind when investigating any of them, as it is not sure.

Maybe someone can spare the time to get deeper into this (I unforunately cannot - that would be too much to check out), or has experience with such services on Fedora to take a good guess, but the first thing I have in mind is that something that has been added to this machine (may it be by configuration or installation) is not compatible with Fedora’s (remaining) defaults, causing stability and security issues. If there is some, I tend to first search in third party software / non-default configurations for the origin.

Sorry that I cannot be of more help, but beyond the suggestion to check out change by change what the origin is (or preferably, see if others have useful experiences to get a better shortcut towards the origin), you might check out on your preferred search engines trigger from the logs, the error messages and such, especially the python3/setsetroubleshoot error and the kernel warning, maybe also the acpi issue (although I don’t think this is related, yet something that you might review). Anyway, in my post you can see what I would investigate additional to the sedenial itself.

---

Slight supplement: you said F30 at 2019, and I guess from the logs that you have third party software that causes trouble. Is there a chance that some of the software you have has not been updated since or so? Just to consider that as origin of issues and instabilities if applicable.

[bockeman (Bob Warren)]

@glb

In essence, the above message means SELinux thinks some process is doing (or attempting to do) something unusual. It might be that you intend your system to do something novel. Or it might be malware. Only you, as the system administrator, would be able to make that determination for sure.

Thanks for posting.

I’m not intending to do anything outside the norm. I try to keep things a simple as possible.

If it’s malware then I’d expect to see some evidence of a breach, and I’d execute contingency plans. Suggestions on what to look for would be appreciated.

@glb

The executable that is doing suspicious/unusual things is named admin and it appears to have been loaded into memory by the httpd daemon (your web server). I would start by running find <path-to your-website-content> -name 'admin' to see if you can locate the executable that is setting off SELinux.

My Nexcloud runs under httpd as user apache. Nextcloud users have their own logins with passwords and protections, but AFAIK these are all handled inside Nextcloud and only user apache transactions hit the system.

The Nextcloud administrative user, with extra priveleges within Nextcloud, is named admin. So a host of background jobs, launched via the user apache crontab entry:

*/5  *  *  *  * php -f /var/www/html/redacted/cron.php`

could be labelled with admin.

My presumption is that all such processes are contained within Nextcloud and user apache. There should be nothing which could surprise SELinux.

But clearly, something unusual is happening. If the Nextcloud containment is broken, then I’d like to know what so that I can bug report it against Nextcloud. How do I narrow this down?

[bockeman (Bob Warren)]

@pg-tips

@glb

In essence, the above message means SELinux thinks some process is doing (or attempting to do) something unusual.

At a guess, maybe this admin executable is trying to inspect all the running processes on the system? (This specific one highlighted in the messages results in an SELinux denial because the target process is of type gnome_atspi_t - something related to GNOME accessibility services - but I’d guess that admin is trying to look at all processes rather than selectively that one.)

Thanks for posting.

I went down the route of suspecting gnome_atspi. After all, this is a headless machine and I don’t need any Assistive Technology.

So I uninstalled at-spi2-core. Unfortunately this was a bad move because far too many apps rely on atspi to function, including the window manager itself, xfce. I was unable to successfully re-install and reconfigure all the affected components, so ended up winding back to prior system backup. I’m assuming the issue is not related to atspi and this is a red-herring.

Let’s suppose that Nextcloud via the apache cron job is attempting to look at all processes. Would that be a problem and why?

[pg-tips (P G)]

@bockeman

I’m assuming the issue is not related to atspi and this is a red-herring.

Yes, I suspect atspi isn’t special here. If I do ls -alZ /proc on my system, I can see a variety of different SELinux types for different processes. You may well find the same issue for some of those.

@bockeman

Let’s suppose that Nextcloud via the apache cron job is attempting to look at all processes. Would that be a problem and why?

Ultimately it depends on what you trust. Personally, I’d say that having a web server (especially one that can incorporate various third party plugins) know everything that’s running on my system goes uncomfortably beyond “need to know”, but it’s a matter of opinion.

(It would certainly go outside your expectation that all the apache user’s processes should be confied within Nextcloud.)

FYI here’s a similar issue someone had where their audit tool had SELinux denials trying to inspect all the processes on the system: https://unix.stackexchange.com/questions/767564/selinux-denies-to-access-file-in-proc

[bockeman (Bob Warren)]

@py0xc3

It remains the question if you have third party repos or otherwise software installed from other soures than our default repos? I presume the Nextcloud stuff comes from somewhere else?

My guess is that Nextcloud/webserver-related stuff is not properly integrated into Fedora or something like that. Although it still makes me question your earlier output with regards to the python script, which looks to me to be a bit more than just a policy issue, plus the kernel issue in your logs (see below).

Again, thanks for your insights. Clearly your expertise goes well beyond mine.

Nextcloud [server] is now integrated into Fedora:

dnf info nextcloud
Updating and loading repositories:
Repositories loaded.
Available packages
Name           : nextcloud
Epoch          : 0
Version        : 31.0.4
Release        : 1.fc42
Architecture   : noarch
Download size  : 185.6 MiB
Installed size : 749.8 MiB
Source         : nextcloud-31.0.4-1.fc42.src.rpm
Repository     : updates
Summary        : Private file sync and share server
URL            : http://nextcloud.com
License        : AGPL-3.0-or-later AND LicenseRef-Callaway-MIT AND LicenseRef-Callaway-BSD AND Apache-2.0 AND WTFPL AND LicenseRef-Callaway-CC-BY-SA AND GPL-3.0-or-later AND A
               : dobe-2006
Description    : NextCloud gives you universal access to your files through a web interface or
               : WebDAV. It also provides a platform to easily view & sync your contacts,
               : calendars and bookmarks across all your devices and enables basic editing right
               : on the web. NextCloud is extendable via a simple but powerful API for
               : applications and plugins.
Vendor         : Fedora Project

and indeed the same version as I am currently using (as I have just found out). So there is an argument that I could and should migrate to using the official Fedora integration. Noted, will do, but not now. But I don’t think the SELinux issue is related to how Nextcloud has been installed/integrated, unless you suggest something for me to explore that could reveal a reason.

I believe the SMB issue is unrelated, unless again you suggest otherwise. There is some legacy software running on a legacy version of Windows with no migration route. I need to serve data from that legacy machine, so I copy it nightly via a cifs mount. This is a real world “feature”. The legacy software is not perfect and occasionally crashes requiring a machine reboot. This Nextcloud server, vericalm, obviously complains if a data transfer via cifs is attempted while the legacy windows machine is offline.

The python scripts are part of the standard SELinux provision, AFAIK. I do not have the skills to drill down into the SELinux python code to determine the cause of

could not create context structure

nor

cannot access local variable 'syslog'

At the very least it looks like the present code has not anticipated the situation that causes this untidy and unhelpful response (i.e. a bug in the code). If so, I could do with some help in formulating the bug report.

Might I suggest that the 4 AVC denials are related to the 4 operations that are attempted, namely search read open and getattr, and this relates a single underlying issue like

could not create context structure

Thanks for your input to date. As you haven’t the time, perhaps that would give someone else head start on further diagnosis.

I don’t suspect lack of updates on my part to be a problem. I’m not sure what you count as third party software, even if you think of Nextcloud as third party, it is now integrated into Fedora (though I have not yet switched). I don’t think I have any third part software.

Another possibility occurs to me. All the software, from the kernel upwards, is continually evolving, including deprecation of certain API features. (Some of the Apps inside Nextcloud have been caught by this). If an update to some software has not been made available, then that could cause a problem. But what and which?

[bockeman (Bob Warren)]

@pg-tips

FYI here’s a similar issue someone had where their audit tool had SELinux denials trying to inspect all the processes on the system: https://unix.stackexchange.com/questions/767564/selinux-denies-to-access-file-in-proc

Potentially useful, thanks.
But the solution

semanage permissive -a auditd_t

would make no difference to me as I’m running SELinux in permissive mode. Plus, that does not stop the flood of messages in /var/log/audit/audit.log

[richiedaze]

What is the installation process you applied to create this server?

[glb (Gregory Lee Bartholomew)]

@bockeman

The Nextcloud administrative user, with extra priveleges within Nextcloud, is named admin. So a host of background jobs, launched via the user apache crontab entry:

*/5  *  *  *  * php -f /var/www/html/redacted/cron.php`

could be labelled with admin.

When SELinux reports comm="admin", it means that there is a command/executable on the filesystem somewhere with that filename that is trying to perform the suspicious act. If you can locate the file, you might find that it is a plain-text script (use file <path-to-file> to be sure) and you might be able to open it up with a text editor to find out more about it. Another possibility is that it is part of a RPM. If so, rpm -qf <path-to-file> would tell you what RPM package the file belongs to and you could search for similar reports in that program’s bug tracker.

[bockeman (Bob Warren)]

@richiedaze

What is the installation process you applied to create this server?

Thanks for chipping in.
I’m not sure I understand the question, or more precisely what you hope to glean that could help with the problem, but here goes:
In 2019, F30 was installed from a f30_netinst PXE boot with

rd.live.image rd.lvm=0 rd.luks=0 rd.md=0 rd.dm=0 inst.vnc

[bockeman (Bob Warren)]

@glb

When SELinux reports comm="admin", it means that there is a command/executable on the filesystem somewhere with that filename that is trying to perform the suspicious act.

Under /usr /etc /var I found one admin file which file revealed as an [ELF] executable, unchanged since 2005, which I trust and know does not trawl through /proc.

Which leads to the question what is this admin that SELinux is reporting?

Could an executable or a script, even a php, be created on-the-fly and that be executed? There’s 1841 files under /var/www/html/nextcloud that contain " admin "?

Could SELinux be confused, and it’s reporting comm="admin" in error?

Could the message libsepol.context_from_string: could not create context structure indicate that some SELinux files have been corrupted?

[glb (Gregory Lee Bartholomew)]

@bockeman

Under /usr /etc /var I found one admin file which file revealed as an [ELF] executable, unchanged since 2005, which I trust and know does not trawl through /proc.

That is likely the command that SELinux is reporting. What package is it part of? Is that command executed by the httpd daemon for some reason?

@bockeman

Could SELinux be confused, and it’s reporting comm="admin" in error?

There are ways to “spoof” the command name in Linux. I wouldn’t expect SELinux to fall for that, but I’m not sure.

[bockeman (Bob Warren)]

@glb

That is likely the command that SELinux is reporting. What package is it part of? Is that command executed by the httpd daemon for some reason?

That admin is part of revision control, which is in constant use, but which I have suspended for the time being. And to prove that admin is not involved I have temporarily renamed it.

/bin/mv -v /usr/libexec/cssc/{admin,nimda}

but I am still getting the same AVC denials.

[richiedaze]

Can you please post the output of these two commands:
sudo semanage fcontext -l | grep httpd_sys_script_
sudo semanage fcontext -l | grep gnome_atspi_

The t is left off intentionally.

[glb (Gregory Lee Bartholomew)]

@bockeman

And to prove that admin is not involved I have temporarily renamed it.

I’m not sure a rename of the file would be enough to prove that it isn’t the file generating the SELinux alerts. It is possible that the executable is still loaded in memory with the earlier name, even though the on-disk name for the file has been changed. If you run ps -ef | grep admin do you see anything listed besides the ps command itself?

@bockeman

Could an executable or a script, even a php, be created on-the-fly and that be executed?

That is possible, yes. It is also possible that someone has uploaded such a script to your website.