selinux January 2018

selinux@lists.fedoraproject.org

6 participants
7 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

Symlink or bind mount?
by Gionatan Danti 30 Apr '18

30 Apr '18

Being a regular user of selinux, I often face situations where some common directories (es: /var/log or /var/lib) needs to be redirected to other partitions/volumes. I very simple approach, without impacting selinux at all, is to mount a volume in the precise path I need to replace - ie mount /dev/vg_test/lv_lib in /var/lib. However, this is a one-volume-for-directory approach and I would like to avoid it. The other possibility is to create single big volume with multiple directories, mount it, and 1) symlink the original dir (ie: /var/log) to the new one (ie: /mnt/volume/var/log); 2) use a bind mount to re-mount the destination dir (/mnt/volume/var/log) on the original one (/var/log). The symlink approach is self-explaining, as anyone listing the original directory will immediately notice it. However, it sometime require extensive customization of the selinux policy, a thing I try hard to avoid. The bind mount approach is somewhat simpler from selinux standpoint, but it much less discoverable by a simple "ls". What do you feel is the preferred approach? I am missing something? 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

3 5

SELinux blocking systemctl --user ??
by Robin Lee Powell 22 Jan '18

22 Jan '18

On a host with unconfined disabled, running this as a staff_u/staff_t user: [sampre_mw@jukni ~]$ systemctl --user status Failed to read server status: Access denied worked until recently. I just upgraded to Fedora 27, but I *think* this worked after the upgrade, so I don't know what's going on there. I get nothing whatever in auditd, which is weird. In syslog I get: Dec 25 09:48:07 jukni systemd[669]: selinux: avc: denied { status } for auid=n/a uid=1086 gid=1086 cmdline="" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=system permissive=0 Further, this: [sampre_mw@jukni ~]$ systemctl --user restart lojban_mediawiki_web Failed to restart lojban_mediawiki_web.service: Access denied See user logs and 'systemctl --user status lojban_mediawiki_web.service' for details. Gives this in syslog: Dec 25 09:49:06 jukni systemd[669]: selinux: avc: denied { start } for auid=n/a uid=1086 gid=1086 path="/home/sampre_mw/.config/systemd/user/lojban_mediawiki_web.service" cmdline="" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 I can't find anything in sesearch about self:system, and all I can find in https://github.com/TresysTechnology/refpolicy.git or https://github.com/TresysTechnology/refpolicy-contrib.git is: policy/modules/kernel/kernel.te 481: allow can_load_kernmodule self:system module_load; policy/modules/system/init.te 225: allow init_t self:system { status reboot halt reload }; It strikes me as unlikely that F27 *actually* shipped with a setup that makes systemctl user operations not work. I don't have a comparable user to test with, really, but at first glance my other F27 systems seem OK. Any idea what I broke?

2 5

Running Qt-5.10 in docker requires "allow container_t container_runtime_t:fifo_file map;"
by Laurent Rineau 22 Jan '18

22 Jan '18

In an automated test process, I have a docker container based on Fedora Rawhide, with Docker running on F27. That container runs a compilation process involving Qt 5.10 (from rawhide). That compilation fails, and I have the following AVC: type=AVC msg=audit(1516334348.971:1059): avc: denied { map } for pid=4046 comm="moc" path="pipe:[3343646]" dev="pipefs" ino=3343646 scontext=system_u:system_r:container_t:s0:c273,c916 tcontext=system_u:system_r:container_runtime_t:s0 tclass=fifo_file permissive=0 When Rawhide had Qt 5.9.3, it was working (no AVC, and successul compilation test). What do you suggest? The tool audit2allow says that I would need that module: module qt5.10 1.0; require { type container_runtime_t; type container_t; class fifo_file map; } #============= container_t ============== allow container_t container_runtime_t:fifo_file map; Is that permission dangerous? Why is it not in the policy? Actually, I have no idea what mean mapping a fifo file. From why I know it makes no sense. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau

2 1

Re: Question about independent SELinux policy module
by Lukas Vrabec 22 Jan '18

22 Jan '18

On 01/15/2018 01:59 PM, Javier Martinez Canillas wrote: > Hello Bill, > Hi all, > On 01/14/2018 10:44 PM, Roberts, William C wrote: >> >> >>> -----Original Message----- >>> From: Javier Martinez Canillas [mailto:javierm@redhat.com] >>> Sent: Friday, January 12, 2018 2:46 AM >>> To: Lukas Vrabec <lvrabec(a)redhat.com> >>> Cc: Tricca, Philip B <philip.b.tricca(a)intel.com>; Roberts, William C >>> <william.c.roberts(a)intel.com>; selinux(a)lists.fedoraproject.org; Sun, Yunying >>> <yunying.sun(a)intel.com>; Jerry Snitselaar <jsnitsel(a)redhat.com> >>> Subject: Re: Question about independent SELinux policy module >>> >>> Sorry, forgot to add the other tpm2-{tss,tools,abrmd} package maintainers to cc. >>> >>> On 01/12/2018 11:30 AM, Javier Martinez Canillas wrote: >>>> Hello Lukas and SELinux team, >>>> >>>> I maintain the tpm2-{tss,tools,abrmd} packages in Fedora, and a recent >>>> upstream change [0] in tpm2-abrmd (using sockets instead of pipes to >>>> pass open fd to the >>>> clients) makes the daemon to die when staring in the D-Bus system bus. >>>> >>>> This is because the tpm2-abrmd runs in the unconfined_service_t domain >>>> and the D-bus daemon isn't allowed to read/write to sockets created by >>>> processes in an unconfined domain. >>>> >>>> The tpm2-abrmd upstream project ships a SELinux policy module [1] that >>>> makes it work on Fedora, but the policy module has the following AV rule as a >>> workaround: >>>> >>>> # This next bit doesn't belong here. It should be exposed through an # >>>> interface likely from the dbus policy module. >>>> gen_require(` >>>> type system_dbusd_t; >>>> ') >>>> allow system_dbusd_t tabrmd_t:unix_stream_socket { read write }; >>>> >>>> The comment correctly points out that it should be instead an >>>> interface in the D-Bus policy module, but neither Fedora's nor refpol >>>> SELinux policy have such an interface for that particular AV rule. >>>> >>>> I have created a tpm2-abrmd-selinux [2] package to ship the customized >>>> SELinux policy in Fedora as explained in this wiki page [3]. But of >>>> course, first that AV rule needs to be removed since it doesn't belong >>>> to the tpm2-abrmd SELinux policy module. >>>> >>>> So my question is what's the correct way to fix this? I'm very far >>>> from being a SELinux expert so I don't know how to proceed. >> >> I would imagine adding that missing interface into Fedora's policy would >> be correct. What is refpolicy doing, does it have such an interface? >> > > As mentioned in my previous email, neither Fedora's nor refpolicy have this > interface. And yes, I would also expect the interface to be added in Fedora's > selinux-policy-contrib package. > > I just first wanted to make sure that a) the interface is correct and the only > hack is where it's being added and b) questioning whether the tpm2-abrmd D-Bus > daemon shouldn't be modified instead to not require the rule in the first place. > > Philip said that the reason why the tpm2-abrmd needs it, is that pass opened fds > through unix sockets. And that's something that it seems no other D-bus service > does (since otherwise an interface for the unix_stream_socket read write AV rule > would already exist in the in the D-Bus policy module). > Yep, it looks like you mentioned, tpm2-abrmd is passing opened fsd through unix sockets, and that's reason why this rules is needed. We also don't have interface for it and it can be add, but then tpm2-abrmd SELinux security policy will be dependent on specific distribution policy. I prefer fix on following PR: https://github.com/intel/tpm2-abrmd/pull/299 >> With that said this touches on 2 things of SE Linux I don't know much about: >> desktop/fedora and dbus >> > > Yes, I'm not that familiar with neither D-Bus nor SELinux to be honest. That's > why I wanted the experts' opinions. > >> I wonder if the mainline SE Linux list would have any suggestions if no one >> Here comes up with anything. >> > > Could be, I preferred to first see how it could be solved with Fedora's SELinux > policy since there's a lot of delta with the upstream refpolicy anyways. > >>>> >>>> I've added Philip (tpm2-abrmd maintainer and author of the SELinux >>>> policy) in case you have more questions about what the tpm2-abrmd is >>>> doing and why needs the mentioned AV rule. >>>> >>>> [0]: https://github.com/intel/tpm2-abrmd/commit/51a3c55d772b >>>> [1]: https://github.com/intel/tpm2-abrmd/commit/b11194de8f40 >>>> [2]: https://github.com/martinezjavier/tpm2-abrmd-selinux >>>> [3]: http://fedoraproject.org/wiki/SELinux/IndependentPolicy >>>> > > Best regards, > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc.

1 0

Loading a new policy
by rbs s 12 Jan '18

12 Jan '18

Hi, I am using Fedora 26. I need to replace the existing target policy with a new one. Even though "make reload" in the new policy directory completes successfully, it doesn't seem to have actually loaded the new binary. Because even after restart seinfo still gives the details of the old policy. What am I missing here? -rbs

4 9

No more massive patches in selinux-policy rpm package
by Lukas Vrabec 09 Jan '18

09 Jan '18

Hi Guys, I changed way how to build selinux-policy rpm package. From now tarballs from selinux-policy github repos[1][2] are used directly instead of patching reference policy. For more info see my blog[3]. If you have any question feel free to ask here. [1] https://github.com/fedora-selinux/selinux-policy [2] https://github.com/fedora-selinux/selinux-policy-contrib [3] https://lukas-vrabec.com/index.php/2018/01/09/no-more-massive-patches-in-se… -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux January 2018