selinux December 2016

selinux@lists.fedoraproject.org

11 participants
12 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

Re: RHEL 7 consoletype_exec interface issue
by Douglas Brown 27 Mar '17

27 Mar '17

Hi, In RHEL 7 when using the userdom_unpriv_user_template interface to create a new role, it in turn uses the consoletype_exec interface; but when I attempt to insert a policy compiled with this, it says the type consoletype_exec_t doesn’t exist. N.B. This works on RHEL 6. Thanks, Doug

3 2

Semi-OT / Newbe: Help writing a policy file
by Gilboa Davara 24 Jan '17

24 Jan '17

Hello all, I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works. - avc message:: avc: denied { associate } for pid=234250 comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 - audit2allow: allow sysctl_irq_t proc_t:filesystem associate; As I appreciate the need of solid SELinux policy I rather label my script correctly, as opposed to opening the sysctl_irq_t gate to world+dog. As such, I'd like to create a file label that *extends* the generic bin_t label - lets call it dev_manage_t - and will be used to give a certain set of scripts the ability to modify /proc/irq/XXX/ Now, I tried creating the following policy, and needless to say it failed, miserably, when I tried to restorecon my script files (EPERM). 1. dev_manage.fc: ------------------------------ /sbin/dev_irq_set -- gen_context(unconfined_u:object_r:dev_manage_t,s0) /sbin/dev_irq_fix -- gen_context(unconfined_u:object_r:dev_manage_t,s0) 2. dev_manage.te ------------------------------ module dev_manage 1.0; type dev_manage_t; require { type bin_t; type sysctl_irq_t; class file { search read write getattr open }; class dir { search read write getattr open }; } allow dev_manage_t sysctl_irq_t:file { search read write getattr open }; allow dev_manage_t sysctl_irq_t:dir { search read write getattr open }; Can anyone please point me to the right direction? I tried using exiting .te files as reference (E.g. irabalance.te) but it didn't help much. - Gilboa

2 11

SELinux and user home dirs custom contexts
by info＠joomladev.eu 03 Jan '17

03 Jan '17

I'm using SELinux with CentOS 7 for many years but I have problem with labeling of home dirs. In my policy and in semanage fcontext --list|grep '/var/www/hosts/ak-chalupova.cz' I have custom labels of files: ----------------------------------------------------------------------------------------------------------------------- /var/www/hosts/ak-chalupova.cz(/.*)? all files system_u:object_r:ak-chalupova_cz_t:s0 /var/www/hosts/ak-chalupova.cz/logs(/.*)? all files system_u:object_r:ak-chalupova_cz_log_t:s0 /var/www/hosts/ak-chalupova.cz/mail(/.*)? all files system_u:object_r:ak-chalupova_cz_mail_t:s0 /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/cgi-bin(/.*)? all files system_u:object_r:ak-chalupova_cz_cgi_t:s0 /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/cgi-bin/php.fcgi all files system_u:object_r:ak-chalupova_cz_cgi_exec_t:s0 ----------------------------------------------------------------------------------------------------------------------- but when I run restorecon -R -v /var/www/hosts/ak-chalupova.cz/ it tries to label all files as user_home_t: ----------------------------------------------------------------------------------------------------------------------- restorecon reset /var/www/hosts/ak-chalupova.cz context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_dir_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/.bash_logout context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/mail context unconfined_u:object_r:ak-chalupova_cz_mail_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/.bash_profile context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/logs context unconfined_u:object_r:ak-chalupova_cz_log_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/logs/access_log context system_u:object_r:ak-chalupova_cz_log_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/logs/error_log context system_u:object_r:ak-chalupova_cz_log_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/.bashrc context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/cgi-bin context unconfined_u:object_r:ak-chalupova_cz_cgi_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/cgi-bin/php.ini context unconfined_u:object_r:ak-chalupova_cz_cgi_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/cgi-bin/php.fcgi context unconfined_u:object_r:ak-chalupova_cz_cgi_exec_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/tmp context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_t:s0 restorecon reset /var/www/hosts/ak-chalupova.cz/ak-chalupova.cz/www context unconfined_u:object_r:ak-chalupova_cz_t:s0->unconfined_u:object_r:user_home_t:s0 ----------------------------------------------------------------------------------------------------------------------- Whaty I'm doing wrong? Thangs in advance.

2 2

samba, symlinks and samba_share_fusefs boolean
by Thomas Mueller 23 Dec '16

23 Dec '16

Hi I've created a PR on githob on november 10 to allow samba to manage lnk_fileswith samba_share_fusefs boolean. It already allows to manage files and dirs - but not lnk_files. Until yet, there is no feedback at all. Is a Github PR the right place to send patches or what is the expected workflow? - Thomas https://github.com/fedora-selinux/selinux-policy/pull/170

1 0

Problem in installing newly released policy packages on FEDORA 25
by Parker, Michael D. 19 Dec '16

19 Dec '16

Hmmm…..There seems to be some errors in the last released policies on FEDORA 25 from the standards update repo. . . . Running transaction Upgrading : selinux-policy-3.13.1-225.1.fc25.noarch 1/18 Re-declaration of boolean virt_sandbox_use_fusefs Failed to create node Bad boolean declaration at /var/lib/selinux/targeted/tmp/modules/100/virt/cil:152 semodule: Failed! Upgrading : selinux-policy-targeted-3.13.1-225.1.fc25.noarch 2/18 Re-declaration of boolean virt_sandbox_use_fusefs Failed to create node Bad boolean declaration at /var/lib/selinux/targeted/tmp/modules/100/virt/cil:152 /usr/sbin/semodule: Failed! Upgrading : NetworkManager-libnm-1:1.4.2-2.fc25.x86_64 3/18 Upgrading : NetworkManager-1:1.4.2-2.fc25.x86_64 4/18 Upgrading : selinux-policy-sandbox-3.13.1-225.1.fc25.noarch 5/18 Re-declaration of boolean virt_sandbox_use_fusefs Failed to create node Bad boolean declaration at /var/lib/selinux/targeted/tmp/modules/100/virt/cil:152 semodule: Failed! Upgrading : selinux-policy-mls-3.13.1-225.1.fc25.noarch 6/18 Upgrading : selinux-policy-minimum-3.13.1-225.1.fc25.noarch 7/18 Failed to resolve typeattributeset statement at /var/lib/selinux/minimum/tmp/modules/100/xserver/cil:472 /usr/sbin/semodule: Failed! . . . ***** ***** ***** Michael D. Parker General Atomics – ElectroMagnetics Systems Division (EMS) Michael.d.parker(a)ga.com <<<<< NOTE: Remember to include my middle initial >>>>> +1 858 964 6675 / Office 86-1319 / Cell +1 858 376 7474 16969 Mesamint Street / San Diego / CA / 92127

3 2

rpcbind policy breakage on Fedora25
by David Hampton 19 Dec '16

19 Dec '16

The latest version of the rpcbind package (0.2.4-0) has moved the rpcbind executable from /sbin/rpcbind to /usr/bin/rpcbind. The selinux-policy (3.13.1-224) doesn't yet reflect this change, so the rpcbind executable ends up labeled bin_t instead of rpcbind_exec_t. David

2 1

libvirt and VM on gluster vol
by lejeczek 16 Dec '16

16 Dec '16

hi everyone, I've a quest whose image resides on a gluster vol, with selinux I see: virsh # start rhel-work2 error: Failed to start domain rhel-work2 error: internal error: qemu unexpectedly closed the monitor: (process:57641): GLib-WARNING **: gmem.c:482: custom memory allocation vtable not supported [2016-12-16 14:35:31.748659] E [MSGID: 104007] [glfs-mgmt.c:637:glfs_mgmt_getspec_cbk] 0-glfs-mgmt: failed to fetch volume file (key:QEMU-VMs) [Invalid argument] 2016-12-16T14:35:32.728242Z qemu-kvm: -drive file=gluster://127.0.0.1/QEMU-VMs/rhel-work2.qcow2,format=raw,if=none,id=drive-virtio-disk0: Gluster connection failed for server=127.0.0.1 port=0 volume=QEMU-VMs image=rhel-work2.qcow2 transport=tcp: Permission denied an attempt to catch sealerts I see only: ]$ ausearch -ts 14:28 | egrep -i '(virt|glust|qem)' | audit2allow #============= svirt_t ============== #!!!! WARNING: 'unlabeled_t' is a base type. allow svirt_t unlabeled_t:dir write; and probably a lot more. Before I start looking at silent denials - would there be a boolean for libvirt+gluster ? many thanks, L.

2 3

Re: Relabelling
by mark 05 Dec '16

05 Dec '16

Thomas wrote: > > Am 5. Dezember 2016 17:25:10 MEZ, schrieb m.roth(a)5-cent.us: > >> We've got a really important server on our network - it's a loghost, >>runs dibbler, etc. We had a grub issue, and now, trying to come up, it's taken over half an hour on relabelling... and this is a 1TB (RAID 1) drive, and not more than about a quarter full. >> >>This is not acceptable - even with fsck, you can tell it fastboot. What reasonable and customary practice should we follow to prevent this very long behaviour? Would have a cron job run restortcon -R / once a month help? If not, what else is there? > > It will only relable once when installing selinux or someone created the trigger file /.autorelabel manually. (Actually the installation creates this file). > > Maybe you installed selinux only before last reboot or someone/something created this trigger file out of order? > Sorry, but this is CentOS 6, and has been running for years. There was network work done over the weekend (and my manager had to come in), and we had several issues with this server. For one, grub seemed to have gone south. Once I reinstalled grub via a rescue flash drive, it came up. What created the /.autorelabel, I have no clue. However, the major issue here is *why* relabelling takes vastly longer than fsck. I rebooted well over an hour after it started relabelling - and I have no idea, of course, how much longer it would run, while the forced check fsck took in the neighborhood of half an hour. Btw, the restorecon -R /var that I started at 12:11 is *still* running at 14:23, to compare to fsck. mark

1 0

Re: Relabelling
by Thomas Mueller 05 Dec '16

05 Dec '16

Forgot the list. -------- Ursprüngliche Nachricht -------- Von: Thomas <thomas(a)chaschperli.ch> Gesendet: 5. Dezember 2016 17:53:18 MEZ An: m.roth(a)5-cent.us Betreff: Re: Relabelling It will only relable once when installing selinux or someone created the trigger file /.autorelabel manually. (Actually the installation creates this file). Maybe you installed selinux only before last reboot or someone/something created this trigger file out of order? - Thomas Am 5. Dezember 2016 17:25:10 MEZ, schrieb m.roth(a)5-cent.us: >Ok, folks, > > We've got a really important server on our network - it's a loghost, >runs dibbler, etc. We had a grub issue, and now, trying to come up, >it's taken over half an hour on relabelling... and this is a 1TB (RAID >1) drive, and not more than about a quarter full. > >This is not acceptable - even with fsck, you can tell it fastboot. What >reasonable and customary practice should we follow to prevent this very >long behaviour? Would have a cron job run restortcon -R / once a month >help? If not, what else is there? > > mark >_______________________________________________ >selinux mailing list -- selinux(a)lists.fedoraproject.org >To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux December 2016