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
Re: RHEL 7 consoletype_exec interface issue
by Douglas Brown
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
6 years, 8 months
[PATCH] rawhide-base: Fix wrong type/attribute flavors in require blocks
by James Carter
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
6 years, 10 months
Maintaining file context tags across network transfers
by Jeff Becker
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
6 years, 10 months
Semi-OT / Newbe: Help writing a policy file
by Gilboa Davara
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
6 years, 10 months
Allow getattr on all contexts?
by Xavier Decoud
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
6 years, 10 months
Cannot start MariaDB 5.5.54 post yum update.
by Brad Howe
https://github.com/MariaDB/server/commit/8fcdd6b0ecbb966f4479856efe93a963...
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 };
6 years, 11 months
