I made some changes to the policy to get plymouth working
in enforcing. I have noticed that since plymouthd is started
very early during boot it is running as kernel_t. Some
of the permissions are for kernel_t even though they are
for the plymouthd process.
Dave Sugar (5):
Allow xdm (lightdm) start plymouth
Dave Sugar (3):
Allow xdm (lightdm) start plymouth
Changes to support plymouth working in enforcing
Some items that seem they can be dontaudited for plymouthd
policy/modules/kernel/devices.if | 18 +++++++++++++
policy/modules/kernel/kernel.te | 5 +++-
policy/modules/services/plymouthd.if | 38 ++++++++++++++++++++++++++++
policy/modules/services/plymouthd.te | 5 ++++
policy/modules/services/xserver.te | 4 +++
5 files changed, 69 insertions(+), 1 deletion(-)
--
2.20.1
type=AVC msg=audit(1554917007.995:194): avc: denied { execute } for pid=7647 comm="lightdm" name="plymouth" dev="dm-1" ino=6508817 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:plymouth_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1554917007.995:194): avc: denied { read open } for pid=7647 comm="lightdm" path="/usr/bin/plymouth" dev="dm-1" ino=6508817 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:plymouth_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1554917007.995:194): avc: denied { execute_no_trans } for pid=7647 comm="lightdm" path="/usr/bin/plymouth" dev="dm-1" ino=6508817 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:plymouth_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1554917007.995:194): avc: denied { map } for pid=7647 comm="plymouth" path="/usr/bin/plymouth" dev="dm-1" ino=6508817 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:plymouth_exec_t:s0 tclass=file permissive=1
Signed-off-by: Dave Sugar <[email protected]>
---
policy/modules/services/xserver.te | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
index a2b08a89..38c28678 100644
--- a/policy/modules/services/xserver.te
+++ b/policy/modules/services/xserver.te
@@ -615,6 +615,10 @@ optional_policy(`
mta_dontaudit_getattr_spool_files(xdm_t)
')
+optional_policy(`
+ plymouthd_domtrans_plymouth(xdm_t)
+')
+
optional_policy(`
resmgr_stream_connect(xdm_t)
')
--
2.20.1
type=AVC msg=audit(1554983723.772:784): avc: denied { create } for pid=8123 comm="plymouthd" scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:system_r:plymouthd_t:s0 tclass=netlink_kobject_uevent_socket permissive=0
type=AVC msg=audit(1555070131.882:1648): avc: denied { getattr } for pid=8634 comm="plymouthd" path="/run/udev/data/c226:0" dev="tmpfs" ino=29946 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1555070131.903:1652): avc: denied { open } for pid=8634 comm="plymouthd" path="/run/udev/data/+drm:card0-DP-1" dev="tmpfs" ino=31856 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1555070131.903:1652): avc: denied { read } for pid=8634 comm="plymouthd" name="+drm:card0-DP-1" dev="tmpfs" ino=31856 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
Signed-off-by: Dave Sugar <[email protected]>
---
policy/modules/services/plymouthd.te | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/policy/modules/services/plymouthd.te b/policy/modules/services/plymouthd.te
index 835ee035..6352375d 100644
--- a/policy/modules/services/plymouthd.te
+++ b/policy/modules/services/plymouthd.te
@@ -38,6 +38,7 @@ dontaudit plymouthd_t self:capability dac_override;
allow plymouthd_t self:capability2 block_suspend;
allow plymouthd_t self:process { signal getsched };
allow plymouthd_t self:fifo_file rw_fifo_file_perms;
+dontaudit plymouthd_t self:netlink_kobject_uevent_socket create;
allow plymouthd_t self:unix_stream_socket create_stream_socket_perms;
manage_dirs_pattern(plymouthd_t, plymouthd_spool_t, plymouthd_spool_t)
@@ -87,6 +88,10 @@ optional_policy(`
gnome_read_generic_home_content(plymouthd_t)
')
+optional_policy(`
+ udev_dontaudit_rw_pid_files(plymouthd_t)
+')
+
optional_policy(`
sssd_stream_connect(plymouthd_t)
')
--
2.20.1
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.
Please note that in this case I have the harddisk encrypted
with LUKS so when plymouthd is started the harddisk is not
unlocked yet. I don't know if the permissions are different
in the case when LUKS is not involved.
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
Signed-off-by: Dave Sugar <[email protected]>
---
policy/modules/kernel/devices.if | 18 +++++++++++++
policy/modules/kernel/kernel.te | 5 +++-
policy/modules/services/plymouthd.if | 38 ++++++++++++++++++++++++++++
3 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
index 78a95ce8..d1cdf933 100644
--- a/policy/modules/kernel/devices.if
+++ b/policy/modules/kernel/devices.if
@@ -1939,6 +1939,24 @@ interface(`dev_setattr_dri_dev',`
setattr_chr_files_pattern($1, device_t, dri_device_t)
')
+########################################
+## <summary>
+## IOCLT the dri devices.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`dev_ioctl_dri_dev',`
+ gen_require(`
+ type device_t, dri_device_t;
+ ')
+
+ allow $1 dri_device_t:chr_file ioctl;
+')
+
########################################
## <summary>
## Read and write the dri devices.
diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
index b9ae4079..d230a5a2 100644
--- a/policy/modules/kernel/kernel.te
+++ b/policy/modules/kernel/kernel.te
@@ -397,9 +397,12 @@ optional_policy(`
')
optional_policy(`
- plymouthd_read_lib_files(kernel_t)
+ dev_ioctl_dri_dev(kernel_t)
+
+ plymouthd_delete_pid_files(kernel_t)
plymouthd_read_pid_files(kernel_t)
plymouthd_read_spool_files(kernel_t)
+ plymouthd_rw_lib_files(kernel_t)
term_use_ptmx(kernel_t)
term_use_unallocated_ttys(kernel_t)
diff --git a/policy/modules/services/plymouthd.if b/policy/modules/services/plymouthd.if
index 04e0c734..3cc08b96 100644
--- a/policy/modules/services/plymouthd.if
+++ b/policy/modules/services/plymouthd.if
@@ -192,6 +192,25 @@ interface(`plymouthd_read_lib_files',`
read_files_pattern($1, plymouthd_var_lib_t, plymouthd_var_lib_t)
')
+########################################
+## <summary>
+## Read and write plymouthd lib files.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`plymouthd_rw_lib_files',`
+ gen_require(`
+ type plymouthd_var_lib_t;
+ ')
+
+ files_search_var_lib($1)
+ rw_files_pattern($1, plymouthd_var_lib_t, plymouthd_var_lib_t)
+')
+
########################################
## <summary>
## Create, read, write, and delete
@@ -232,6 +251,25 @@ interface(`plymouthd_read_pid_files',`
allow $1 plymouthd_var_run_t:file read_file_perms;
')
+########################################
+## <summary>
+## Delete the plymouthd pid files.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`plymouthd_delete_pid_files',`
+ gen_require(`
+ type plymouthd_var_run_t;
+ ')
+
+ files_search_pids($1)
+ delete_files_pattern($1, plymouthd_var_run_t, plymouthd_var_run_t)
+')
+
########################################
## <summary>
## All of the rules required to
--
2.20.1
What is netlink_kobject_uevent_socket? Do we have a place we can document
this sort of thing to make it easier to determine whether access is required
and what the implications of such access are?
On Saturday, 13 April 2019 5:39:32 AM AEST Sugar, David wrote:
> type=AVC msg=audit(1554983723.772:784): avc: denied { create } for
> pid=8123 comm="plymouthd" scontext=system_u:system_r:plymouthd_t:s0
> tcontext=system_u:system_r:plymouthd_t:s0
> tclass=netlink_kobject_uevent_socket permissive=0
> type=AVC msg=audit(1555070131.882:1648): avc: denied { getattr } for
> pid=8634 comm="plymouthd" path="/run/udev/data/c226:0" dev="tmpfs"
> ino=29946 scontext=system_u:system_r:plymouthd_t:s0
> tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1555070131.903:1652): avc: denied { open } for
> pid=8634 comm="plymouthd" path="/run/udev/data/+drm:card0-DP-1" dev="tmpfs"
> ino=31856 scontext=system_u:system_r:plymouthd_t:s0
> tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1555070131.903:1652): avc: denied { read } for
> pid=8634 comm="plymouthd" name="+drm:card0-DP-1" dev="tmpfs" ino=31856
> scontext=system_u:system_r:plymouthd_t:s0
> tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
> Signed-off-by: Dave Sugar <[email protected]>
> ---
> policy/modules/services/plymouthd.te | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/policy/modules/services/plymouthd.te
> b/policy/modules/services/plymouthd.te
index 835ee035..6352375d 100644
> --- a/policy/modules/services/plymouthd.te
> +++ b/policy/modules/services/plymouthd.te
> @@ -38,6 +38,7 @@ dontaudit plymouthd_t self:capability dac_override;
> allow plymouthd_t self:capability2 block_suspend;
> allow plymouthd_t self:process { signal getsched };
> allow plymouthd_t self:fifo_file rw_fifo_file_perms;
> +dontaudit plymouthd_t self:netlink_kobject_uevent_socket create;
> allow plymouthd_t self:unix_stream_socket create_stream_socket_perms;
>
> manage_dirs_pattern(plymouthd_t, plymouthd_spool_t, plymouthd_spool_t)
> @@ -87,6 +88,10 @@ optional_policy(`
> gnome_read_generic_home_content(plymouthd_t)
> ')
>
> +optional_policy(`
> + udev_dontaudit_rw_pid_files(plymouthd_t)
> +')
> +
> optional_policy(`
> sssd_stream_connect(plymouthd_t)
> ')
> --
> 2.20.1
>
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Saturday, 13 April 2019 5:39:31 AM AEST Sugar, David wrote:
> 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.
Could plymouth re-exec itself or do a dynamic domain transition to get the
right domain?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 4/12/19 10:43 PM, Russell Coker wrote:
> On Saturday, 13 April 2019 5:39:31 AM AEST Sugar, David wrote:
>> 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.
>
> Could plymouth re-exec itself or do a dynamic domain transition to get the
> right domain?
>
I don't see a way in the plymouth.conf or other configuration file to
have plymouth re-exec.
On 4/12/19 10:33 PM, Russell Coker wrote:
> What is netlink_kobject_uevent_socket? Do we have a place we can document
> this sort of thing to make it easier to determine whether access is required
> and what the implications of such access are?
>
I'm really not sure either. But, please note, that this patch is
dontaudit rules to quiet some denials that didn't seem to have any
negative side effect. If this patch isn't applied things will still
function, just have some entries in the audit logs.
> On Saturday, 13 April 2019 5:39:32 AM AEST Sugar, David wrote:
>> type=AVC msg=audit(1554983723.772:784): avc: denied { create } for
>> pid=8123 comm="plymouthd" scontext=system_u:system_r:plymouthd_t:s0
>> tcontext=system_u:system_r:plymouthd_t:s0
>> tclass=netlink_kobject_uevent_socket permissive=0
>
>> type=AVC msg=audit(1555070131.882:1648): avc: denied { getattr } for
>> pid=8634 comm="plymouthd" path="/run/udev/data/c226:0" dev="tmpfs"
>> ino=29946 scontext=system_u:system_r:plymouthd_t:s0
>> tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
>> type=AVC msg=audit(1555070131.903:1652): avc: denied { open } for
>> pid=8634 comm="plymouthd" path="/run/udev/data/+drm:card0-DP-1" dev="tmpfs"
>> ino=31856 scontext=system_u:system_r:plymouthd_t:s0
>> tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
>> type=AVC msg=audit(1555070131.903:1652): avc: denied { read } for
>> pid=8634 comm="plymouthd" name="+drm:card0-DP-1" dev="tmpfs" ino=31856
>> scontext=system_u:system_r:plymouthd_t:s0
>> tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
>> Signed-off-by: Dave Sugar <[email protected]>
>> ---
>> policy/modules/services/plymouthd.te | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/policy/modules/services/plymouthd.te
>> b/policy/modules/services/plymouthd.te
> index 835ee035..6352375d 100644
>> --- a/policy/modules/services/plymouthd.te
>> +++ b/policy/modules/services/plymouthd.te
>> @@ -38,6 +38,7 @@ dontaudit plymouthd_t self:capability dac_override;
>> allow plymouthd_t self:capability2 block_suspend;
>> allow plymouthd_t self:process { signal getsched };
>> allow plymouthd_t self:fifo_file rw_fifo_file_perms;
>> +dontaudit plymouthd_t self:netlink_kobject_uevent_socket create;
>> allow plymouthd_t self:unix_stream_socket create_stream_socket_perms;
>>
>> manage_dirs_pattern(plymouthd_t, plymouthd_spool_t, plymouthd_spool_t)
>> @@ -87,6 +88,10 @@ optional_policy(`
>> gnome_read_generic_home_content(plymouthd_t)
>> ')
>>
>> +optional_policy(`
>> + udev_dontaudit_rw_pid_files(plymouthd_t)
>> +')
>> +
>> optional_policy(`
>> sssd_stream_connect(plymouthd_t)
>> ')
>> --
>> 2.20.1
>>
>
>
On Saturday, 13 April 2019 1:26:06 PM AEST Sugar, David wrote:
> On 4/12/19 10:33 PM, Russell Coker wrote:
> > What is netlink_kobject_uevent_socket? Do we have a place we can document
> > this sort of thing to make it easier to determine whether access is
> > required and what the implications of such access are?
>
> I'm really not sure either. But, please note, that this patch is
> dontaudit rules to quiet some denials that didn't seem to have any
> negative side effect. If this patch isn't applied things will still
> function, just have some entries in the audit logs.
There's a good chance the action in question isn't an accident and some aspect
of the program's functionality will be changed. I think it's best to have an
idea of what the issue was before putting in a dontaudit rule, if some
configuration of that program actually needs such functionality then a
dontaudit will make it inconvenient to track it down.
Have you tried running strace or ltrace to see what it's doing?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Saturday, 13 April 2019 1:23:15 PM AEST Sugar, David wrote:
> On 4/12/19 10:43 PM, Russell Coker wrote:
>
> > On Saturday, 13 April 2019 5:39:31 AM AEST Sugar, David wrote:
> >
> >> 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.
> >
> >
> > Could plymouth re-exec itself or do a dynamic domain transition to get
> > the
> > right domain?
> >
>
>
> I don't see a way in the plymouth.conf or other configuration file to
> have plymouth re-exec.
Probably need to hack the plymouth source.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Sat, Apr 13, 2019 at 02:24:45PM +1000, Russell Coker wrote:
> On Saturday, 13 April 2019 1:23:15 PM AEST Sugar, David wrote:
> > On 4/12/19 10:43 PM, Russell Coker wrote:
> >
> > > On Saturday, 13 April 2019 5:39:31 AM AEST Sugar, David wrote:
> > >
> > >> 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.
> > >
> > >
> > > Could plymouth re-exec itself or do a dynamic domain transition to get
> > > the
> > > right domain?
> > >
> >
> >
> > I don't see a way in the plymouth.conf or other configuration file to
> > have plymouth re-exec.
>
> Probably need to hack the plymouth source.
Not sure if it is worth the trouble, plymouthd mainly runs in the initramfs.
There's a couple of left-overs when systemd loads policy but that is it AFAIK.
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
On Sat, Apr 13, 2019 at 02:24:25PM +1000, Russell Coker wrote:
> On Saturday, 13 April 2019 1:26:06 PM AEST Sugar, David wrote:
> > On 4/12/19 10:33 PM, Russell Coker wrote:
> > > What is netlink_kobject_uevent_socket? Do we have a place we can document
> > > this sort of thing to make it easier to determine whether access is
> > > required and what the implications of such access are?
> >
> > I'm really not sure either. But, please note, that this patch is
> > dontaudit rules to quiet some denials that didn't seem to have any
> > negative side effect. If this patch isn't applied things will still
> > function, just have some entries in the audit logs.
>
> There's a good chance the action in question isn't an accident and some aspect
> of the program's functionality will be changed. I think it's best to have an
> idea of what the issue was before putting in a dontaudit rule, if some
> configuration of that program actually needs such functionality then a
> dontaudit will make it inconvenient to track it down.
>
> Have you tried running strace or ltrace to see what it's doing?
I agree that this probably shouldnt be dontaudited. This is a common pattern for "udev clients"
The kobject_uevent socket aspect is probably to monitor devices (equivalent to `udevadm monitor`)
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
On 4/12/19 10:33 PM, Russell Coker wrote:
> What is netlink_kobject_uevent_socket? Do we have a place we can document
> this sort of thing to make it easier to determine whether access is required
> and what the implications of such access are?
The object class/perms list should be the place. Right now its at
https://selinuxproject.org/page/ObjectClassesPerms, though arguably it
could move back to the refpolicy wiki not that it's on SELinux project
GitHub.
--
Chris PeBenito