selinux

selinux@lists.fedoraproject.org

4831 discussions

Allowing OpenDMARC to send mail
by Matt Domsch 14 Sep '22

14 Sep '22

OpenDMARC (Domain-based Message Authentication, Reporting & Conformance) provides an open source library that implements the DMARC verification service plus a milter-based filter application that can plug in to any milter-aware MTA, including sendmail, Postfix, or any other MTA that supports the milter protocol. One feature of OpenDMARC is that i can send email to domains who have specified in their DMARC DNS record that they wish to receive reports (either aggregate or forensic) from mail servers when a message claiming to originate from their mail domain has been received. This allows sending mail servers to possibly adjust their mail sending practices to ensure all mail they legitimately send are marked as such, and all mail sent as a spoof of their domain then be blocked by filters. opendmarc runs in selinux domain dkim_milter_t (I never got around to asking for a separate dmarc_milter_t domain), and uses popen("/usr/sbin/sendmail -t ...") to send its aggregate or forensic report. selinux policy currently prohibits this behavior. I have been trying to write a custom policy that would allow opendmarc to make the transition to sendmail_t, but have been unsuccessful, hence this plea for help. #============= dkim_milter_t ============== allow dkim_milter_t self:process setrlimit; # opendmarc calls setrlimit() allow dkim_milter_t shell_exec_t:file { execute_no_trans map entrypoint }; # opendmarc calls popen() which invokes /bin/sh allow dkim_milter_t sendmail_exec_t:file { entrypoint execute getattr open read map }; # invokes sendmail which has this file type allow dkim_milter_t sendmail_t : process transition; # allow the transition to sendmail_t type_transition dkim_milter_t sendmail_exec_t : process sendmail_t; # However, once sendmail is running and tries to create its queue files in /var/spool/mqueue which has type mqueue_spool_t, the audit logs indicate it's still running as dkim_milter_t which doesn't have permissions to manage that directory (nor should it - that's sendmail's job). type=AVC msg=audit(1662776560.507:10521833): avc: denied { create } for pid=1385220 comm="sendmail" name="df28A2Meeh1385220" scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=file permissive=0 What do I need to do to get opendmarc to be running in sendmail_t automatically following the popen()? Also filed in https://bugzilla.redhat.com/show_bug.cgi?id=2125030 Thanks, Matt

3 5

Setting context in early boot
by Frederick Grose 08 Sep '22

08 Sep '22

I have a general scoping question on setting SELinux context on files/directories during early boot. I'm working on a feature in dracut to implement general stacking of filesystem hierarchies via OverlayFS for the root filesystem within the dmsquash-live-root module. How should I address the setting of context for new files, directories, or links needed to assemble the components for the OverlayFS mount? For example, when I mkdir -m 0755 -p --context=system_u:object_r:root_t:s0 /run/somemountpoint I get this warning in the journal: mkdir: warning: ignoring --context; it requires an SELinux/SMACK-enabled kernel If the SELinux code is not active at this early stage, what is to be done?

3 2

Re: Samba and Borg/fuse denied - ?
by lejeczek 22 Jul '22

22 Jul '22

On 21/07/2022 17:11, Robin Lee Powell wrote: > > On Thu, Jul 21, 2022 at 02:33:31PM +0100, lejeczek wrote: >> Hi guys >> >> I see that: >> -> $ getsebool samba_share_fusefs >> samba_share_fusefs --> on >> >> but unless I put 'permissive' on or: >> -> $ semanage permissive --add smb_t >> then Samba will have not access to borg fuse mounts and denials are silent. >> >> Anybody would also think this can go as BZ or request for "enhancement"? >> All thoughts share are greatly appreciated. > I can't help with the actual issue, but the incantation for seeing > the silent denials is probably: sudo semanage dontaudit off My concern here is about 'samba_share_fusefs' - unless it's not what I thought it was. I see other domains have '_use_fusefs' - perhaps that is what Samba needs too @devel ? selinux-policy-3.14.3-104.el8.noarch thanks, L.

1 0

Samba and Borg/fuse denied - ?
by lejeczek 21 Jul '22

21 Jul '22

Hi guys I see that: -> $ getsebool samba_share_fusefs samba_share_fusefs --> on but unless I put 'permissive' on or: -> $ semanage permissive --add smb_t then Samba will have not access to borg fuse mounts and denials are silent. Anybody would also think this can go as BZ or request for "enhancement"? All thoughts share are greatly appreciated. many thanks, L.

1 0

Re: qemu-ga guest-exec & SELinux
by Daniel P. Berrangé 21 Jun '22

21 Jun '22

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 :|

1 0

qemu-ga guest-exec & SELinux
by Marc-André Lureau 20 Jun '22

20 Jun '22

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 1

btrfs, user created subvolumes
by Chris Murphy 13 Jun '22

13 Jun '22

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

1 0

polyinstantiation_enabled vs allow_polyinstantiation
by Iker Pedrosa 09 Jun '22

09 Jun '22

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?

3 3

Incorrect permissons in the RPM package and boomaga requires the SELinux security policy
by Martin Gansser 20 May '22

20 May '22

Hi, a user opened a bugzilla ticket [1] with this selinux problem, but i don't know how to resolve this: This issue is still present on Fedora 36. After installing the `boomaga-selinux` package I still get the following SELinux errors: ``` SELinux is preventing boomaga from setattr access on the directory /var/cache/boomaga/chris. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow boomaga to have setattr access on the chris directory Then you need to change the label on /var/cache/boomaga/chris Do # semanage fcontext -a -t FILE_TYPE '/var/cache/boomaga/chris' where FILE_TYPE is one of the following: cupsd_etc_t, cupsd_log_t, cupsd_rw_etc_t, cupsd_tmp_t, cupsd_var_run_t, fonts_cache_t, print_spool_t. Then execute: restorecon -v '/var/cache/boomaga/chris' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that boomaga should be allowed setattr access on the chris directory 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 'boomaga' --raw | audit2allow -M my-boomaga # semodule -X 300 -i my-boomaga.pp Additional Information: Source Context system_u:system_r:cupsd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_t:s0 Target Objects /var/cache/boomaga/chris [ dir ] Source boomaga Source Path boomaga Port <Unknown> Host fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-36.8-2.fc36.noarch Local Policy RPM selinux-policy-targeted-36.8-2.fc36.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name fedora Platform Linux fedora 5.17.7-300.fc36.x86_64 #1 SMP PREEMPT Thu May 12 14:56:44 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-05-18 09:25:42 CEST Last Seen 2022-05-18 09:25:42 CEST Local ID fcf9d05e-bd5b-4ef6-8a1f-a9a1f94705ff Raw Audit Messages type=AVC msg=audit(1652858742.233:473): avc: denied { setattr } for pid=16952 comm="boomaga" name="chris" dev="nvme0n1p7" ino=2129750 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0 Hash: boomaga,cupsd_t,var_t,dir,setattr ``` Hope somebody can help here. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1409115 Regards Martin

1 0

Questions about fail2ban policy
by Orion Poplawski 19 May '22

19 May '22

I'm getting the following error building fail2ban on EPEL9: make[1]: Entering directory '/builddir/build/BUILD/fail2ban-0.11.2' fail2ban.if:13: Error: duplicate definition of fail2ban_domtrans(). Original definition on 13. fail2ban.if:33: Error: duplicate definition of fail2ban_domtrans_client(). Original definition on 33. fail2ban.if:60: Error: duplicate definition of fail2ban_run_client(). Original definition on 60. fail2ban.if:80: Error: duplicate definition of fail2ban_stream_connect(). Original definition on 80. fail2ban.if:99: Error: duplicate definition of fail2ban_rw_inherited_tmp_files(). Original definition on 99. fail2ban.if:118: Error: duplicate definition of fail2ban_rw_stream_sockets(). Original definition on 118. fail2ban.if:137: Error: duplicate definition of fail2ban_dontaudit_use_fds(). Original definition on 137. fail2ban.if:156: Error: duplicate definition of fail2ban_dontaudit_rw_stream_sockets(). Original definition on 156. fail2ban.if:174: Error: duplicate definition of fail2ban_read_lib_files(). Original definition on 174. fail2ban.if:194: Error: duplicate definition of fail2ban_read_log(). Original definition on 194. fail2ban.if:215: Error: duplicate definition of fail2ban_append_log(). Original definition on 215. fail2ban.if:235: Error: duplicate definition of fail2ban_read_pid_files(). Original definition on 235. fail2ban.if:254: Error: duplicate definition of fail2ban_dontaudit_leaks(). Original definition on 254. fail2ban.if:281: Error: duplicate definition of fail2ban_admin(). Original definition on 281. Compiling targeted fail2ban module fail2ban.te:102:ERROR 'syntax error' at token 'logging_watch_audit_log_files' on line 6330: logging_watch_audit_log_files(fail2ban_t) The .if errors don't seem to actually fail the build, but I'm still curious if it's time to drop the fail2ban policy from selinux-policy itself. The latter seems to be a problem, but is fine on Fedora (through F37). It also complains about other logging_watch_* macros. What happened to this in EL9? -- 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/

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux