[PATCH 2/2] pam_faillock creates files in /run/faillock

[PATCH 2/2] pam_faillock creates files in /run/faillock

[David Sugar]

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 <dsugar@tresys.com>
---
 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

[PATCH 1/2] Allow greeter to start dbus and transition

[David Sugar]

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 <dsugar@tresys.com>
---
 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

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5226 bytes --]

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 <dsugar@tresys.com>
> ---
>  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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Sugar, David]

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 ---

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Chris PeBenito]

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

Re: [PATCH 1/2] Allow greeter to start dbus and transition

[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 <dsugar@tresys.com>
> ---
>   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

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3438 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] pam_faillock creates files in /run/faillock

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] Allow greeter to start dbus and transition

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3742 bytes --]

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 <dsugar@tresys.com>
> > ---
> >   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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] Allow greeter to start dbus and transition

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

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 <dsugar@tresys.com>
> > > ---
> > >   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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] Allow greeter to start dbus and transition

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5050 bytes --]

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 <dsugar@tresys.com>
> > > > ---
> > > >   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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] Allow greeter to start dbus and transition

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5537 bytes --]

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 <dsugar@tresys.com>
> > > > > ---
> > > > >   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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] Allow greeter to start dbus and transition

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6111 bytes --]

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 <dsugar@tresys.com>
> > > > > > ---
> > > > > >   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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]