selinux May 2018

selinux@lists.fedoraproject.org

17 participants
14 discussions

Initial context for init
by Philip Seeley 01 Aug '19

01 Aug '19

Hi all, Quick question is: In the targeted policy should init run SystemHigh as it does in the mls policy? The background: We're setting up a targeted system where we confine all users and remove the unconfined policy module, but we also enable polyinstantiation of /tmp and /var/tmp. If we ssh in as a staff_u user phil and elevate to root/sysadm_r then we have a context of: staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 And therefore /var/tmp is: drwxrwxrwt. root root system_u:object_r:tmp_t:s0-s0:c0.c1023 /var/tmp Which is really: drwxrwxrwt. root root system_u:object_r:tmp_t:s0-s0:c0.c1023 /var/tmp-inst/system_u:object_r:tmp_t:s0-s0:c0.c1023_phil The real /var/tmp is: drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /var/tmp Now if we use run_init to update an RPM that contains a post install script, rpm can't create the temporary script file: # run_init bash -c 'rpm -i --force /root/libselinux-2.0.94-7.el6.x86_64.rpm' Authenticating phil. Password: error: error creating temporary file /var/tmp/rpm-tmp.atkHTf: Permission denied error: Couldn't create temporary file for %post (libselinux-2.0.94-7.el6.x86_64): Permission denied Note: you need to use run_init as the rpm might restart a service, e.g. the sssd rpm. We've traced this to the /etc/selinux/targeted/contexts/initrc_context file which contains: system_u:system_r:initrc_t:s0 So we transition to initrc_t and then to rpm_t without any categories, but because the polyinstantiated /var/tmp directory has c0.c1023 we get denied. Normally in targeted init runs unconfined, but we've removed this. type=AVC msg=audit(1467342325.016:716): avc: denied { read } for pid=2779 comm="rpm" name="system_u:object_r:tmp_t:s0-s0:c0.c1023_phil" dev=dm-0 ino=1966082 scontext=system_u:system_r:rpm_t:s0 tcontext=system_u:object_r:tmp_t:s0-s0:c0.c1023 tclass=dir It works if we change initrc_context to: system_u:system_r:initrc_t:s0-s0:c0.c1023 We don't see the issue under mls because the default initrc_context is: system_u:system_r:initrc_t:s0-s15:c0.c1023 We've traces this back through the selinux-policy src RPM and to the upstream refpolicy and see that config/appconfig-mcs/initrc_context is: system_u:system_r:initrc_t:s0 whereas config/appconfig-mls/initrc_context is: system_u:system_r:initrc_t:s0-mls_systemhigh So under mls init's context is SystemHigh, but under mcs/targeted it doesn't have any categories. So the long question is should config/appconfig-mcs/initrc_context really be: system_u:system_r:initrc_t:mcs_systemhigh as it seems odd that the more secure mls policy would run init at SystemHigh but targeted doesn't. Thanks Phil Seeley

3 3

ejabberd pull requests
by Randy Barlow 14 Jul '18

14 Jul '18

Greetings! In November I pulled the ejabberd SELinux policy into Fedora 27+ so I could manage it more closely with ejabberd updates. At the time I sent pull requests to the Fedora SELinux policy to remove it from there, but the pull requests haven't been reviewed or merged. Could someone take a look? https://github.com/fedora-selinux/selinux-policy-contrib/pull/38 https://github.com/fedora-selinux/selinux-policy-contrib/pull/39 At this point, I suppose we'll also want to make this change on the Fedora 28 branch. You can see the policy in the ejabberd sources now: https://src.fedoraproject.org/rpms/ejabberd/tree/master

4 5

How do I stop ignoring an alert?
by John Griffiths 28 May '18

28 May '18

I have marked some recurring alerts as "ignore" in sealert browser. There have been some recent policy updates and I want to now receive alerts for those alerts to see if they were fixed in the update. I have read the man pages for sealert and setroubleshootd and cannot find any reference to a command or an edit to be able to stop ignoring an alert. Is there such a command? Do I have to edit a file? If so, which one? Thanks, John

2 4

Re: svirt_lxc_net_t -> container_t and nsswitch_domain
by Lukas Vrabec 26 May '18

26 May '18

On 05/26/2018 12:15 PM, Daniel Walsh wrote: > On 05/25/2018 10:26 AM, Lukas Vrabec wrote: >> On 05/23/2018 11:50 PM, Dustin C. Hatch wrote: >>> I recently upgraded some of my Docker hosts to CentOS 7.5 and started >>> getting "Permission Denied" errors inside of containers. I traced this >>> down to any container that mounts and uses /etc/passwd from the host (so >>> that UIDs inside the container map to the same username as on the host), >>> because the SELinux policy in CentOS 7.5 does not allow the new >>> continer_t domain to read passwd_file_t. >>> >> Yes we renamed svirt_lxc_net_t domain for container to container_t, >> which make more sense. >> >> Container SELinux security module is not distribution policy, so for >> this reason adding Dan Walsh to our discussion. >> >> Dan, >> >> container_t don't have auth_use_nsswitch in container policy, is it bug >> or you removed it for some reason? >> >> Thanks, >> Lukas. > Yes the reason is we did not want the container processes to figure out > which users are on the host. > During a container CVE, we were dinged on the fact that containers could > read /etc/passwd. > Yes, it make sense. Thanks, Lukas. > This is probably a case where it would be great to easily extend content > from the host into a container. >>> The old svirt_lxc_net_t domain had the nsswitch_domain attribute, while >>> its replacement, container_t, does not. I cannot find any reference for >>> this change, so I was wondering if it was deliberate or not. If it was >>> deliberate, what would be the consequences if I were to make a local >>> policy change to add that attribute back? If it was not deliberate, I >>> would be happy to open a ticket in Bugzilla. > It was deliberate and it is not an issue if you add it back, or > something tighter like > > auth_read_passwd(container_t) > > I believe allowing general containers to read users information should > be denied by default, but if you have a use case that you want to enable > it, I have no problem with it. >>> >>> Thanks, >>> >> > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc.

1 0

SELinux problems with snaps
by Anatoli Babenia 25 May '18

25 May '18

How to fix issues with snaps and SELinux? Is there any intro into what's going on with them and what is the workflow to report and deal with issues such as this - https://forum.snapcraft.io/t/snap-can-not-execute-its-own-files-on-selinux/…

2 1

svirt_lxc_net_t -> container_t and nsswitch_domain
by Dustin C. Hatch 25 May '18

25 May '18

I recently upgraded some of my Docker hosts to CentOS 7.5 and started getting "Permission Denied" errors inside of containers. I traced this down to any container that mounts and uses /etc/passwd from the host (so that UIDs inside the container map to the same username as on the host), because the SELinux policy in CentOS 7.5 does not allow the new continer_t domain to read passwd_file_t. The old svirt_lxc_net_t domain had the nsswitch_domain attribute, while its replacement, container_t, does not. I cannot find any reference for this change, so I was wondering if it was deliberate or not. If it was deliberate, what would be the consequences if I were to make a local policy change to add that attribute back? If it was not deliberate, I would be happy to open a ticket in Bugzilla. Thanks, -- ♫Dustin

2 1

selinux-policy-3.14.1-25 causes issues with nVidia drivers and sddm
by Ed Greshko 24 May '18

24 May '18

Hi, Updating to selinux-policy-3.14.1-25 causes systems running KDE and sddm to boot to a blank screen with only a mouse cursor. This is the relevant AVC which seems to be the issue. type=AVC msg=audit(1527130068.596:164): avc: denied { map } for pid=1205 comm="sddm-greeter" path="/dev/nvidiactl" dev="devtmpfs" ino=17300 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xserver_misc_device_t:s0 tclass=chr_file permissive=0 Should this be fixed in selinux or should the nVidia packager do something? -- Conjecture is just a conclusion based on incomplete information. It isn't a fact.

2 5

Re: motion
by m.roth＠5-cent.us 21 May '18

21 May '18

On Sun, 15 Apr 2018 20:48. ukas Vrabec <lvrabec(a)redhat.com> wrote: > On 04/12/2018 10:49 PM, m.roth(a)5-cent.us wrote: >> Got a CentOS 7 box running motion. Selinux is complaining that one of the >> scripts motion runs is mislabeled. Here's what it is. >> system_u:object_r:nfs_t:s0 /home/motion/bin/on_move_end >> >> Now, ~motion is NFS mounted, and we've got use_nfs_home_dirs --> on, so >> what *would* the proper label be, or do I really need to create a policy >> for this? > > Could you please reproduce issue on your system and then attach output of: > > # ausearch -m AVC -ts today > It's been a busy week - sorry it took this long to respond. Do you *really* want all of it - this happens whenever someone goes into the secure room and is on video... and there are four cameras. Just today, I get 79k worth of o/p. Here's the most recent minute's o/p: time->Wed Apr 18 11:21:32 2018 type=PROCTITLE msg=audit(1524064892.294:35325): proctitle=7368002D63002F686F6D652F6D6F74696F6E2F62696E2F6F6E5F6D6F76655F656E64202F686F6D652F6D6F74696F6E2F63616D6572612F323031382D30342D31382F323031382D30342D31382D3131313134352D31322D6172676F2D312E617669203120323031382D30342D3138002026 type=SYSCALL msg=audit(1524064892.294:35325): arch=c000003e syscall=59 success=yes exit=0 a0=af4fe0 a1=af5040 a2=af3b90 a3=7ffd1c86d700 items=0 ppid=1438 pid=11961 auid=4294967295 uid=489 gid=39 euid=489 suid=489 fsuid=489 egid=39 sgid=39 fsgid=39 tty=(none) ses=4294967295 comm="on_move_end" exe="/usr/bin/bash" subj=system_u:system_r:motion_t:s0 key=(null) type=AVC msg=audit(1524064892.294:35325): avc: denied { execute_no_trans } for pid=11961 comm="sh" path="/home/motion/bin/on_move_end" dev="0:46" ino=53198849 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=file type=AVC msg=audit(1524064892.294:35325): avc: denied { execute } for pid=11961 comm="sh" name="on_move_end" dev="0:46" ino=53198849 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=file ---- time->Wed Apr 18 11:21:32 2018 type=PROCTITLE msg=audit(1524064892.291:35324): proctitle=7368002D63002F686F6D652F6D6F74696F6E2F62696E2F6F6E5F6D6F76655F656E64202F686F6D652F6D6F74696F6E2F63616D6572612F323031382D30342D31382F323031382D30342D31382D3131313134352D31322D6172676F2D312E617669203120323031382D30342D3138002026 type=SYSCALL msg=audit(1524064892.291:35324): arch=c000003e syscall=59 success=yes exit=0 a0=432503 a1=7ff42f7f9b00 a2=7ffc2ba4b760 a3=7ff42f7fb730 items=0 ppid=1438 pid=11961 auid=4294967295 uid=489 gid=39 euid=489 suid=489 fsuid=489 egid=39 sgid=39 fsgid=39 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:motion_t:s0 key=(null) type=AVC msg=audit(1524064892.291:35324): avc: denied { execute_no_trans } for pid=11961 comm="motion" path="/usr/bin/bash" dev="dm-1" ino=98 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file ---- time->Wed Apr 18 11:22:22 2018 type=PROCTITLE msg=audit(1524064942.249:35327): proctitle=2F62696E2F7368002F686F6D652F6D6F74696F6E2F62696E2F6F6E5F6D6F76655F656E64002F686F6D652F6D6F74696F6E2F63616D6572612F323031382D30342D31382F323031382D30342D31382D3131323033342D30362D6172676F2D332E617669003300323031382D30342D3138 type=SYSCALL msg=audit(1524064942.249:35327): arch=c000003e syscall=59 success=yes exit=0 a0=78eb50 a1=78eb70 a2=78e8b0 a3=7ffdcf4d8af0 items=0 ppid=12042 pid=12043 auid=4294967295 uid=489 gid=39 euid=489 suid=489 fsuid=489 egid=39 sgid=39 fsgid=39 tty=(none) ses=4294967295 comm="uname" exe="/usr/bin/uname" subj=system_u:system_r:motion_t:s0 key=(null) type=AVC msg=audit(1524064942.249:35327): avc: denied { execute_no_trans } for pid=12043 comm="on_move_end" path="/usr/bin/uname" dev="dm-1" ino=259829 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file ---- time->Wed Apr 18 11:22:22 2018 type=PROCTITLE msg=audit(1524064942.249:35326): proctitle=2F62696E2F7368002F686F6D652F6D6F74696F6E2F62696E2F6F6E5F6D6F76655F656E64002F686F6D652F6D6F74696F6E2F63616D6572612F323031382D30342D31382F323031382D30342D31382D3131323033342D30362D6172676F2D332E617669003300323031382D30342D3138 type=SYSCALL msg=audit(1524064942.249:35326): arch=c000003e syscall=21 success=yes exit=0 a0=78eb50 a1=1 a2=7ffdcf4d8d40 a3=7ffdcf4d89d0 items=0 ppid=12042 pid=12043 auid=4294967295 uid=489 gid=39 euid=489 suid=489 fsuid=489 egid=39 sgid=39 fsgid=39 tty=(none) ses=4294967295 comm="on_move_end" exe="/usr/bin/bash" subj=system_u:system_r:motion_t:s0 key=(null) type=AVC msg=audit(1524064942.249:35326): avc: denied { execute } for pid=12043 comm="on_move_end" name="uname" dev="dm-1" ino=259829 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file mark

2 1

Relocating /etc/libvirt and Selinux label
by Gionatan Danti 18 May '18

18 May '18

Hi list, in relocating /etc/libvirt to another filesystem, I encountered another "lnk_file read" permission problem. First, I setup a selinux equivalence rule between the original path (/etc/libvirtd) and the new one (/tank/kvm/etc/libvirt/). Original layout/label: [root@whitehole ~]# ls -alZ /etc/ | grep libv drwx------. root root system_u:object_r:virt_etc_t:s0 libvirt After relocation and context restore (via "chcon -h -t virt_etc_t libvirt"): [root@whitehole ~]# ls -alZ /etc/ | grep libv lrwxrwxrwx. root root system_u:object_r:virt_etc_t:s0 libvirt -> /tank/kvm/etc/libvirt/ After relocation, libvirtd does not start, and audit2allow shows "allow virtd_t virt_etc_t:lnk_file read". Relabeling the link file with "restorecon -F /etc/libvirtd" produces the following output: [root@gdanti-lenovo etc]# ls -alZ | grep libv lrwxrwxrwx. root root system_u:object_r:etc_t:s0 libvirt -> /tank/kvm/etc/libvirt/ Now libvirtd correctly starts. However, I have some questions: - is this the correct mode to relocate a directory? - this is not the first "lnk_file read" problem I see. Why does the selinux policy prevent this kind of accesses? Do they pose security concerns? Or does the policy simply not expect to deal with relocated daemons? - after "restorecon -F /etc/libvirtd", which causes a relabel with etc_t type, libvirtd correctly starts. Why does the policy enable etc_t link reads, at the same time denying virt_etc_t link reads? - how can I avoid the problem (short of using bind mounts)? 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

2 5

Re: C 7, selinux, and rpc.gssd
by m.roth＠5-cent.us 18 May '18

18 May '18

Lukas Vrabec <lvrabec(a)redhat.com> wrote: > On 05/17/2018 09:12 PM, m.roth(a)5-cent.us wrote: >> As systems are upgraded, we're getting a ton of complaints >> (fortunately, we're in permissive mode) that would break everything. >> All of them involve rpc.gssd, and I see a number of bugs listed when I >> search. >> >> Note that I first saw this on a RHEL system, but now I'm seeing it on >> CentOS 7. I'm bringing it up here, because, given that there are >> multiple reported, that there's some bigger picture involving policy >> and rpc.gssd. >> >> I'll note that some of the reported bugs were *closed last year, or >> before, so it seems to me an old issue resurfaced. >> >> Example. >> SELinux is preventing /usr/sbin/rpc.gssd from using the block_suspend >> capability. > > While you won't send any logs, I'm not able to help you, but based on > our example, it looks like kernel bug affecting SELinux. Solution is to > dontaudit this SELinux denial. > > Also, what version of Centos 7 are you using? Centos 7.5? > One system is LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: RedHatEnterpriseWorkstation Description: Red Hat Enterprise Linux Workstation release 7.5 (Maipo) Release: 7.5 Codename: Maipo Another is LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.5.1804 (Core) Release: 7.5.1804 Codename: Core What logs do you usually want, the results of running sealert? From that, I see, on the CentOS 7.5 system: excerpt: Raw Audit Messages type=AVC msg=audit(1526626994.989:9622): avc: denied { block_suspend } for pid=901 comm="rpc.gssd" capability=36 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=capability2 And on the RHEL system: Raw Audit Messages type=AVC msg=audit(1526626926.76:162255): avc: denied { block_suspend } for pid=1218 comm="rpc.gssd" capability=36 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=capability2 So, same policy, and same denials. Note that the RHEL system is set for enforcing, while the CentOS system is permissive. mark

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux May 2018