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
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: qemu-ga guest-exec & SELinux
by Daniel P. Berrangé
On Tue, Jun 21, 2022 at 10:42:39AM +0200, Renaud Métrich wrote:
> Hi there,
>
> I'm the BZ reporter.
>
> I think the safe solution is to provide something similar to what was done
> for vmtools: have a context switching to become sort of "unconfined" domain.
>
> This context switch has to happen only the executor and we already have a
> solution, I documented it in the BZ.
>
> I don't think having an additional boolean is necessary, unless we want to
> restrict the commands the guest can execute.
If we allow QGA to execute arbitrary commands, running those commands
unconfined_t, then what is the point of having any SELinux policy
for QGA at all. It can just execute "/bin/sh" or "/bin/perl", passing
any script commands it wants, having them run as unconfined_t and thus
escape all SELinux confinement of QGA.
I didn't realize that we in fact already allowed runing any command
labelled bin_t. That already makes the QGA policy useless as a security
measure and should be addressed IMHO by putting that existing rul;e
behind a boolean, defaulting to disabled.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2 years
qemu-ga guest-exec & SELinux
by Marc-André Lureau
Hi!
https://bugzilla.redhat.com/show_bug.cgi?id=2093355 ("AVCs when trying to
execute a command through qemu-ga ("guest-exec" command)") describes an
issue with fedora/rhel SELinux rules, where some program executions are
denied.
qemu-ga has "virt_qemu_ga_t" context, and is not allowed to execute
binaries that are not "bin_t", iiuc. The suggestion from Renaud Métrich is
for qemu-ga exec command to launch the user program through an helper
program that would have the virt_qemu_ga_unconfined_exec_t context, and
appropriate rules in selinux (similar to fsfreeze-hook rules), so any
program can be executed. qemu-ga would thus ship and use that helper, in
all OS, to avoid varying code paths.
Does that sound reasonable or should we try to find a solution with SELinux
rules instead?
thanks
--
Marc-André Lureau
2 years
btrfs, user created subvolumes
by Chris Murphy
Hi,
Two questions as it relates to btrfs subvolumes created by users on Fedora.
Question 1, should new subvolumes within the ~/ hierarchy have the
same label as a new directory?
$ mkdir hi
$ btrfs subvolume create hi2
$ ls -lZ
drwxrwxr-x. 1 chris chris unconfined_u:object_r:user_home_t:s0
0 Jun 13 15:55 hi
drwxrwxr-x. 1 chris chris system_u:object_r:unlabeled_t:s0
0 Jun 13 15:55 hi2
Is this expected? Or should I file a bug?
Question 2, should users be allowed to remove subvolumes (including
subvolume snapshots) they own?
There's a bit of background here:
* Users can 'btrfs subvolume create' without privileges
* Users can't 'btrfs subvolume delete' without privileges, unless the
Btrfs file system is mounted with option "user_subvol_rm_allowed"
* Users can remove empty subvolumes without privileges, e.g. rmdir or
rm -rf so long as the user owns all the items contained in the
subvolume.
OK a bit more background. A subvolume is a file b-tree. It's where all
file and directory metadata is located: inode, datetime, permissions,
xattr, compression info, extent info.
When deleting a subvolume, none of the contents are checked for
permissions at all - the tree is just snipped off the file system, and
the extents are later freed by a kernel cleaner thread. So it's
essentially an immediately returning command, with the expensive
backref walk done by a dedicated kernel thread later.
On any file system when deleting a directory, all the contents have
permissions checked. If the user can't delete an item, then the
directory won't be empty, and they won't be able to remove it. This is
the same for btrfs subvolumes when using the same commands, rmdir and
rm -rf. The subvolume can't be deleted until it's empty. This can be
quite alot more expensive than just a subvolume delete.
I'm wondering if anyone can imagine problems with enabling
user_subvol_rm_allowed mount option on Fedora desktops by default? And
whether SELinux can or should have some role in preventing mistakes?
Like if SELinux could distinguish between an active user home
directory that is also a btrfs subvolume - don't allow the user to
stab themselves in the foot. But let them delete any other subvolume
they own. Or maybe it's low enough risk.
Thanks,
--
Chris Murphy
2 years
polyinstantiation_enabled vs allow_polyinstantiation
by Iker Pedrosa
Hi,
I would like to know what's the difference between the two booleans provided in the title. Is there any documentation that I could check? Is any of them needed when I'd like to have poly-instantiated directories with SELinux in enforcing mode?
2 years
