selinux June 2017

selinux@lists.fedoraproject.org

7 participants
4 discussions

Initial context for init
by Philip Seeley 02 Aug '19

02 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

Cannot transition to radicale_t domain
by Juan Orti Alcaine 30 Jun '17

30 Jun '17

Hi, I'm troubleshooting the radicale policy but I cannot figure why the service fails to transition to radicale_t. It runs in the init_t domain. Could anybody give a look to the policy to check if there is something wrong? I don't know what can be the problem. Thank you. http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.te http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.fc http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.if

5 12

Enforcing directory access control using categories
by Bill D 22 Jun '17

22 Jun '17

Hello, Is it possible to enforce directory read/write/execute control using categories? For example, using a category, I would like Linux users assigned to that category to have read/write/execute rights to directory /opt/foo. Other Linux users that do not have that category assigned should not have read/write/execute access to /opt/foo I know this can be done with normal DAC procedures using groups and/or file permission tools such as chmod and chown. And I also know that it can done with SELinux TE (i.e create an SELinux security policy) But can it be done by using just categories? Regards, Bill

2 8

ssh authorized key failure
by David Highley 10 Jun '17

10 Jun '17

Since the last selinux update on May 20, selinux-policy-targeted-3.13.1-225.16.fc25.noarch. My Android client Juice ssh mosh encryption key fails to authenticate. First found avc that was due to the use_nfs_home_dirs --> off getting turned off. Still fails with the following journal information, no avc logged. We have also tried turning up the log level on sshd and totally disable selinux. So given that we did a total disable of selinux and it still fails we are at a loss where to go next. Jun 09 19:06:25 spruce audit[2267]: CRYPTO_SESSION pid=2267 uid=0 auid=429496729 5 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start dire ction=from-client cipher=aes128-ctr ksize=128 mac=hmac-sha1 pfs=ecdh-sha2-nistp2 56 spid=2268 suid=74 rport=37507 laddr=10.2.2.2 lport=22 exe="/usr/sbin/sshd" h ostname=? addr=74.92.228.89 terminal=? res=success' Jun 09 19:06:25 spruce audit[2267]: USER_AUTH pid=2267 uid=0 auid=4294967295 ses =4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="dh ighley" exe="/usr/sbin/sshd" hostname=? addr=74.92.228.89 terminal=ssh res=failed' Jun 09 19:06:25 spruce kernel: audit: type=1100 audit(1497060385.743:353): pid=2267 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="dhighley" exe="/usr/sbin/sshd" hostname=? addr=74.92.228.89 terminal=ssh res=failed' Jun 09 19:06:25 spruce sshd[2267]: error: Received disconnect from 74.92.228.89 port 37507:3: com.jcraft.jsch.JSchException: Auth cancel [preauth] Jun 09 19:06:25 spruce audit[2267]: CRYPTO_KEY_USER pid=2267 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:d1:e7:9d:df:7e:c5:05:7c:22:2c:44:d4:21:c3:3b:02:ea:2c:32:9a:cd:b6:c3:93:d7:22:37:20:3d:75:1d:bb direction=? spid=2268 suid=74 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' Jun 09 19:06:25 spruce kernel: audit: type=2404 audit(1497060385.754:354): pid=2267 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:d1:e7:9d:df:7e:c5:05:7c:22:2c:44:d4:21:c3:3b:02:ea:2c:32:9a:cd:b6:c3:93:d7:22:37:20:3d:75:1d:bb direction=? spid=2268 suid=74 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' Jun 09 19:06:25 spruce kernel: audit: type=2404 audit(1497060385.754:355): pid=2267 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=2268 suid=74 rport=37507 laddr=10.2.2.2 lport=22 exe="/usr/sbin/sshd" hostname=? addr=74.92.228.89 terminal=? res=success' Jun 09 19:06:25 spruce kernel: audit: type=1109 audit(1497060385.754:356): pid=2267 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/sbin/sshd" hostname=74.92.228.89 addr=74.92.228.89 terminal=ssh res=failed'

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux June 2017