Hello, I run a Fedora 35 server and would like setroubleshootd to send email alerts for avc denials, but I'm having trouble configuring this due to the apparent lack of support for configuring an smtp password.
The out of the box setroubleshoot.conf sets
> smtp_host = localhost
> smtp_port = 25
> from_address = SELinux_Troubleshoot
, but there is no config parameter for smtp password.
For this to actually work on a machine acting as an MTA (I have postfix running locally), the mail server would have to be configured to allow unauthenticated port 25 connections to masquerade as any local system user, which no decent postfix setup would allow.
I am not a python programmer, but in my reading of https://pagure.io/setroubleshoot/blob/main/f/framework/src/setroubleshoot/e…, it doesn't appear there is any built in way to support authenticated email sending despite the underlying smtplib being able to do it.
I would suggest either a) adding password support for smtplib, or/and b) adding an option to send mail using the sendmail binary, which allows postfix to recognize the running user without any password needed.
Has anyone else run into problems deploying the setroubleshootd email alerts in practice? email_alert.py appears simple enough to hack in password support, but I feel a security oriented project like selinux shouldn't require an insecure mail setup in order to send its alerts.
Any tips are welcome,
Thanks,
Matt
Hi folks,
setenforce allows users to swap selinux mode between enforcing and
permissive.
If I want my selinux to stay in enforcing mode forever so that nobody is
able to interfere with my selinux.
What should I do?
Thanks.
---henry
Certmonger allows for the configuration of a post-save command to be run after it has obtained new certificates. This can be used to copy the key & certificates out of wherever certmonger is allowed to put them, and save them elsewhere with a particular owner/group, combine the certificate & chain into a single file as required by some software, etc.
The problem comes with SELinux which prevents my post-save scripts from being able to do all of that. I thought the solution was to give the scripts the context of certmonger_unconfined_exec_t, which would cause a transition to the certmonger_unconfined_t domain which is as its name suggests unconfined; but I can't get this to work.
I'm trying to use runcon to simulate certmonger executing a fake script:
# cat /tmp/fakescript
#!/bin/bash
set -eu
id -Z
# /tmp/fakescript
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# ls -Z /tmp/fakescript
unconfined_u:object_r:certmonger_unconfined_exec_t:s0 /tmp/fakescript
# runcon system_u:system_r:certmonger_t:s0 /tmp/fakescript
runcon: ‘/tmp/fakescript’: Permission denied
Here is the avc denial:
----
type=PROCTITLE msg=audit(27/04/21 16:16:47.156:153492) : proctitle=runcon system_u:system_r:certmonger_t:s0 /tmp/fakescript
type=SYSCALL msg=audit(27/04/21 16:16:47.156:153492) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x7ffd8aa768ab a1=0x7ffd8aa75888 a2=0x7ffd8aa75898 a3=0x0 items=0 ppid=177795 pid=177796 auid=sam.admin uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=103 comm=runcon exe=/usr/bin/runcon subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(27/04/21 16:16:47.156:153492) : avc: denied { entrypoint } for pid=177796 comm=runcon path=/tmp/fakescript dev="dm-0" ino=33563064 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:certmonger_unconfined_exec_t:s0 tclass=file permissive=0
Even though:
# sepolicy transition -s certmonger_t -t certmonger_unconfined_t
certmonger_t @ certmonger_unconfined_exec_t --> certmonger_unconfined_t
Diving in a little deeper, I can see that certmonger can execute the file:
# sesearch -s certmonger_t -t certmonger_unconfined_exec_t -c file -p execute -A
allow certmonger_t certmonger_unconfined_exec_t:file { execute execute_no_trans getattr ioctl map open read };
... and that the file type is an entrypoint for the certmonger_unconfined_t domain:
# sesearch -s certmonger_unconfined_t -t certmonger_unconfined_exec_t -c file -p entrypoint -A
allow certmonger_unconfined_t certmonger_unconfined_exec_t:file { entrypoint execute getattr ioctl lock map open read };
... and that transition is permitted from certmonger_t:
# sesearch -s certmonger_t -t certmonger_unconfined_t -c process -p transition -A
allow certmonger_t certmonger_unconfined_t:process transition;
Which leaves me scratching my head, unsure why it doesn't work in practice...
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
Hi Folks,
I want to trace policy triggered by a process from the command line. Tried
ps -Z $(pgrep cmd) ----> cmd is either command or executable file name
But it does not pick up any policy type.
Any suggestions?
Thanks.
----henry
I would really appreciate some SELinux expertise with this issue. There
is a little more discussion in the report.
Thanks,
Orion
-------- Forwarded Message --------
Subject: [Bug 2170630] New: SELinux is preventing zabbix_agentd from
'getattr' accesses on the file /proc/kcore.
Date: Thu, 16 Feb 2023 20:25:15 +0000
From: bugzilla(a)redhat.com
To: orion(a)nwra.com
https://bugzilla.redhat.com/show_bug.cgi?id=2170630
Bug ID: 2170630
Summary: SELinux is preventing zabbix_agentd from 'getattr'
accesses on the file /proc/kcore.
Product: Fedora
Version: 37
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:c24d6bdbf305be68dc05545d71227a8d033fc8ba37b3
982373781ae7fc12670e;VARIANT_ID=workstation;
Component: zabbix
Assignee: gwync(a)protonmail.com
Reporter: b.gatessucks(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: bennie.joubert(a)jsdaav.com, dan(a)danny.cz,
gwync(a)protonmail.com, orion(a)nwra.com
Target Milestone: ---
Classification: Fedora
Description of problem:
SELinux is preventing zabbix_agentd from 'getattr' accesses on the file
/proc/kcore.
***** Plugin catchall (100. confidence) suggests
**************************
If you believe that zabbix_agentd should be allowed getattr access on
the kcore
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:
# ausearch -c 'zabbix_agentd' --raw | audit2allow -M my-zabbixagentd
# semodule -X 300 -i my-zabbixagentd.pp
Additional Information:
Source Context system_u:system_r:zabbix_agent_t:s0
Target Context system_u:object_r:proc_kcore_t:s0
Target Objects /proc/kcore [ file ]
Source zabbix_agentd
Source Path zabbix_agentd
Port <Unknown>
Host (removed)
Source RPM Packages Target RPM Packages SELinux
Policy RPM selinux-policy-targeted-37.19-1.fc37.noarch
Local Policy RPM zabbix-selinux-6.0.8-1.fc37.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name (removed)
Platform Linux (removed) 6.1.11-200.fc37.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Feb 9 19:20:24 UTC 2023
x86_64
x86_64
Alert Count 6
First Seen 2023-02-15 20:44:35 GMT
Last Seen 2023-02-16 19:44:35 GMT
Local ID a7f07d90-52c4-48bf-b944-2dbf3b82932b
Raw Audit Messages
type=AVC msg=audit(1676576675.836:523): avc: denied { getattr } for
pid=5913
comm="zabbix_agentd" path="/proc/kcore" dev="proc" ino=4026532075
scontext=system_u:system_r:zabbix_agent_t:s0
tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file permissive=0
Hash: zabbix_agentd,zabbix_agent_t,proc_kcore_t,file,getattr
Version-Release number of selected component:
selinux-policy-targeted-37.19-1.fc37.noarch
Additional info:
component: zabbix
reporter: libreport-2.17.4
hashmarkername: setroubleshoot
kernel: 6.1.11-200.fc37.x86_64
type: libreport
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2170630
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/