plymouth is started very early in the boot process. Looks
like before the SELinux policy is loaded so plymouthd is
running as kernel_t rather than plymouthd_t. Due to this
I needed to allow a few permissions on kernel_t to get
the system to boot.
type=AVC msg=audit(1554917011.127:225): avc: denied { write } for pid=2585 comm="plymouthd" name="plymouth" dev="tmpfs" ino=18877 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_run_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1554917011.127:226): avc: denied { remove_name } for pid=2585 comm="plymouthd" name="pid" dev="tmpfs" ino=18883 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_run_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1554917011.127:227): avc: denied { unlink } for pid=2585 comm="plymouthd" name="pid" dev="tmpfs" ino=18883 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1554917011.116:224): avc: denied { write } for pid=2585 comm="plymouthd" name="boot-duration" dev="dm-16" ino=2097285 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:plymouthd_var_lib_t:s0 tclass=file permissive=1
type=AVC msg=audit(1555069712.938:237): avc: denied { ioctl } for pid=2554 comm="plymouthd" path="/dev/dri/card0" dev="devtmpfs" ino=12229 ioctlcmd=64b1 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0
CRIU can influence the PID of the threads it wants to create.
CRIU uses /proc/sys/kernel/ns_last_pidto tell the kernel which
PID it wants for the next clone().
So it has to write to that file. This feels like a problematic as
it opens up the container writing to all sysctl_kernel_t.
Using new label container_t will just write to
sysctl_kernel_ns_last_pid_t instad writing to more generic
sysctl_kernel_t files.
Remove complement (~) and wildcard (*) in allow rules so that there are no
unintentional additions when new permissions are declared.
This patch does not add or remove permissions from any rules.
When a program uses init_module() to load a module, the kernel checks
for system:load_module permission in the process type [1].
For example when systemd loads ip_tables modules (since
1d3087978a),
the following AVC denial gets reported:
avc: denied { module_load } for pid=1 comm="systemd"
scontext=system_u:system_r:init_t tcontext=system_u:system_r:init_t
tclass=system permissive=1
[1] The relevant kernel code is selinux_kernel_module_from_file() in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c?h=v4.11#n3836
/* init_module */
if (file == NULL)
return avc_has_perm(sid, sid, SECCLASS_SYSTEM,
SYSTEM__MODULE_LOAD, NULL);
In this code, both source and target SIDs are current_sid().
Every Infiniband network will have a default pkey, so that is labeled.
The rest of the pkey configuration is network specific. The policy allows
access to the default and unlabeled pkeys for sysadm and staff users.
kernel_t is allowed access to all pkeys, which it needs to process and
route management datagrams.
Endports are all unlabeled by default, sysadm users are allowed to
manage the subnet on unlabeled endports. kernel_t is allowed to manage
the subnet on all ibendports, which is required for configuring the HCA.
This patch requires selinux series: "SELinux user space support for
Infiniband RDMA", due to the new ipkeycon labeling mechanism.
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
This patch doesn't do everything that is needed to have systemd-nspawn work.
But it does everything that is needed and which I have written in a clear and
uncontroversial way. I think it's best to get this upstream now and then
either have a separate discussion about the more difficult issues, or wait
until I devise a way of solving those problems that's not too hacky.
Who knows, maybe someone else will devise a brilliant solution to the remaining
issues after this is accepted upstream.
Also there's a tiny patch for systemd_machined_t that is required by
systemd_nspawn_t.
Description: systemd-nspawn
Author: Russell Coker <russell@coker.com.au>
Last-Update: 2017-03-29
This patch adds missing permissions in the kernel module that prevent
to run it without the unconfined module.
This second version improves the comment section of new interfaces:
"Domain" is replaced by "Domain allowed access".
Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
On Tuesday, 2 August 2016 7:59:28 PM AEDT Chris PeBenito wrote:
> On 07/31/16 08:34, Russell Coker wrote:
> > The following patch deals with a single binary for modutils, so depmod_t,
> > and insmod_t are merged.
>
> Since the main SELinux distros (including RHEL/CentOS 7) all have merged
> modutils these days, I'm open to taking a patch that fully merges these
> domains (in which case renaming to kmod_t, with proper aliasing seems
> the best idea).
>
> However, it's been some time since I used a busybox-based system; does
> busybox still have separated tools? Yes, this is a bit of an obvious
> question since busybox is also single-binary, but IIRC, the embedded
> guys made some tiny helper scripts or executables so proper
> transitioning could occur. Separate domains may still make sense.
As we have had no response from Busybox users in the last 3 months and also no
response to the thread Luis started in 2013 I think it's safe to assume that
they don't need this.
I've attached a new patch which renames to kmod_t as you suggested. Please
consider it for inclusion.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Description: Change modutils policy to match the use of a single binary
Author: Russell Coker <russell@coker.com.au>
Last-Update: 2014-06-25
The "module_load" permission has been recently added to the "system"
class (kernel 4.7).
The following patch updates the Reference Policy so that the new
permission is allowed when a kernel module should be loaded.
To preserve the module encapsulation, a new interface is defined
in the kernel files module and that interface is then used in the
kernel module.
A short note is added about unneeded permissions that set the
kernel scheduling parameters (might lead to service disruption).
Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
When a device gets removed, for example with "cryptsetup close",
kdevtmpfs (a kernel thread) removes its entry from devtmpfs filesystem:
avc: denied { unlink } for pid=48 comm="kdevtmpfs"
name="dm-4" dev="devtmpfs" ino=144111
scontext=system_u:system_r:kernel_t
tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
Allow this access on systems using systemd.