Not possible to specify smtp password for setroubleshootd?
by Matt Kinni
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..., 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
1 week, 3 days
get rid of setenforce
by Henry Zhang
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
1 week, 3 days
certmonger post-save scripts & certmonger_unconfined_t domain
by Sam Morris
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
2 weeks
Re: [CentOS-devel] Making the redhat selinux-policy repository
publicly available
by Zdenek Pytela
On Tue, Jul 11, 2023 at 10:37 PM Troy Dawson <tdawson(a)redhat.com> wrote:
> On Tue, Jul 11, 2023 at 12:50 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
>> On Tue, Jul 11, 2023 at 9:31 AM Troy Dawson <tdawson(a)redhat.com> wrote:
>> >
>> > On Tue, Jul 11, 2023 at 4:28 AM Daan De Meyer <daan.j.demeyer(a)gmail.com>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> It seems that the selinux-policy rpm is built from
>> >> git@gitlab.cee.redhat.com:SELinux/selinux-policy.git which seems to be
>> >> a redhat internal repository. More specifically, if I try to checkout
>> >> the commit listed in the selinux-policy spec
>> >> (
>> https://gitlab.com/redhat/centos-stream/rpms/selinux-policy/-/blob/c9s/se...
>> )
>> >> in the fedora-selinux repository cloned from github, I get an error
>> >> saying that the commit does not exist. It would be great if the
>> >> repository containing this commit was publicly available and open for
>> >> external contributors just like all the other packages in CentOS
>> >> Stream. Is it possible to make this happen?
>> >
>> >
>> > I'm not the selinux-policy maintainer, so I can't comment on where they
>> work on the selinux-policy source code.
>> >
>> > But this is how I get the sources, if that is what you are ultimately
>> looking for.
>> >
>> > centpkg clone selinux-policy
>> > cd selinux-policy
>> > centpkg sources
>> > or if you want to know where they really are
>> > centpkg -v sources
>> > This shows it to be coming from
>> >
>> https://sources.stream.centos.org/sources/rpms/selinux-policy/selinux-pol...
>> >
>> > The sources information is found in the sources file
>> >
>> https://gitlab.com/redhat/centos-stream/rpms/selinux-policy/-/blob/c9s/so...
>> >
>> > I know this isn't exactly what you asked for, but I hope it still helps.
>> >
>>
>> I think the idea is that having the Git repository in a public
>> location would allow the CentOS Hyperscale SIG to contribute to the
>> SELinux policy in a meaningful way.
>>
>
> Ah, ok. That makes sense.
> As I said, I'm not the maintainer so I don't know why it's where it is.
> So I'll step out of the conversation.
>
Hi,
I am one of the selinux-policy maintainers. Currently, repository for
Fedora is at github.com and RHEL sources are in an internal repo. We have
already discussed moving centos stream sources to some of the public
repositories, but it did not happen. Currently we are discussing it again,
there are a few options how to do so.
To get just the latest repository content, steps described by Troy should
work. Additionally, most of the upstream work is done in Fedora and anyway
every new commit should go to Fedora first, RHEL content is mostly a subset
of Fedora, there are very few differences.
--
Zdenek Pytela
Security SELinux team
2 months
relabelto and relabelfrom
by Henry Zhang
Hi folks,
In SELinux, relabelto and relabelfrom are terms that inform the policy if a
relabel operation (change of context) is allowed from a particular label
(context) or towards a particular label (context).
Without using them, no relabel is allowed?
Thanks.
---henry
6 months
unconfined_t access to a new file type
by Wart
I created a new policy module using sepolgen for my RL9 server to manage
the shibboleth service, then started customizing it. Part of the new
policy is a new shibboleth_etc_t file type.
This system is also using puppet to manage various config files on the
filesystem.
The shibd process, running in its shibd_t domain, is able to read this
file type with no problem, but I notice that puppet (running in the
unconfined_t domain) now generates a new AVC denial when trying to
access files of this new file type.
Do I need to explicitly allow the unconfined_t domain access to my new
file type, or is there some other piece that I'm missing?
--Mike
fc file:
/usr/sbin/shibd -- gen_context(system_u:object_r:shibd_exec_t,s0)
/etc/shibboleth(/.*)? --
gen_context(system_u:object_r:shibboleth_etc_t,s0)
/var/log/shibboleth(/.*)?
gen_context(system_u:object_r:shibboleth_var_log_t,s0)
/var/cache/shibboleth(/.*)?
gen_context(system_u:object_r:shibboleth_var_cache_t,s0)
/var/run/shibboleth -d
gen_context(system_u:object_r:shibboleth_var_run_t,s0)
/var/run/shibboleth/shibd.sock -s
gen_context(system_u:object_r:shibboleth_var_run_t,s0)
/etc/shibboleth/.*.pem -- gen_context(system_u:object_r:cert_t,s0)
/etc/shibboleth/.*pem -- gen_context(system_u:object_r:cert_t,s0)
if file:
## <summary>policy for shibd</summary>
########################################
## <summary>
## Execute shibd_exec_t in the shibd domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
## </param>
#
interface(`shibd_domtrans',`
gen_require(`
type shibd_t, shibd_exec_t;
')
corecmd_search_bin($1)
domtrans_pattern($1, shibd_exec_t, shibd_t)
')
######################################
## <summary>
## Execute shibd in the caller domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`shibd_exec',`
gen_require(`
type shibd_exec_t;
')
corecmd_search_bin($1)
can_exec($1, shibd_exec_t)
')
te file:
policy_module(local_shibd, 1.0.0)
########################################
#
# Declarations
#
require {
type httpd_t;
type var_run_t;
type cert_t;
type http_port_t;
type kernel_t;
class file { append create getattr open read rename unlink write };
class dir { add_name remove_name search write };
class tcp_socket { name_connect };
class sock_file { create setattr write };
class unix_stream_socket { connectto };
class unix_dgram_socket { create getopt sendto setopt };
}
type shibd_t;
type shibd_exec_t;
type shibboleth_etc_t;
type shibboleth_var_log_t;
type shibboleth_var_cache_t;
type shibboleth_var_run_t;
init_daemon_domain(shibd_t, shibd_exec_t)
permissive shibd_t;
########################################
#
# shibd local policy
#
allow shibd_t self:capability { setgid setuid };
allow shibd_t self:process { fork signal_perms };
allow shibd_t self:fifo_file rw_fifo_file_perms;
allow shibd_t self:unix_stream_socket create_stream_socket_perms;
domain_use_interactive_fds(shibd_t)
files_read_etc_files(shibd_t)
auth_use_nsswitch(shibd_t)
miscfiles_read_localization(shibd_t)
allow shibd_t shibboleth_etc_t:file { getattr open read };
allow shibd_t shibboleth_var_log_t:dir { add_name remove_name search
write };
allow shibd_t shibboleth_var_log_t:file { append create getattr open
read rename unlink write };
allow shibd_t cert_t:file { open read };
allow shibd_t shibboleth_var_run_t:dir { add_name remove_name search
write };
allow shibd_t shibboleth_var_run_t:sock_file { create setattr unlink };
allow shibd_t shibboleth_var_cache_t:dir { add_name remove_name search
write };
allow shibd_t shibboleth_var_cache_t:file { create getattr open read
unlink write };
allow shibd_t http_port_t:tcp_socket name_connect;
# Let apache talk to shibd and vice versa
allow httpd_t shibboleth_etc_t:file { getattr open read };
allow httpd_t shibd_t:unix_stream_socket connectto;
allow httpd_t shibboleth_var_run_t:dir search;
allow httpd_t shibboleth_var_run_t:sock_file write;
allow shibd_t kernel_t:unix_dgram_socket sendto;
allow shibd_t self:unix_dgram_socket { create getopt setopt };
The AVC denial:
----
time->Mon Dec 4 14:40:45 2023
node=llodmt.ligo-la.caltech.edu type=PROCTITLE
msg=audit(1701722445.997:630306):
proctitle=707570706574206167656E743A206170706C79696E6720636F6E66696775726174696F6E
node=llodmt.ligo-la.caltech.edu type=PATH
msg=audit(1701722445.997:630306): item=0
name="/etc/shibboleth/shibboleth2.xml" inode=17384656 dev=09:7e
mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:shibboleth_etc_t:s0 nametype=NORMAL cap_fp=0
cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
node=llodmt.ligo-la.caltech.edu type=CWD
msg=audit(1701722445.997:630306): cwd="/"
node=llodmt.ligo-la.caltech.edu type=SYSCALL
msg=audit(1701722445.997:630306): arch=c000003e syscall=257 success=yes
exit=35 a0=ffffff9c a1=7fa634a38e68 a2=80000 a3=0 items=1 ppid=2725223
pid=4135271 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="puppet"
exe="/opt/puppetlabs/puppet/bin/ruby"
subj=system_u:system_r:unconfined_service_t:s0 key=(null)
node=llodmt.ligo-la.caltech.edu type=AVC
msg=audit(1701722445.997:630306): avc: denied { open } for
pid=4135271 comm="puppet" path="/etc/shibboleth/shibboleth2.xml"
dev="md126" ino=17384656
scontext=system_u:system_r:unconfined_service_t:s0
tcontext=system_u:object_r:shibboleth_etc_t:s0 tclass=file permissive=1
node=llodmt.ligo-la.caltech.edu type=AVC
msg=audit(1701722445.997:630306): avc: denied { read } for
pid=4135271 comm="puppet" name="shibboleth2.xml" dev="md126"
ino=17384656 scontext=system_u:system_r:unconfined_service_t:s0
tcontext=system_u:object_r:shibboleth_etc_t:s0 tclass=file permissive=1
6 months, 2 weeks