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
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[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 
To:	Philip Seeley/Australia/IBM@IBMAU,
            [e-mail]
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
> [e-mail]

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