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 analyze audit.log and see
arch=c00000b7 syscall=35
Where can I find what c00000b7 and 35 mean respectively for arm64 device?
Thanks.
---henry
Greetings,
I have a custom policy that has a label for a directory and all its
contents, except for one specific sub-directory that uses a more
specific type. When a file is created in that sub-directory, it gets
the general label instead of the specific one.
It looks wrong, and at least restorecon seems to agree because it will
happily relabel the offending file, meeting my expectations. I must be
doing something wrong, probably missing something, but I have no idea
what.
Or could it be a bug? The kernel module could be evaluating rules in a
different order, hence the discrepancy at file creation time. In my
policy file contexts are sorted from least to most specific.
Anyway, I can't share that, so I made a minimal reproducer:
https://github.com/dridi/selinux-lostlabel
Any help appreciated, I tried really hard to understand what is going
on, to no avail. The only similar search result was wrong labels in
home directories showing up in several places but I couldn't find my
nugget there.
I initially sent an email and it's not showing up in the archive, so
instead I subscribed to the list and started a new thread using the
Hyperkitty interface. Apologies in advance if you receive it twice.
Thanks,
Dridi
Il 2023-05-19 18:56 Casper ha scritto:
> With audit2allow, you can read from "auditd" logs then try to generate
> the .te file, then compile it into a Module Policy.
>
> If you know how to write Type Enforcement[1] (.te) file, you will have
> to compile it manually into a loadable Module Policy file. This step
> is done automatically by audit2allow.
>
> """
> Module (or Non-base) Policy - These are optional policy source files
> that when compiled, can be dynamically loaded or unloaded within the
> policy store. By convention these files are named after the module or
> application they represent, with the compiled binary having a '.pp'
> extension. These files are compiled using the checkmodule command.
> """
>
> CIL modules can be used with semodule because they are compiled by
> semodule directly, at install time.[2]
>
> [1] https://selinuxproject.org/page/NB_TE
> [2] https://selinuxproject.org/page/PolicyLanguage
Thank you so much.
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
Hi all,
I have a question about mysql relocation.
I already created an equivalency rule such as "semanage fcontext --list
-C" returns the following:
SELinux Local fcontext Equivalence
/mnt/lv_data/var/lib/mysql = /var/lib/mysql
Then I created a symlink in /var/lib:
system_u:object_r:mysqld_db_t:s0 26 May 17 14:39 mysql ->
/mnt/lv_data/var/lib/mysql
However, httpd/php can not connect to the database. The following
message is logged in audit.log:
type=AVC msg=audit(1684352064.936:232): avc: denied { read } for
pid=8558 comm="httpd" name="mysql" dev="sda4" ino=147925
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:mysqld_db_t:s0 tclass=lnk_file permissive=0
My understanding is that httpd can not read the symlink. I expected to
find a boolean to allow this kind of access, to no avail.
So my question is: can I allow httpd symlink access without manually
modifying the actual policy (ie: using audit2allow and the likes)?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8