selinux January 2017

selinux@lists.fedoraproject.org

12 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

[PATCH] rawhide-base: Fix wrong type/attribute flavors in require blocks
by James Carter 01 Feb '17

01 Feb '17

In userdom_execmod_user_home_files(), user_home_type is an attribute, not a type. In userdom_read_inherited_user_home_content_files(), admin_home_t is a type, not an attribute. In userdom_dontaudit_read_inherited_admin_home_files(), admin_home_t is a type, not an attribute. Signed-off-by: James Carter <jwcart2(a)tycho.nsa.gov> --- policy/modules/system/userdomain.if | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if index 269ce67..4b0a3ed 100644 --- a/policy/modules/system/userdomain.if +++ b/policy/modules/system/userdomain.if @@ -4925,7 +4925,7 @@ interface(`userdom_users_dgram_send',` # interface(`userdom_execmod_user_home_files',` gen_require(` - type user_home_type; + attribute user_home_type; ') allow $1 user_home_type:file execmod; @@ -5321,7 +5321,7 @@ interface(`userdom_read_inherited_user_home_content_files',` # interface(`userdom_dontaudit_read_inherited_admin_home_files',` gen_require(` - attribute admin_home_t; + type admin_home_t; ') dontaudit $1 admin_home_t:file read_inherited_file_perms; @@ -5339,7 +5339,7 @@ interface(`userdom_dontaudit_read_inherited_admin_home_files',` # interface(`userdom_dontaudit_append_inherited_admin_home_file',` gen_require(` - attribute admin_home_t; + type admin_home_t; ') dontaudit $1 admin_home_t:file append_inherited_file_perms; -- 2.7.4

2 2

Maintaining file context tags across network transfers
by Jeff Becker 31 Jan '17

31 Jan '17

Hi. I was hoping to use sftp/vsftpd to transfer a file between two hosts (both) running SELinux, and have the file tag remain the same on both the source and destination. However, it seems that the behaviour I see is like cp (without any options) - that is, the destination file inherits the tag of its containing directory. Is there any way to get the behaviour to be more like mv, in which the tag is maintained? If there is a better way than ftp, I'd be interested in hearing about it. Thanks for your help. Jeff Becker

2 1

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

program produces message - org.freedesktop.DBus.Error.Spawn.ExecFailed
by Martin Gansser 24 Jan '17

24 Jan '17

a user has told me, when he run boomaga, the following error message appears: Processing - [Boomaga] home: /home/justin Stopped - [Boomaga] org.freedesktop.DBus.Error.Spawn.ExecFailed : Failed to execute program org.boomaga: No such file or directory I use this selinux rules within booamga: https://martinkg.fedorapeople.org/Review/test/boomaga/ Which policy rules must be changed ?

2 2

Allow getattr on all contexts?
by Xavier Decoud 17 Jan '17

17 Jan '17

Hi, perhaps a rookie question... I've installed keepalived 1.2.13 (from official CentOS repos) on CentOS 7.3. A check-script uses pidof to monitor whether a certain process is still alive. Now I get alerts like the following on all contexts of all running processes: setroubleshoot: SELinux is preventing /usr/sbin/killall5 from getattr access on the file /usr/sbin/irqbalance. For complete SELinux messages. run sealert -l 5db84650-63a7-408c-b8a0-34031c77b6a4 It's clear to me why. killall5 searches for process I'd like to monitor. Sure, one can create a loadable monitor to allow or to dontlog (except the context of the monitored process). But, what about i.e. services installed in the future? Everytime there'll be a new process with a new context there'll be a new alert. Is there something like a wildcard to allow keepalived to use killall5 / getattr on all contexts? I don't like to switch keepalived to unconfined_exec_t just to get rid of the alerts. BTW, these alerts were not present under CentOS 6.8 KR Xavier

2 2

Re: New Blog on how SELinux blocked Docker container escape.
by Tracy Reed 14 Jan '17

14 Jan '17

On Fri, Jan 13, 2017 at 11:48:20AM PST, Daniel J Walsh spake thusly: > http://rhelblog.redhat.com/2017/01/13/docker-0-day-stopped-cold-by-selinux/ I have long been of the opinion that it is this sort of thing which best advocates the use of SELinux. We need more examples like this. I posted this to reddit a couple years ago: https://www.reddit.com/r/linux/comments/1xdokz/selinux_saved_our_asses_xpos… And just a few months ago we had another SELinux save. I would say that in the years I've been using SELinux I've probably seen 5 cases where SELinux successfully contained an attack. I wish I would have written them all up at the time. Those 5 saves definitely made it worth it. Check out the comments on that reddit post, Daniel. :) -- Tracy Reed

2 1

Cannot start MariaDB 5.5.54 post yum update.
by Brad Howe 06 Jan '17

06 Jan '17

https://github.com/MariaDB/server/commit/8fcdd6b0ecbb966f4479856efe93a963a7… Change committed 12/24/2016 [root@server~]# audit2allow -w -a type=AVC msg=audit(1483109493.114:191353): avc: denied { setgid } for pid=19833 comm="mysqld_safe_hel" capability=6 scontext=unconfined_u:system_r:mysqld_safe_t:s0 tcontext=unconfined_u:system_r:mysqld_safe_t:s0 tclass=capability Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. [root@server ~]# audit2allow -a #============= mysqld_safe_t ============== allow mysqld_safe_t self:capability { setgid setuid };

1 1

program requires SELinux policy to write to ~/.cache directory
by Martin Gansser 05 Jan '17

05 Jan '17

Hi, i am the package maintainer of boomaga and users told me that there is a problem with access rights, when writing to ~/.cache directory. I created already a selinux package for testing: https://martinkg.fedorapeople.org/Review/test/boomaga/ however, I have only little knowledge regarding selinux. A bugzilla bug report also exists: https://bugzilla.redhat.com/show_bug.cgi?id=1409115 Can someone test the package and if necessary, help with changes?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux January 2017