Initial context for init
by 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
4 years, 4 months
- 3
- 3
tips for writing portable policy?
by James Ralston
Does anyone have tips on how to write portable policy?
For example, this policy:
gen_tunable(local_custom_gssd_t_permissive, false)
gen_require(`
type gssd_t;
type kernel_t;
type tmp_t;
class capability2 block_suspend;
class file unlink;
class key { read view setattr write };
')
tunable_policy(`local_custom_gssd_t_permissive',`
allow gssd_t kernel_t:key { read view setattr write };
allow gssd_t tmp_t:file unlink;
allow gssd_t self:capability2 block_suspend;
')
…will build on any of (RHEL5, RHEL6, RHEL7), but if you attempt to
load this policy on anything but RHEL7, it will fail with this error:
libsepol.permission_copy_callback: Module local depends on
permission block_suspend in class capability2, not satisfied (No such
file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such
file or directory).
/usr/sbin/semodule: Failed!
A fair amount of the policy we write applies to all of our systems, so
if we have to resort to maintaining separate policy for each of
(RHEL5, RHEL6, RHEL7), there's going to be duplication, and we'd
prefer to avoid that.
Are there any feature-test m4 macros that would ease writing
cross-distro policy?
What techniques do others use to avoid unnecessary duplication of
policy when you need to maintain similar policy on different distros?
Thanks in advance for any tips.
5 years, 1 month
- 1
- 0
Preventing curl | bash
by Sheogorath
Hi,
it's mostly a question out of curiosity but maybe useful for some people.
I wonder if there is a way to prevent a direct piping from curl to bash
using SELinux.
And of course one can download a file and then run bash on it, but a
simple rule that prevents direct piping would at least give a heads up
about it.
--
Signed
Sheogorath
5 years, 1 month
- 4
- 4
- ← Newer
- 1
- Older →