* [PATCH 1/2] Allow greeter to start dbus and transition
@ 2018-12-21 1:41 David Sugar
2018-12-21 1:41 ` [PATCH 2/2] pam_faillock creates files in /run/faillock David Sugar
2018-12-22 19:28 ` [PATCH 1/2] Allow greeter to start dbus and transition Chris PeBenito
0 siblings, 2 replies; 15+ messages in thread
From: David Sugar @ 2018-12-21 1:41 UTC (permalink / raw)
To: selinux-refpolicy
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-21 1:41 [PATCH 1/2] Allow greeter to start dbus and transition David Sugar @ 2018-12-21 1:41 ` David Sugar 2018-12-21 10:34 ` Dominick Grift 2018-12-22 19:28 ` [PATCH 1/2] Allow greeter to start dbus and transition Chris PeBenito 1 sibling, 1 reply; 15+ messages in thread From: David Sugar @ 2018-12-21 1:41 UTC (permalink / raw) To: selinux-refpolicy 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 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-21 1:41 ` [PATCH 2/2] pam_faillock creates files in /run/faillock David Sugar @ 2018-12-21 10:34 ` Dominick Grift 2018-12-22 2:58 ` Sugar, David 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-21 10:34 UTC (permalink / raw) To: David Sugar; +Cc: selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-21 10:34 ` Dominick Grift @ 2018-12-22 2:58 ` Sugar, David 2018-12-22 19:20 ` Chris PeBenito 2018-12-23 10:20 ` Dominick Grift 0 siblings, 2 replies; 15+ messages in thread From: Sugar, David @ 2018-12-22 2:58 UTC (permalink / raw) To: selinux-refpolicy 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 --- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-22 2:58 ` Sugar, David @ 2018-12-22 19:20 ` Chris PeBenito 2018-12-23 10:20 ` Dominick Grift 1 sibling, 0 replies; 15+ messages in thread From: Chris PeBenito @ 2018-12-22 19:20 UTC (permalink / raw) To: Sugar, David, selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-22 2:58 ` Sugar, David 2018-12-22 19:20 ` Chris PeBenito @ 2018-12-23 10:20 ` Dominick Grift 2018-12-23 10:46 ` Dominick Grift 1 sibling, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 10:20 UTC (permalink / raw) To: Sugar, David; +Cc: selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-23 10:20 ` Dominick Grift @ 2018-12-23 10:46 ` Dominick Grift 2018-12-23 16:09 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 10:46 UTC (permalink / raw) To: Sugar, David, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-23 10:46 ` Dominick Grift @ 2018-12-23 16:09 ` Dominick Grift 2018-12-23 16:16 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 16:09 UTC (permalink / raw) To: Sugar, David, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] pam_faillock creates files in /run/faillock 2018-12-23 16:09 ` Dominick Grift @ 2018-12-23 16:16 ` Dominick Grift 0 siblings, 0 replies; 15+ messages in thread From: Dominick Grift @ 2018-12-23 16:16 UTC (permalink / raw) To: Sugar, David, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] Allow greeter to start dbus and transition 2018-12-21 1:41 [PATCH 1/2] Allow greeter to start dbus and transition David Sugar 2018-12-21 1:41 ` [PATCH 2/2] pam_faillock creates files in /run/faillock David Sugar @ 2018-12-22 19:28 ` Chris PeBenito 2018-12-23 16:33 ` Dominick Grift 1 sibling, 1 reply; 15+ messages in thread From: Chris PeBenito @ 2018-12-22 19:28 UTC (permalink / raw) To: David Sugar, selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] Allow greeter to start dbus and transition 2018-12-22 19:28 ` [PATCH 1/2] Allow greeter to start dbus and transition Chris PeBenito @ 2018-12-23 16:33 ` Dominick Grift 2018-12-23 16:45 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 16:33 UTC (permalink / raw) To: Chris PeBenito; +Cc: David Sugar, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] Allow greeter to start dbus and transition 2018-12-23 16:33 ` Dominick Grift @ 2018-12-23 16:45 ` Dominick Grift 2018-12-23 16:52 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 16:45 UTC (permalink / raw) To: Chris PeBenito, David Sugar, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] Allow greeter to start dbus and transition 2018-12-23 16:45 ` Dominick Grift @ 2018-12-23 16:52 ` Dominick Grift 2018-12-23 16:55 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 16:52 UTC (permalink / raw) To: Chris PeBenito, David Sugar, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] Allow greeter to start dbus and transition 2018-12-23 16:52 ` Dominick Grift @ 2018-12-23 16:55 ` Dominick Grift 2018-12-23 17:02 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2018-12-23 16:55 UTC (permalink / raw) To: Chris PeBenito, David Sugar, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] Allow greeter to start dbus and transition 2018-12-23 16:55 ` Dominick Grift @ 2018-12-23 17:02 ` Dominick Grift 0 siblings, 0 replies; 15+ messages in thread From: Dominick Grift @ 2018-12-23 17:02 UTC (permalink / raw) To: Chris PeBenito, David Sugar, selinux-refpolicy [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-12-23 17:02 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-21 1:41 [PATCH 1/2] Allow greeter to start dbus and transition David Sugar 2018-12-21 1:41 ` [PATCH 2/2] pam_faillock creates files in /run/faillock David Sugar 2018-12-21 10:34 ` Dominick Grift 2018-12-22 2:58 ` Sugar, David 2018-12-22 19:20 ` Chris PeBenito 2018-12-23 10:20 ` Dominick Grift 2018-12-23 10:46 ` Dominick Grift 2018-12-23 16:09 ` Dominick Grift 2018-12-23 16:16 ` Dominick Grift 2018-12-22 19:28 ` [PATCH 1/2] Allow greeter to start dbus and transition Chris PeBenito 2018-12-23 16:33 ` Dominick Grift 2018-12-23 16:45 ` Dominick Grift 2018-12-23 16:52 ` Dominick Grift 2018-12-23 16:55 ` Dominick Grift 2018-12-23 17:02 ` Dominick Grift
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).