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
Symlink or bind mount?
by Gionatan Danti
Being a regular user of selinux, I often face situations where some
common directories (es: /var/log or /var/lib) needs to be redirected to
other partitions/volumes.
I very simple approach, without impacting selinux at all, is to mount a
volume in the precise path I need to replace - ie mount
/dev/vg_test/lv_lib in /var/lib. However, this is a
one-volume-for-directory approach and I would like to avoid it.
The other possibility is to create single big volume with multiple
directories, mount it, and
1) symlink the original dir (ie: /var/log) to the new one (ie:
/mnt/volume/var/log);
2) use a bind mount to re-mount the destination dir
(/mnt/volume/var/log) on the original one (/var/log).
The symlink approach is self-explaining, as anyone listing the original
directory will immediately notice it. However, it sometime require
extensive customization of the selinux policy, a thing I try hard to
avoid.
The bind mount approach is somewhat simpler from selinux standpoint, but
it much less discoverable by a simple "ls".
What do you feel is the preferred approach? I am missing something?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
5 years, 7 months
dvdemux notifications
by Andrea Vai
Hi all,
I am getting continuous selinux notifications about a "dvdemux"
process, and I don't know how to manage it.
Some of the (revelant?) data in the message window:
SELinux impedisce a dvdemux0:sink un accesso execstack su un processo.
[Translation from italian: SELinux denies to dvdemux0:sink an execstac
access on a process]
type=AVC msg=audit(1518457458.85:1216): avc: denied { execstack }
for pid=3263 comm="gst-plugin-scan"
scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023
tclass=process permissive=0
Hash: dvdemux0:sink,thumb_t,thumb_t,process,execstack
Can you help me please? I have a lot of notifications every day. I
don't know selinux so even a couple of hints would be very
appreciated.
Let me know if I have to provide more information.
Thank you very much,
Andrea (Fedora 27)
5 years, 9 months
Can third party kernel modules be inserted in selinux system?
by Srinivasa Rao Ragolu
Hi All,
I have enabled SELINUX in kernel and added respective userland packages to
rootfs on my embedded environment.
Now I have downloaded some third party kernel modules and tried to insert,
and I got below messages. Got inserted but no device nodes got created,
means partial
*insmod if-susi.ko *
*[ 609.367590] kfopen failed! (-2)*
*[ 609.370755] kfopen failed! (-2)*
*[ 609.500194] kfopen failed! (-2)*
*[ 609.503351] kfopen failed! (-2)*
Q) Can kernel modules from third party, be inserted without issues (or) do
we need to build those modules using SELINUX kernel?
Thanks,
Srinivas.
5 years, 9 months
implementing AppLocker-like functionality with SELinux?
by James Ralston
Our users have a tendency to install software that, per company
policy, is not permitted to be installed. Most users have sudo
privileges on their hosts, which is how they install the software.
In the Windows world, AppLocker can be used to restrict users from
executing programs, by path, publisher, or hash.
Has anyone contemplating using SELinux to implement something similar
to AppLocker, but for Linux?
One thought would be to roll a custom policy that creates a new type
(say, forbidden_t), and then essentially prevent all access for that
type. But this would not work unless we changed the default SELinux
User for users from unconfined_u to user_r, and that has the potential
to be very disruptive.
Even if we did this, it wouldn't permit us to blacklist by hash; it
would be dependent on the path location.
We run Clam Antivirus on our hosts, so something we are thinking of
doing is writing custom rules to flag the unwanted programs as
malware. But unless we also used fanotify-based blocking with ClamAV,
that wouldn't prevent users from executing the unwanted programs.
Note that we *are not* trying to stop malicious users from
deliberately installing software they know is forbidden. Our main
problem is that our users typically don't bother to consult the
"forbidden software" list before installing. So we're attempting to
catch users who are unintentionally doing the wrong thing, not
deliberately doing the wrong thing.
Has anyone else already explored this issue? If so, what were your
conclusions?
5 years, 9 months
SELinux read-only rootfs
by sajjad ahmed
Hi,
Can SELinux enable Linux boot/operate with read-only rootfs? I'm working on an IoT project and read-only rootfs is a security constraint and SELinux enabled image is unable to properly boot/operate in this environment. Is this SELinux limitation, or we can fix this with proper mount configurations.
ThanksSajjad Ahmed
5 years, 9 months
