The display manager lightdm (and I think gdm) start a dbus binary.
This allows that to happen in a special dbus domain.
type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
Signed-off-by: Dave Sugar <[email protected]>
---
policy/modules/services/xserver.te | 1 +
1 file changed, 1 insertion(+)
diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
index fa7ce88e..12ad3a87 100644
--- a/policy/modules/services/xserver.te
+++ b/policy/modules/services/xserver.te
@@ -568,6 +568,7 @@ optional_policy(`
optional_policy(`
dbus_system_bus_client(xdm_t)
dbus_connect_system_bus(xdm_t)
+ dbus_role_template(xdm, system_r, xdm_t)
optional_policy(`
accountsd_dbus_chat(xdm_t)
--
2.19.2
These are changes needed when pam_fallock created files in /run/faillock
(which is labeled faillog_t). sudo and xdm (and probably other domains)
will create files in this directory for successful and failed logins
attempts.
type=AVC msg=audit(1545153126.899:210): avc: denied { search } for pid=8448 comm="lightdm" name="faillock" dev="tmpfs" ino=39318 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1545153131.090:214): avc: denied { write } for pid=8448 comm="lightdm" name="faillock" dev="tmpfs" ino=39318 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1545153131.090:214): avc: denied { add_name } for pid=8448 comm="lightdm" name="dsugar" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1545153131.090:214): avc: denied { create } for pid=8448 comm="lightdm" name="dsugar" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=1
type=AVC msg=audit(1545153131.091:215): avc: denied { setattr } for pid=8448 comm="lightdm" name="dsugar" dev="tmpfs" ino=87599 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=1
type=AVC msg=audit(1545167205.531:626): avc: denied { search } for pid=8264 comm="sudo" name="faillock" dev="tmpfs" ino=35405 scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1545167205.531:627): avc: denied { write } for pid=8264 comm="sudo" name="faillock" dev="tmpfs" ino=35405 scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1545167205.531:627): avc: denied { add_name } for pid=8264 comm="sudo" name="root" scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1545167205.531:627): avc: denied { create } for pid=8264 comm="sudo" name="root" scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=sysadm_u:object_r:faillog_t:s0 tclass=file permissive=1
Signed-off-by: Dave Sugar <[email protected]>
---
policy/modules/admin/sudo.if | 1 +
policy/modules/services/xserver.te | 1 +
policy/modules/system/authlogin.if | 20 ++++++++++++++++++++
3 files changed, 22 insertions(+)
diff --git a/policy/modules/admin/sudo.if b/policy/modules/admin/sudo.if
index 7661a2f3..5fab0d04 100644
--- a/policy/modules/admin/sudo.if
+++ b/policy/modules/admin/sudo.if
@@ -113,6 +113,7 @@ template(`sudo_role_template',`
term_relabel_all_ttys($1_sudo_t)
term_relabel_all_ptys($1_sudo_t)
+ auth_create_faillog($1_sudo_t)
auth_run_chk_passwd($1_sudo_t, $2)
# sudo stores a token in the pam_pid directory
auth_manage_pam_pid($1_sudo_t)
diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
index 12ad3a87..fd89a95b 100644
--- a/policy/modules/services/xserver.te
+++ b/policy/modules/services/xserver.te
@@ -481,6 +481,7 @@ term_setattr_console(xdm_t)
term_use_unallocated_ttys(xdm_t)
term_setattr_unallocated_ttys(xdm_t)
+auth_create_faillog(xdm_t)
auth_domtrans_pam_console(xdm_t)
auth_manage_pam_pid(xdm_t)
auth_manage_pam_console_data(xdm_t)
diff --git a/policy/modules/system/authlogin.if b/policy/modules/system/authlogin.if
index 7f8c002e..5521aec3 100644
--- a/policy/modules/system/authlogin.if
+++ b/policy/modules/system/authlogin.if
@@ -744,6 +744,26 @@ interface(`auth_append_faillog',`
allow $1 faillog_t:file append_file_perms;
')
+########################################
+## <summary>
+## Create fail log lock (in /run/faillock).
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`auth_create_faillog',`
+ gen_require(`
+ type faillog_t;
+ ')
+
+ auth_rw_faillog($1)
+ create_files_pattern($1, faillog_t, faillog_t)
+ setattr_files_pattern($1, faillog_t, faillog_t)
+')
+
########################################
## <summary>
## Read and write the login failure log.
--
2.19.2
On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
> These are changes needed when pam_fallock created files in /run/faillock
> (which is labeled faillog_t). sudo and xdm (and probably other domains)
> will create files in this directory for successful and failed logins
> attempts.
The pam stuff has become a bit broken in my view.
We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
My opinion is that this belongs in auth_use_pam()
>
> type=AVC msg=audit(1545153126.899:210): avc: denied { search } for pid=8448 comm="lightdm" name="faillock" dev="tmpfs" ino=39318 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1545153131.090:214): avc: denied { write } for pid=8448 comm="lightdm" name="faillock" dev="tmpfs" ino=39318 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1545153131.090:214): avc: denied { add_name } for pid=8448 comm="lightdm" name="dsugar" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1545153131.090:214): avc: denied { create } for pid=8448 comm="lightdm" name="dsugar" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1545153131.091:215): avc: denied { setattr } for pid=8448 comm="lightdm" name="dsugar" dev="tmpfs" ino=87599 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=1
>
> type=AVC msg=audit(1545167205.531:626): avc: denied { search } for pid=8264 comm="sudo" name="faillock" dev="tmpfs" ino=35405 scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1545167205.531:627): avc: denied { write } for pid=8264 comm="sudo" name="faillock" dev="tmpfs" ino=35405 scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1545167205.531:627): avc: denied { add_name } for pid=8264 comm="sudo" name="root" scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1545167205.531:627): avc: denied { create } for pid=8264 comm="sudo" name="root" scontext=sysadm_u:sysadm_r:cleaner_applyconfig_sudo_t:s0-s0:c0.c1023 tcontext=sysadm_u:object_r:faillog_t:s0 tclass=file permissive=1
>
> Signed-off-by: Dave Sugar <[email protected]>
> ---
> policy/modules/admin/sudo.if | 1 +
> policy/modules/services/xserver.te | 1 +
> policy/modules/system/authlogin.if | 20 ++++++++++++++++++++
> 3 files changed, 22 insertions(+)
>
> diff --git a/policy/modules/admin/sudo.if b/policy/modules/admin/sudo.if
> index 7661a2f3..5fab0d04 100644
> --- a/policy/modules/admin/sudo.if
> +++ b/policy/modules/admin/sudo.if
> @@ -113,6 +113,7 @@ template(`sudo_role_template',`
> term_relabel_all_ttys($1_sudo_t)
> term_relabel_all_ptys($1_sudo_t)
>
> + auth_create_faillog($1_sudo_t)
> auth_run_chk_passwd($1_sudo_t, $2)
> # sudo stores a token in the pam_pid directory
> auth_manage_pam_pid($1_sudo_t)
> diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> index 12ad3a87..fd89a95b 100644
> --- a/policy/modules/services/xserver.te
> +++ b/policy/modules/services/xserver.te
> @@ -481,6 +481,7 @@ term_setattr_console(xdm_t)
> term_use_unallocated_ttys(xdm_t)
> term_setattr_unallocated_ttys(xdm_t)
>
> +auth_create_faillog(xdm_t)
> auth_domtrans_pam_console(xdm_t)
> auth_manage_pam_pid(xdm_t)
> auth_manage_pam_console_data(xdm_t)
> diff --git a/policy/modules/system/authlogin.if b/policy/modules/system/authlogin.if
> index 7f8c002e..5521aec3 100644
> --- a/policy/modules/system/authlogin.if
> +++ b/policy/modules/system/authlogin.if
> @@ -744,6 +744,26 @@ interface(`auth_append_faillog',`
> allow $1 faillog_t:file append_file_perms;
> ')
>
> +########################################
> +## <summary>
> +## Create fail log lock (in /run/faillock).
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +#
> +interface(`auth_create_faillog',`
> + gen_require(`
> + type faillog_t;
> + ')
> +
> + auth_rw_faillog($1)
> + create_files_pattern($1, faillog_t, faillog_t)
> + setattr_files_pattern($1, faillog_t, faillog_t)
> +')
> +
> ########################################
> ## <summary>
> ## Read and write the login failure log.
> --
> 2.19.2
>
--
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 12/21/18 5:34 AM, Dominick Grift wrote:
> On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
>> These are changes needed when pam_fallock created files in /run/faillock
>> (which is labeled faillog_t). sudo and xdm (and probably other domains)
>> will create files in this directory for successful and failed logins
>> attempts.
> The pam stuff has become a bit broken in my view.
>
> We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
>
> So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
>
> My opinion is that this belongs in auth_use_pam()
Dominick,
I see those interfaces.? It looks like xdm_t already uses
auth_login_pgm_domain(xdm_t).? It also isn't really clear to me what the
difference is between auth_login_pgm_domain() and auth_use_pam().? I
will make updates moving my change into auth_use_pam() and also update
sudo_role_template() to use (I think) auth_login_pgm_domain ().
I will resubmit this patch,
--- snip ---
On 12/21/18 9:58 PM, Sugar, David wrote:
>
> On 12/21/18 5:34 AM, Dominick Grift wrote:
>> On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
>>> These are changes needed when pam_fallock created files in /run/faillock
>>> (which is labeled faillog_t). sudo and xdm (and probably other domains)
>>> will create files in this directory for successful and failed logins
>>> attempts.
>> The pam stuff has become a bit broken in my view.
>>
>> We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
>>
>> So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
>>
>> My opinion is that this belongs in auth_use_pam()
>
> Dominick,
>
> I see those interfaces.? It looks like xdm_t already uses
> auth_login_pgm_domain(xdm_t).? It also isn't really clear to me what the
> difference is between auth_login_pgm_domain() and auth_use_pam().
It's a little muddy, but a "login" domain is as it seems; authentication
for login programs. The "use" one is other uses of PAM.
--
Chris PeBenito
On 12/20/18 8:41 PM, David Sugar wrote:
> The display manager lightdm (and I think gdm) start a dbus binary.
> This allows that to happen in a special dbus domain.
>
> type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
>
> Signed-off-by: Dave Sugar <[email protected]>
> ---
> policy/modules/services/xserver.te | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> index fa7ce88e..12ad3a87 100644
> --- a/policy/modules/services/xserver.te
> +++ b/policy/modules/services/xserver.te
> @@ -568,6 +568,7 @@ optional_policy(`
> optional_policy(`
> dbus_system_bus_client(xdm_t)
> dbus_connect_system_bus(xdm_t)
> + dbus_role_template(xdm, system_r, xdm_t)
>
> optional_policy(`
> accountsd_dbus_chat(xdm_t)
This doesn't sit well with me. XDM isn't a user, or is system_r a user
role, so it shouldn't be using this template. On my system,
at-spi-bus-launcher is running as part of my user session, not as part
of XDM. It seems like this may be a transition problem.
--
Chris PeBenito
On Sat, Dec 22, 2018 at 02:58:41AM +0000, Sugar, David wrote:
>
> On 12/21/18 5:34 AM, Dominick Grift wrote:
> > On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
> >> These are changes needed when pam_fallock created files in /run/faillock
> >> (which is labeled faillog_t). sudo and xdm (and probably other domains)
> >> will create files in this directory for successful and failed logins
> >> attempts.
> > The pam stuff has become a bit broken in my view.
> >
> > We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
> >
> > So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
> >
> > My opinion is that this belongs in auth_use_pam()
>
> Dominick,
>
> I see those interfaces.? It looks like xdm_t already uses
> auth_login_pgm_domain(xdm_t).? It also isn't really clear to me what the
> difference is between auth_login_pgm_domain() and auth_use_pam().? I
> will make updates moving my change into auth_use_pam() and also update
> sudo_role_template() to use (I think) auth_login_pgm_domain ().
sudo is not an auth_login_pgm_domain() i believe
the auth_use_pam() is a subset of auth_login_pgm_domain()
so login_pgm domains are pam clients plus extras needed to log in users
a auth_use_pam() (pam client) has a pam stack but it might not actually do logins
sudo uses pam but its not a real login program, so afaik sudo should call auth_use_pam()
xdm is a login_pgm, so is sshd etc
systemd is also a pam client, but not a login program
>
> I will resubmit this patch,
>
> --- snip ---
--
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 Sun, Dec 23, 2018 at 11:20:00AM +0100, Dominick Grift wrote:
> On Sat, Dec 22, 2018 at 02:58:41AM +0000, Sugar, David wrote:
> >
> > On 12/21/18 5:34 AM, Dominick Grift wrote:
> > > On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
> > >> These are changes needed when pam_fallock created files in /run/faillock
> > >> (which is labeled faillog_t). sudo and xdm (and probably other domains)
> > >> will create files in this directory for successful and failed logins
> > >> attempts.
> > > The pam stuff has become a bit broken in my view.
> > >
> > > We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
> > >
> > > So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
> > >
> > > My opinion is that this belongs in auth_use_pam()
> >
> > Dominick,
> >
> > I see those interfaces.? It looks like xdm_t already uses
> > auth_login_pgm_domain(xdm_t).? It also isn't really clear to me what the
> > difference is between auth_login_pgm_domain() and auth_use_pam().? I
> > will make updates moving my change into auth_use_pam() and also update
> > sudo_role_template() to use (I think) auth_login_pgm_domain ().
>
> sudo is not an auth_login_pgm_domain() i believe
>
> the auth_use_pam() is a subset of auth_login_pgm_domain()
>
> so login_pgm domains are pam clients plus extras needed to log in users
>
> a auth_use_pam() (pam client) has a pam stack but it might not actually do logins
>
> sudo uses pam but its not a real login program, so afaik sudo should call auth_use_pam()
> xdm is a login_pgm, so is sshd etc
>
> systemd is also a pam client, but not a login program
And yes systemd needs to be able to create these /run/faillock/USER files as well, but if you test this on RHEL then you wont see it because
RHEL doesnt use /etc/pam.d/systemd-user (i suppose)
so:
1. auth_use_pam() == "pam clients" (programs that have a file in /etc/pam.d), they use pam for authentication of some sort
2, auth_login_pgm_domain() == superset (special pam clients that need permissions to do actual logins)
>
> >
> > I will resubmit this patch,
> >
> > --- snip ---
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
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 Sun, Dec 23, 2018 at 11:46:48AM +0100, Dominick Grift wrote:
> On Sun, Dec 23, 2018 at 11:20:00AM +0100, Dominick Grift wrote:
> > On Sat, Dec 22, 2018 at 02:58:41AM +0000, Sugar, David wrote:
> > >
> > > On 12/21/18 5:34 AM, Dominick Grift wrote:
> > > > On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
> > > >> These are changes needed when pam_fallock created files in /run/faillock
> > > >> (which is labeled faillog_t). sudo and xdm (and probably other domains)
> > > >> will create files in this directory for successful and failed logins
> > > >> attempts.
> > > > The pam stuff has become a bit broken in my view.
> > > >
> > > > We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
> > > >
> > > > So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
> > > >
> > > > My opinion is that this belongs in auth_use_pam()
> > >
> > > Dominick,
> > >
> > > I see those interfaces.? It looks like xdm_t already uses
> > > auth_login_pgm_domain(xdm_t).? It also isn't really clear to me what the
> > > difference is between auth_login_pgm_domain() and auth_use_pam().? I
> > > will make updates moving my change into auth_use_pam() and also update
> > > sudo_role_template() to use (I think) auth_login_pgm_domain ().
> >
> > sudo is not an auth_login_pgm_domain() i believe
> >
> > the auth_use_pam() is a subset of auth_login_pgm_domain()
> >
> > so login_pgm domains are pam clients plus extras needed to log in users
> >
> > a auth_use_pam() (pam client) has a pam stack but it might not actually do logins
> >
> > sudo uses pam but its not a real login program, so afaik sudo should call auth_use_pam()
> > xdm is a login_pgm, so is sshd etc
> >
> > systemd is also a pam client, but not a login program
>
> And yes systemd needs to be able to create these /run/faillock/USER files as well, but if you test this on RHEL then you wont see it because
> RHEL doesnt use /etc/pam.d/systemd-user (i suppose)
>
> so:
>
> 1. auth_use_pam() == "pam clients" (programs that have a file in /etc/pam.d), they use pam for authentication of some sort
> 2, auth_login_pgm_domain() == superset (special pam clients that need permissions to do actual logins)
Another interesting detail is that pam_faillock clients need cap_dac_override to be able to write records to /run/faillock/USER files
I wonder whether that is a bug
for example sshd (root) creates /run/faillock/joe with joe.root and 0600 but then sshd (root) needs cap_dac_override to write records to that file
Probably should have created the files with 0660 ... to avoid the need for cap_dac_override...
>
> >
> > >
> > > I will resubmit this patch,
> > >
> > > --- snip ---
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
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 Sun, Dec 23, 2018 at 05:09:21PM +0100, Dominick Grift wrote:
> On Sun, Dec 23, 2018 at 11:46:48AM +0100, Dominick Grift wrote:
> > On Sun, Dec 23, 2018 at 11:20:00AM +0100, Dominick Grift wrote:
> > > On Sat, Dec 22, 2018 at 02:58:41AM +0000, Sugar, David wrote:
> > > >
> > > > On 12/21/18 5:34 AM, Dominick Grift wrote:
> > > > > On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
> > > > >> These are changes needed when pam_fallock created files in /run/faillock
> > > > >> (which is labeled faillog_t). sudo and xdm (and probably other domains)
> > > > >> will create files in this directory for successful and failed logins
> > > > >> attempts.
> > > > > The pam stuff has become a bit broken in my view.
> > > > >
> > > > > We use to use auth_use_pam() for these kinds of things but the interface was forgotten and not updated properly.
> > > > >
> > > > > So for example sudo does not even call auth_use_pam() and a lot of stuff was added directly to the login_pgm domain that should have been added to auth_use_pam() instead.
> > > > >
> > > > > My opinion is that this belongs in auth_use_pam()
> > > >
> > > > Dominick,
> > > >
> > > > I see those interfaces.? It looks like xdm_t already uses
> > > > auth_login_pgm_domain(xdm_t).? It also isn't really clear to me what the
> > > > difference is between auth_login_pgm_domain() and auth_use_pam().? I
> > > > will make updates moving my change into auth_use_pam() and also update
> > > > sudo_role_template() to use (I think) auth_login_pgm_domain ().
> > >
> > > sudo is not an auth_login_pgm_domain() i believe
> > >
> > > the auth_use_pam() is a subset of auth_login_pgm_domain()
> > >
> > > so login_pgm domains are pam clients plus extras needed to log in users
> > >
> > > a auth_use_pam() (pam client) has a pam stack but it might not actually do logins
> > >
> > > sudo uses pam but its not a real login program, so afaik sudo should call auth_use_pam()
> > > xdm is a login_pgm, so is sshd etc
> > >
> > > systemd is also a pam client, but not a login program
> >
> > And yes systemd needs to be able to create these /run/faillock/USER files as well, but if you test this on RHEL then you wont see it because
> > RHEL doesnt use /etc/pam.d/systemd-user (i suppose)
> >
> > so:
> >
> > 1. auth_use_pam() == "pam clients" (programs that have a file in /etc/pam.d), they use pam for authentication of some sort
> > 2, auth_login_pgm_domain() == superset (special pam clients that need permissions to do actual logins)
>
> Another interesting detail is that pam_faillock clients need cap_dac_override to be able to write records to /run/faillock/USER files
> I wonder whether that is a bug
>
> for example sshd (root) creates /run/faillock/joe with joe.root and 0600 but then sshd (root) needs cap_dac_override to write records to that file
> Probably should have created the files with 0660 ... to avoid the need for cap_dac_override...
I filed a bugzilla for this, just to be sure: https://bugzilla.redhat.com/show_bug.cgi?id=1661822
>
> >
> > >
> > > >
> > > > I will resubmit this patch,
> > > >
> > > > --- snip ---
> > >
> > > --
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > Dominick Grift
> >
> >
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
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, Dec 22, 2018 at 02:28:15PM -0500, Chris PeBenito wrote:
> On 12/20/18 8:41 PM, David Sugar wrote:
> > The display manager lightdm (and I think gdm) start a dbus binary.
> > This allows that to happen in a special dbus domain.
> >
> > type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> >
> > Signed-off-by: Dave Sugar <[email protected]>
> > ---
> > policy/modules/services/xserver.te | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> > index fa7ce88e..12ad3a87 100644
> > --- a/policy/modules/services/xserver.te
> > +++ b/policy/modules/services/xserver.te
> > @@ -568,6 +568,7 @@ optional_policy(`
> > optional_policy(`
> > dbus_system_bus_client(xdm_t)
> > dbus_connect_system_bus(xdm_t)
> > + dbus_role_template(xdm, system_r, xdm_t)
> > optional_policy(`
> > accountsd_dbus_chat(xdm_t)
>
> This doesn't sit well with me. XDM isn't a user, or is system_r a user
> role, so it shouldn't be using this template. On my system,
> at-spi-bus-launcher is running as part of my user session, not as part of
> XDM. It seems like this may be a transition problem.
It does not sit well with me either but gdm is actually a "user" in way's. and it has a session.
the gdm DM policy should never have been merged with XDM DM policy as XDM is much cleaner.
GDM is nasty
>
> --
> Chris PeBenito
--
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 Sun, Dec 23, 2018 at 05:33:59PM +0100, Dominick Grift wrote:
> On Sat, Dec 22, 2018 at 02:28:15PM -0500, Chris PeBenito wrote:
> > On 12/20/18 8:41 PM, David Sugar wrote:
> > > The display manager lightdm (and I think gdm) start a dbus binary.
> > > This allows that to happen in a special dbus domain.
> > >
> > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > >
> > > Signed-off-by: Dave Sugar <[email protected]>
> > > ---
> > > policy/modules/services/xserver.te | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> > > index fa7ce88e..12ad3a87 100644
> > > --- a/policy/modules/services/xserver.te
> > > +++ b/policy/modules/services/xserver.te
> > > @@ -568,6 +568,7 @@ optional_policy(`
> > > optional_policy(`
> > > dbus_system_bus_client(xdm_t)
> > > dbus_connect_system_bus(xdm_t)
> > > + dbus_role_template(xdm, system_r, xdm_t)
> > > optional_policy(`
> > > accountsd_dbus_chat(xdm_t)
> >
> > This doesn't sit well with me. XDM isn't a user, or is system_r a user
> > role, so it shouldn't be using this template. On my system,
> > at-spi-bus-launcher is running as part of my user session, not as part of
> > XDM. It seems like this may be a transition problem.
>
> It does not sit well with me either but gdm is actually a "user" in way's. and it has a session.
>
> the gdm DM policy should never have been merged with XDM DM policy as XDM is much cleaner.
>
> GDM is nasty
In dssp2 i actually have a seuser for gdm:
# seinfo -xugdm.id
Users: 1
user gdm.id roles sys.role level s0 range s0;
And believe me, I did not do that for fun. In distributions with systemd --user this is just needed because
systemd will spawn a --user instance for gdm and this user instance spawns all kinds of processes on gdm's behalf
for example dbus instance, the last thing you want is to have a gdm dbus instance running with system_dbusd_t
>
> >
> > --
> > Chris PeBenito
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
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 Sun, Dec 23, 2018 at 05:45:12PM +0100, Dominick Grift wrote:
> On Sun, Dec 23, 2018 at 05:33:59PM +0100, Dominick Grift wrote:
> > On Sat, Dec 22, 2018 at 02:28:15PM -0500, Chris PeBenito wrote:
> > > On 12/20/18 8:41 PM, David Sugar wrote:
> > > > The display manager lightdm (and I think gdm) start a dbus binary.
> > > > This allows that to happen in a special dbus domain.
> > > >
> > > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > >
> > > > Signed-off-by: Dave Sugar <[email protected]>
> > > > ---
> > > > policy/modules/services/xserver.te | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> > > > index fa7ce88e..12ad3a87 100644
> > > > --- a/policy/modules/services/xserver.te
> > > > +++ b/policy/modules/services/xserver.te
> > > > @@ -568,6 +568,7 @@ optional_policy(`
> > > > optional_policy(`
> > > > dbus_system_bus_client(xdm_t)
> > > > dbus_connect_system_bus(xdm_t)
> > > > + dbus_role_template(xdm, system_r, xdm_t)
> > > > optional_policy(`
> > > > accountsd_dbus_chat(xdm_t)
> > >
> > > This doesn't sit well with me. XDM isn't a user, or is system_r a user
> > > role, so it shouldn't be using this template. On my system,
> > > at-spi-bus-launcher is running as part of my user session, not as part of
> > > XDM. It seems like this may be a transition problem.
> >
> > It does not sit well with me either but gdm is actually a "user" in way's. and it has a session.
> >
> > the gdm DM policy should never have been merged with XDM DM policy as XDM is much cleaner.
> >
> > GDM is nasty
>
> In dssp2 i actually have a seuser for gdm:
>
> # seinfo -xugdm.id
>
> Users: 1
> user gdm.id roles sys.role level s0 range s0;
>
> And believe me, I did not do that for fun. In distributions with systemd --user this is just needed because
> systemd will spawn a --user instance for gdm and this user instance spawns all kinds of processes on gdm's behalf
>
> for example dbus instance, the last thing you want is to have a gdm dbus instance running with system_dbusd_t
then again, in dssp2 i just run pretty much everything in "gdm_t"
so maybe a dbus_exec() is more appropriate (and simpler)
>
> >
> > >
> > > --
> > > Chris PeBenito
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
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 Sun, Dec 23, 2018 at 05:52:06PM +0100, Dominick Grift wrote:
> On Sun, Dec 23, 2018 at 05:45:12PM +0100, Dominick Grift wrote:
> > On Sun, Dec 23, 2018 at 05:33:59PM +0100, Dominick Grift wrote:
> > > On Sat, Dec 22, 2018 at 02:28:15PM -0500, Chris PeBenito wrote:
> > > > On 12/20/18 8:41 PM, David Sugar wrote:
> > > > > The display manager lightdm (and I think gdm) start a dbus binary.
> > > > > This allows that to happen in a special dbus domain.
> > > > >
> > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > >
> > > > > Signed-off-by: Dave Sugar <[email protected]>
> > > > > ---
> > > > > policy/modules/services/xserver.te | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> > > > > index fa7ce88e..12ad3a87 100644
> > > > > --- a/policy/modules/services/xserver.te
> > > > > +++ b/policy/modules/services/xserver.te
> > > > > @@ -568,6 +568,7 @@ optional_policy(`
> > > > > optional_policy(`
> > > > > dbus_system_bus_client(xdm_t)
> > > > > dbus_connect_system_bus(xdm_t)
> > > > > + dbus_role_template(xdm, system_r, xdm_t)
> > > > > optional_policy(`
> > > > > accountsd_dbus_chat(xdm_t)
> > > >
> > > > This doesn't sit well with me. XDM isn't a user, or is system_r a user
> > > > role, so it shouldn't be using this template. On my system,
> > > > at-spi-bus-launcher is running as part of my user session, not as part of
> > > > XDM. It seems like this may be a transition problem.
> > >
> > > It does not sit well with me either but gdm is actually a "user" in way's. and it has a session.
> > >
> > > the gdm DM policy should never have been merged with XDM DM policy as XDM is much cleaner.
> > >
> > > GDM is nasty
> >
> > In dssp2 i actually have a seuser for gdm:
> >
> > # seinfo -xugdm.id
> >
> > Users: 1
> > user gdm.id roles sys.role level s0 range s0;
> >
> > And believe me, I did not do that for fun. In distributions with systemd --user this is just needed because
> > systemd will spawn a --user instance for gdm and this user instance spawns all kinds of processes on gdm's behalf
> >
> > for example dbus instance, the last thing you want is to have a gdm dbus instance running with system_dbusd_t
>
> then again, in dssp2 i just run pretty much everything in "gdm_t"
> so maybe a dbus_exec() is more appropriate (and simpler)
https://github.com/DefenSec/dssp2-standard/blob/master/policy/gnome/g/gdm.cil#L218
>
> >
> > >
> > > >
> > > > --
> > > > Chris PeBenito
> > >
> > > --
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > Dominick Grift
> >
> >
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
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 Sun, Dec 23, 2018 at 05:55:10PM +0100, Dominick Grift wrote:
> On Sun, Dec 23, 2018 at 05:52:06PM +0100, Dominick Grift wrote:
> > On Sun, Dec 23, 2018 at 05:45:12PM +0100, Dominick Grift wrote:
> > > On Sun, Dec 23, 2018 at 05:33:59PM +0100, Dominick Grift wrote:
> > > > On Sat, Dec 22, 2018 at 02:28:15PM -0500, Chris PeBenito wrote:
> > > > > On 12/20/18 8:41 PM, David Sugar wrote:
> > > > > > The display manager lightdm (and I think gdm) start a dbus binary.
> > > > > > This allows that to happen in a special dbus domain.
> > > > > >
> > > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute } for pid=16376 comm="at-spi-bus-laun" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { read open } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { execute_no_trans } for pid=16376 comm="at-spi-bus-laun" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > > type=AVC msg=audit(1544628523.635:3208): avc: denied { map } for pid=16376 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
> > > > > >
> > > > > > Signed-off-by: Dave Sugar <[email protected]>
> > > > > > ---
> > > > > > policy/modules/services/xserver.te | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> > > > > > index fa7ce88e..12ad3a87 100644
> > > > > > --- a/policy/modules/services/xserver.te
> > > > > > +++ b/policy/modules/services/xserver.te
> > > > > > @@ -568,6 +568,7 @@ optional_policy(`
> > > > > > optional_policy(`
> > > > > > dbus_system_bus_client(xdm_t)
> > > > > > dbus_connect_system_bus(xdm_t)
> > > > > > + dbus_role_template(xdm, system_r, xdm_t)
> > > > > > optional_policy(`
> > > > > > accountsd_dbus_chat(xdm_t)
> > > > >
> > > > > This doesn't sit well with me. XDM isn't a user, or is system_r a user
> > > > > role, so it shouldn't be using this template. On my system,
> > > > > at-spi-bus-launcher is running as part of my user session, not as part of
> > > > > XDM. It seems like this may be a transition problem.
> > > >
> > > > It does not sit well with me either but gdm is actually a "user" in way's. and it has a session.
> > > >
> > > > the gdm DM policy should never have been merged with XDM DM policy as XDM is much cleaner.
> > > >
> > > > GDM is nasty
> > >
> > > In dssp2 i actually have a seuser for gdm:
> > >
> > > # seinfo -xugdm.id
> > >
> > > Users: 1
> > > user gdm.id roles sys.role level s0 range s0;
> > >
> > > And believe me, I did not do that for fun. In distributions with systemd --user this is just needed because
> > > systemd will spawn a --user instance for gdm and this user instance spawns all kinds of processes on gdm's behalf
> > >
> > > for example dbus instance, the last thing you want is to have a gdm dbus instance running with system_dbusd_t
> >
> > then again, in dssp2 i just run pretty much everything in "gdm_t"
> > so maybe a dbus_exec() is more appropriate (and simpler)
>
> https://github.com/DefenSec/dssp2-standard/blob/master/policy/gnome/g/gdm.cil#L218
My last comment on this: my advice is to stay in the xdm_t domain and to not transition out of it. just run that whole session in xdm_t, all of it.
>
> >
> > >
> > > >
> > > > >
> > > > > --
> > > > > Chris PeBenito
> > > >
> > > > --
> > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > > Dominick Grift
> > >
> > >
> > >
> > > --
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > Dominick Grift
> >
> >
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift