Initial context for init

[Philip Seeley]

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

[Miroslav Grepl]

On 07/01/2016 06:47 AM, Philip Seeley wrote:
>  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 
Hi Phil,
what is your OS and version of selinux-policy?

>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/[e-mail]
>   

-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

[Philip Seeley]

Hi Miroslav,

Thanks for the reply.

We're fully patched RHEL6 and selinux-policy-targeted-3.7.19-292.

We've done a bit more investigation...

After modifying /etc/selinux/targeted/contexts/initrc_context to:

system_u:system_r:initrc_t:s0-s0:c0.c1023

we've also found that categories get removed during domain transitions in
the initrc scripts.

For this example we built a custom sssd package so that the output of the
sssd restart doesn't go to /dev/null and added “echo $0 $(id)” to the top
of /sbin/service and /etc/init.d/sssd.

When we restarted the sssd service we get:

# run_init bash -c 'service sssd restart'
Authenticating pseeley.
Password:
/sbin/service uid=0(root) gid=0(root) groups=0(root)
context=system_u:system_r:initrc_t:s0-s0:c0.c1023
/etc/init.d/sssd uid=0(root) gid=0(root) groups=0(root)
context=system_u:system_r:initrc_t:s0-s0:c0.c1023
Stopping sssd:                                             [  OK  ]
Starting sssd:                                             [  OK  ]

but when this is called from rpm_script_t we get:

# run_init bash -c 'yum reinstall -y
-q /home/pseeley/sssd-1.13.3-22.el6_8.4.x86_64.rpm'
Authenticating pseeley.
Password:
/sbin/service uid=0(root) gid=0(root) groups=0(root)
context=system_u:system_r:rpm_script_t:s0-s0:c0.c1023
/etc/init.d/sssd uid=0(root) gid=0(root) groups=0(root)
context=system_u:system_r:initrc_t:s0
Stopping sssd: [  OK  ]
Starting sssd: [  OK  ]

So the domain transition rpm_script_t->initrc_t also removes all the
categories.

The odd thing is under MLS this doesn't happen. We've not been able to
actually confirmed this is the reason, but in policy/modules/system/init.te
we see the statement:

ifdef(`enable_mls',`
        kernel_ranged_domtrans_to(init_t, init_exec_t, s0 - mls_systemhigh)
')

but we're not sure if this would affect the initrc_t type rather than the
init_t type.

Thanks

Phil



From:	Miroslav Grepl <mgrepl(a)redhat.com
>  
To:	Philip Seeley/Australia/IBM@IBMAU,
            selinux(a)lists.fedoraproject.org
Date:	18/07/2016 16:10
Subject:	Re: Initial context for init



On 07/01/2016 06:47 AM, Philip Seeley wrote:
>  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:Geoff Robertson
>
>  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
>  
Hi Phil,
what is your OS and version of selinux-policy?

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>
>  
https://lists.fedoraproject.org/admin/lists/[e-mail]
>  

--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

SElinux and proxies

[Jayson Hurst]

I am running into an issue using a 2fa binary through a squid proxy. I am writing the
selinux policy for the 2fa binary, but when when I attempt to access the system via ssh I
am seeing the following AVC

type=AVC msg=audit(1564694436.236:1003): avc:  denied  { name_connect } for  pid=30620
comm="starling" dest=3128 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:squid_port_t:s0 tclass=tcp_socket permissive=0

The following will fix it for the squid proxy:

corenet_tcp_connect_squid_port(sshd_t)

but what if tomorrow I decide to use a different proxy, that uses a different port. What
is the correct way to set this up so that regardless of what proxy is being used on
whatever port I don't have to update my policy every time?

Thanks,

Jayson