selinux April 2021

selinux@lists.fedoraproject.org

7 participants
6 discussions

certmonger post-save scripts & certmonger_unconfined_t domain
by Sam Morris 28 Apr '21

28 Apr '21

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 3

iscsi.service: Unit cannot be reloaded because it is inactive.
by Jason Long 08 Apr '21

08 Apr '21

Hello, I'm using Fedora Server as an iSCSI Shared Storage. When I rebooted my server then the "iscsi.service" couldn't load: [root@node3 ~]# systemctl status iscsi.service ● iscsi.service - Login and scanning of iSCSI devices Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Sat 2021-04-03 18:49:08 +0430; 2s ago └─ ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes was not met Docs: man:iscsiadm(8) man:iscsid(8) Apr 03 18:39:17 node3.localhost.localdomain systemd[1]: Condition check resulted in Login and scanning of iSCSI devices being skipped. Apr 03 18:39:17 node3.localhost.localdomain systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive. Apr 03 18:39:17 node3.localhost.localdomain systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive. Apr 03 18:49:08 node3.localhost.localdomain systemd[1]: Condition check resulted in Login and scanning of iSCSI devices being skipped. SELinux is enabled on my Fedora Server: # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [root@node3 ~]# ps -eZ | grep iscsid_t [root@node3 ~]# And when I looked at the log, then I saw below errors: # dmesg -H -l err [Apr 4 15:05] [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message. [ +0.000009] [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message. [ +9.037994] dev[000000004a7f146c]: Unable to change SE Device alua_support: alua_support has fixed value [ +0.000014] dev[000000004a7f146c]: Unable to change SE Device alua_support: alua_support has fixed value [ +0.000798] dev[000000004a7f146c]: Unable to change SE Device pgr_support: pgr_support has fixed value [ +0.000004] dev[000000004a7f146c]: Unable to change SE Device pgr_support: pgr_support has fixed value How can I configure SELinux for an iSCSI Shared Storage? Thank you.

2 7

Looking for users of userfaultfd(2) syscall in Fedora
by Ondrej Mosnacek 07 Apr '21

07 Apr '21

Hi all, Kernel 5.12 added support to SELinux for controlling access to the userfaultfd interface [1][2] and we'd like to implement this in Fedora's selinux-policy. However, once we add the corresponding class to the policy, all SELinux domains for which we don't add the appropriate rules will have any usage of userfaultfd(2) denied. Therefore, we would like to identify as many users of this syscall as possible before we make that change, so that we can add and test all the needed rules in one go, minimizing the amount of denials found after the fact. My understanding is that userfaultfd(2) doesn't have many users among system services, so it should be possible to catch most/all of them in advance. So if you know that your (or any other) Fedora component uses userfaultfd(2), please let us know. AFAIK, at least QEMU most likely uses it, so we'll have that one on our radar, but we'd like to know if there are any other programs/services we need to cover. Thanks! [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.

3 3

Re: Looking for users of userfaultfd(2) syscall in Fedora
by Ondrej Mosnacek 07 Apr '21

07 Apr '21

On Tue, Apr 6, 2021 at 7:33 PM Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> wrote: > On Tue, Apr 06, 2021 at 06:57:27PM +0200, Ondrej Mosnacek wrote: > > Hi all, > > > > Kernel 5.12 added support to SELinux for controlling access to the > > userfaultfd interface [1][2] and we'd like to implement this in > > Fedora's selinux-policy. However, once we add the corresponding class > > to the policy, all SELinux domains for which we don't add the > > appropriate rules will have any usage of userfaultfd(2) denied. > > https://codesearch.debian.net/search?q=userfaultfd(&literal=1 > lists a few candidates… Thanks, that's a nice tool! Filtering out false-positives, the kernel itself, and user programs that would normally run under unconfined_t, packages dead in Fedora, ..., the only relevant one seems to be 'criu' (already mentioned in this thread). Strange that it didn't find QEMU... maybe needs a more generic search... -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.

1 0

Re: Looking for users of userfaultfd(2) syscall in Fedora
by Florian Weimer 06 Apr '21

06 Apr '21

* Zbigniew Jędrzejewski-Szmek: > The code is available. From what I remember, they had a fairly beefy > server dedicated to the indexing... But if somebody provides that, it > should be fairly easy to duplicate. Michael even expressed interest about setting up an instance, if I recall correctly, but that was quite some time ago. Thanks, Florian

1 0

Re: Looking for users of userfaultfd(2) syscall in Fedora
by Matthew Miller 06 Apr '21

06 Apr '21

On Tue, Apr 06, 2021 at 05:16:52PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > https://codesearch.debian.net/search?q=userfaultfd(&literal=1 > lists a few candidates… You beat me to this suggestion. :) I'd love for Fedora to someday have a similar service! -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux April 2021