I put a ifdef wrapper around the GDM access that was contentious. Please
consider this for inclusion now.
Index: refpolicy-2.20170421/policy/modules/system/locallogin.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/system/locallogin.te
+++ refpolicy-2.20170421/policy/modules/system/locallogin.te
@@ -33,6 +33,7 @@ role system_r types sulogin_t;
#
allow local_login_t self:capability { chown dac_override fowner fsetid kill setgid setuid sys_nice sys_resource sys_tty_config };
+dontaudit local_login_t self:capability net_admin;
allow local_login_t self:process { setexec setrlimit setsched };
allow local_login_t self:fd use;
allow local_login_t self:fifo_file rw_fifo_file_perms;
@@ -237,6 +238,9 @@ fs_rw_tmpfs_chr_files(sulogin_t)
files_read_etc_files(sulogin_t)
auth_read_shadow(sulogin_t)
+auth_login_pgm_domain(sulogin_t)
+kernel_read_crypto_sysctls(sulogin_t)
+selinux_set_generic_booleans(sulogin_t)
init_getpgid_script(sulogin_t)
Index: refpolicy-2.20170421/policy/modules/contrib/policykit.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/contrib/policykit.te
+++ refpolicy-2.20170421/policy/modules/contrib/policykit.te
@@ -87,6 +87,9 @@ domtrans_pattern(policykit_t, policykit_
kernel_read_kernel_sysctls(policykit_t)
kernel_read_system_state(policykit_t)
+fs_getattr_tmpfs(policykit_t)
+fs_getattr_cgroup(policykit_t)
+dev_read_urand(policykit_t)
dev_read_urand(policykit_t)
@@ -101,6 +104,7 @@ auth_use_nsswitch(policykit_t)
userdom_getattr_all_users(policykit_t)
userdom_read_all_users_state(policykit_t)
+userdom_dbus_send_all_users(policykit_t)
optional_policy(`
dbus_system_domain(policykit_t, policykit_exec_t)
Index: refpolicy-2.20170421/policy/modules/contrib/dbus.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/contrib/dbus.te
+++ refpolicy-2.20170421/policy/modules/contrib/dbus.te
@@ -96,6 +96,12 @@ corecmd_exec_shell(system_dbusd_t)
dev_read_urand(system_dbusd_t)
dev_read_sysfs(system_dbusd_t)
+ifdef(`init_systemd', `
+ # gdm3 causes system_dbusd_t to want this access
+ dev_rw_dri(system_dbusd_t)
+ dev_rw_input_dev(system_dbusd_t)
+')
+
domain_use_interactive_fds(system_dbusd_t)
domain_read_all_domains_state(system_dbusd_t)
Index: refpolicy-2.20170421/policy/modules/system/authlogin.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/system/authlogin.te
+++ refpolicy-2.20170421/policy/modules/system/authlogin.te
@@ -105,6 +105,8 @@ files_list_etc(chkpwd_t)
kernel_read_crypto_sysctls(chkpwd_t)
# is_selinux_enabled
kernel_read_system_state(chkpwd_t)
+selinux_get_enforce_mode(chkpwd_t)
+selinux_getattr_fs(chkpwd_t)
domain_dontaudit_use_interactive_fds(chkpwd_t)
Index: refpolicy-2.20170421/policy/modules/contrib/gpg.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/contrib/gpg.te
+++ refpolicy-2.20170421/policy/modules/contrib/gpg.te
@@ -87,6 +87,7 @@ gpg_stream_connect_agent(gpg_t)
domtrans_pattern(gpg_t, gpg_agent_exec_t, gpg_agent_t)
domtrans_pattern(gpg_t, gpg_helper_exec_t, gpg_helper_t)
+kernel_read_crypto_sysctls(gpg_t)
kernel_read_sysctl(gpg_t)
# read /proc/cpuinfo
kernel_read_system_state(gpg_t)
@@ -214,6 +215,11 @@ manage_sock_files_pattern(gpg_agent_t, g
manage_files_pattern(gpg_agent_t, gpg_secret_t, gpg_secret_t)
manage_lnk_files_pattern(gpg_agent_t, gpg_secret_t, gpg_secret_t)
+xserver_sigchld_xdm(gpg_agent_t)
+dbus_system_bus_client(gpg_agent_t)
+auth_use_nsswitch(gpg_agent_t)
+xserver_read_user_xauth(gpg_agent_t)
+
manage_dirs_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
manage_files_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
manage_sock_files_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
On 21 Apr 2017 11:10 am, "Russell Coker via refpolicy" <
[email protected]> wrote:
I put a ifdef wrapper around the GDM access that was contentious. Please
consider this for inclusion now.
Index: refpolicy-2.20170421/policy/modules/system/locallogin.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/system/locallogin.te
+++ refpolicy-2.20170421/policy/modules/system/locallogin.te
@@ -33,6 +33,7 @@ role system_r types sulogin_t;
#
allow local_login_t self:capability { chown dac_override fowner fsetid
kill setgid setuid sys_nice sys_resource sys_tty_config };
+dontaudit local_login_t self:capability net_admin;
allow local_login_t self:process { setexec setrlimit setsched };
allow local_login_t self:fd use;
allow local_login_t self:fifo_file rw_fifo_file_perms;
@@ -237,6 +238,9 @@ fs_rw_tmpfs_chr_files(sulogin_t)
files_read_etc_files(sulogin_t)
auth_read_shadow(sulogin_t)
+auth_login_pgm_domain(sulogin_t)
+kernel_read_crypto_sysctls(sulogin_t)
+selinux_set_generic_booleans(sulogin_t)
What usage need this access?
init_getpgid_script(sulogin_t)
Index: refpolicy-2.20170421/policy/modules/contrib/policykit.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/contrib/policykit.te
+++ refpolicy-2.20170421/policy/modules/contrib/policykit.te
@@ -87,6 +87,9 @@ domtrans_pattern(policykit_t, policykit_
kernel_read_kernel_sysctls(policykit_t)
kernel_read_system_state(policykit_t)
+fs_getattr_tmpfs(policykit_t)
+fs_getattr_cgroup(policykit_t)
+dev_read_urand(policykit_t)
dev_read_urand(policykit_t)
@@ -101,6 +104,7 @@ auth_use_nsswitch(policykit_t)
userdom_getattr_all_users(policykit_t)
userdom_read_all_users_state(policykit_t)
+userdom_dbus_send_all_users(policykit_t)
optional_policy(`
dbus_system_domain(policykit_t, policykit_exec_t)
Index: refpolicy-2.20170421/policy/modules/contrib/dbus.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/contrib/dbus.te
+++ refpolicy-2.20170421/policy/modules/contrib/dbus.te
@@ -96,6 +96,12 @@ corecmd_exec_shell(system_dbusd_t)
dev_read_urand(system_dbusd_t)
dev_read_sysfs(system_dbusd_t)
+ifdef(`init_systemd', `
+ # gdm3 causes system_dbusd_t to want this access
+ dev_rw_dri(system_dbusd_t)
+ dev_rw_input_dev(system_dbusd_t)
+')
+
domain_use_interactive_fds(system_dbusd_t)
domain_read_all_domains_state(system_dbusd_t)
Index: refpolicy-2.20170421/policy/modules/system/authlogin.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/system/authlogin.te
+++ refpolicy-2.20170421/policy/modules/system/authlogin.te
@@ -105,6 +105,8 @@ files_list_etc(chkpwd_t)
kernel_read_crypto_sysctls(chkpwd_t)
# is_selinux_enabled
kernel_read_system_state(chkpwd_t)
+selinux_get_enforce_mode(chkpwd_t)
+selinux_getattr_fs(chkpwd_t)
domain_dontaudit_use_interactive_fds(chkpwd_t)
Index: refpolicy-2.20170421/policy/modules/contrib/gpg.te
===================================================================
--- refpolicy-2.20170421.orig/policy/modules/contrib/gpg.te
+++ refpolicy-2.20170421/policy/modules/contrib/gpg.te
@@ -87,6 +87,7 @@ gpg_stream_connect_agent(gpg_t)
domtrans_pattern(gpg_t, gpg_agent_exec_t, gpg_agent_t)
domtrans_pattern(gpg_t, gpg_helper_exec_t, gpg_helper_t)
+kernel_read_crypto_sysctls(gpg_t)
kernel_read_sysctl(gpg_t)
# read /proc/cpuinfo
kernel_read_system_state(gpg_t)
@@ -214,6 +215,11 @@ manage_sock_files_pattern(gpg_agent_t, g
manage_files_pattern(gpg_agent_t, gpg_secret_t, gpg_secret_t)
manage_lnk_files_pattern(gpg_agent_t, gpg_secret_t, gpg_secret_t)
+xserver_sigchld_xdm(gpg_agent_t)
+dbus_system_bus_client(gpg_agent_t)
+auth_use_nsswitch(gpg_agent_t)
+xserver_read_user_xauth(gpg_agent_t)
+
manage_dirs_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
manage_files_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
manage_sock_files_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20170421/e61aca09/attachment.html
On the 21st of April 2017 13:57:11 CEST, "Christian G?ttsche via refpolicy" <[email protected]> wrote:
>On 21 Apr 2017 11:10 am, "Russell Coker via refpolicy" <
>refpolicy at oss.tresys.com> wrote:
>
>I put a ifdef wrapper around the GDM access that was contentious.
>Please
>consider this for inclusion now.
>
>Index: refpolicy-2.20170421/policy/modules/system/locallogin.te
>===================================================================
>--- refpolicy-2.20170421.orig/policy/modules/system/locallogin.te
>+++ refpolicy-2.20170421/policy/modules/system/locallogin.te
>@@ -33,6 +33,7 @@ role system_r types sulogin_t;
> #
>
> allow local_login_t self:capability { chown dac_override fowner fsetid
>kill setgid setuid sys_nice sys_resource sys_tty_config };
>+dontaudit local_login_t self:capability net_admin;
> allow local_login_t self:process { setexec setrlimit setsched };
> allow local_login_t self:fd use;
> allow local_login_t self:fifo_file rw_fifo_file_perms;
>@@ -237,6 +238,9 @@ fs_rw_tmpfs_chr_files(sulogin_t)
> files_read_etc_files(sulogin_t)
>
> auth_read_shadow(sulogin_t)
>+auth_login_pgm_domain(sulogin_t)
>+kernel_read_crypto_sysctls(sulogin_t)
>+selinux_set_generic_booleans(sulogin_t)
>
>What usage need this access?
They are dangerous permissions, especially the one that allows to set the SELinux booleans!
Only the system administrator should be permitted to set the booleans interactively through the application...
> init_getpgid_script(sulogin_t)
>
>Index: refpolicy-2.20170421/policy/modules/contrib/policykit.te
>===================================================================
>--- refpolicy-2.20170421.orig/policy/modules/contrib/policykit.te
>+++ refpolicy-2.20170421/policy/modules/contrib/policykit.te
>@@ -87,6 +87,9 @@ domtrans_pattern(policykit_t, policykit_
>
> kernel_read_kernel_sysctls(policykit_t)
> kernel_read_system_state(policykit_t)
>+fs_getattr_tmpfs(policykit_t)
>+fs_getattr_cgroup(policykit_t)
>+dev_read_urand(policykit_t)
>
> dev_read_urand(policykit_t)
>
>@@ -101,6 +104,7 @@ auth_use_nsswitch(policykit_t)
>
> userdom_getattr_all_users(policykit_t)
> userdom_read_all_users_state(policykit_t)
>+userdom_dbus_send_all_users(policykit_t)
>
> optional_policy(`
> dbus_system_domain(policykit_t, policykit_exec_t)
>Index: refpolicy-2.20170421/policy/modules/contrib/dbus.te
>===================================================================
>--- refpolicy-2.20170421.orig/policy/modules/contrib/dbus.te
>+++ refpolicy-2.20170421/policy/modules/contrib/dbus.te
>@@ -96,6 +96,12 @@ corecmd_exec_shell(system_dbusd_t)
> dev_read_urand(system_dbusd_t)
> dev_read_sysfs(system_dbusd_t)
>
>+ifdef(`init_systemd', `
>+ # gdm3 causes system_dbusd_t to want this access
>+ dev_rw_dri(system_dbusd_t)
>+ dev_rw_input_dev(system_dbusd_t)
>+')
>+
> domain_use_interactive_fds(system_dbusd_t)
> domain_read_all_domains_state(system_dbusd_t)
>
>Index: refpolicy-2.20170421/policy/modules/system/authlogin.te
>===================================================================
>--- refpolicy-2.20170421.orig/policy/modules/system/authlogin.te
>+++ refpolicy-2.20170421/policy/modules/system/authlogin.te
>@@ -105,6 +105,8 @@ files_list_etc(chkpwd_t)
> kernel_read_crypto_sysctls(chkpwd_t)
> # is_selinux_enabled
> kernel_read_system_state(chkpwd_t)
>+selinux_get_enforce_mode(chkpwd_t)
>+selinux_getattr_fs(chkpwd_t)
>
> domain_dontaudit_use_interactive_fds(chkpwd_t)
>
>Index: refpolicy-2.20170421/policy/modules/contrib/gpg.te
>===================================================================
>--- refpolicy-2.20170421.orig/policy/modules/contrib/gpg.te
>+++ refpolicy-2.20170421/policy/modules/contrib/gpg.te
>@@ -87,6 +87,7 @@ gpg_stream_connect_agent(gpg_t)
> domtrans_pattern(gpg_t, gpg_agent_exec_t, gpg_agent_t)
> domtrans_pattern(gpg_t, gpg_helper_exec_t, gpg_helper_t)
>
>+kernel_read_crypto_sysctls(gpg_t)
> kernel_read_sysctl(gpg_t)
> # read /proc/cpuinfo
> kernel_read_system_state(gpg_t)
>@@ -214,6 +215,11 @@ manage_sock_files_pattern(gpg_agent_t, g
> manage_files_pattern(gpg_agent_t, gpg_secret_t, gpg_secret_t)
> manage_lnk_files_pattern(gpg_agent_t, gpg_secret_t, gpg_secret_t)
>
>+xserver_sigchld_xdm(gpg_agent_t)
>+dbus_system_bus_client(gpg_agent_t)
>+auth_use_nsswitch(gpg_agent_t)
>+xserver_read_user_xauth(gpg_agent_t)
>+
> manage_dirs_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
> manage_files_pattern(gpg_agent_t, gpg_agent_tmp_t, gpg_agent_tmp_t)
>manage_sock_files_pattern(gpg_agent_t, gpg_agent_tmp_t,
>gpg_agent_tmp_t)
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy
On Fri, 21 Apr 2017 09:57:11 PM Christian G?ttsche wrote:
> auth_read_shadow(sulogin_t)
> +auth_login_pgm_domain(sulogin_t)
> +kernel_read_crypto_sysctls(sulogin_t)
> +selinux_set_generic_booleans(sulogin_t)
>
> What usage need this access?
Just the sulogin program.
Can you please configure your MUA to put "> " at the start of every quoted
line? It makes it very difficult to read if you don't differentate the quoted
text from what you write.
If necessary just type "> " at the start of every line you quote.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Hello again.
On the 21st of April 2017 14:20:12 CEST, Russell Coker via refpolicy <[email protected]> wrote:
>On Fri, 21 Apr 2017 09:57:11 PM Christian G?ttsche wrote:
>> auth_read_shadow(sulogin_t)
>> +auth_login_pgm_domain(sulogin_t)
>> +kernel_read_crypto_sysctls(sulogin_t)
>> +selinux_set_generic_booleans(sulogin_t)
>>
>> What usage need this access?
>
>Just the sulogin program.
I also have the sulogin program, it comes from sysvinit, but it doesn't require the above dangerous permissions...
Sounds like a non-standard sulogin which does wrong things, things that it shouldn't be doing because they are not related to its job.
Where does your sulogin program come from?
>Can you please configure your MUA to put "> " at the start of every
>quoted
>line? It makes it very difficult to read if you don't differentate the
>quoted
>text from what you write.
>
>If necessary just type "> " at the start of every line you quote.
I read the message from Christian correctly. There is no line separation between quoted and non-quoted text, but apart from that the quoted text appears correctly marked. Strange problem...
Regards,
Guido
On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy wrote:
> > auth_read_shadow(sulogin_t)
> >
> >+auth_login_pgm_domain(sulogin_t)
> >+kernel_read_crypto_sysctls(sulogin_t)
> >+selinux_set_generic_booleans(sulogin_t)
> >
> >What usage need this access?
>
> They are dangerous permissions, especially the one that allows to set the
> SELinux booleans!
>
> Only the system administrator should be permitted to set the booleans
> interactively through the application...
Sulogin only runs at the console when something goes wrong in the early boot
process, and the first thing it does is ask for a root password.
It's simply impossible for sulogin to do what it does without the first line,
it is a login program.
The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
user_mail_domain among others. If we need to restrict access to that then
exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all deal with
untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are exposed to
data from the Internet and have that access.
The policy currently has sysadm_shell_domtrans(sulogin_t) which allows sulogin
to execute "bash -c setsebool" or similar. So allowing it to set booleans
directly doesn't really change much.
There is simply no possibility to allow sulogin to do what it is intended to
do without granting it access to destroy things (at least indirectly). If you
don't want that then the only option is to remove sulogin. I guess you could
submit a patch with a boolean to deny executing sulogin_exec_t for init if
that's what you want.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via refpolicy wrote:
> On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy wrote:
> > > auth_read_shadow(sulogin_t)
> > >
> > >+auth_login_pgm_domain(sulogin_t)
> > >+kernel_read_crypto_sysctls(sulogin_t)
> > >+selinux_set_generic_booleans(sulogin_t)
> > >
> > >What usage need this access?
> >
> > They are dangerous permissions, especially the one that allows to set the
> > SELinux booleans!
> >
> > Only the system administrator should be permitted to set the booleans
> > interactively through the application...
>
> Sulogin only runs at the console when something goes wrong in the early boot
> process, and the first thing it does is ask for a root password.
>
> It's simply impossible for sulogin to do what it does without the first line,
> it is a login program.
I don't think its a login program from an authlogin perspective. It has no pam config here on fedora. There are no default contexts for sulogin
>
> The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
> user_mail_domain among others. If we need to restrict access to that then
> exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all deal with
> untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are exposed to
> data from the Internet and have that access.
>
> The policy currently has sysadm_shell_domtrans(sulogin_t) which allows sulogin
> to execute "bash -c setsebool" or similar. So allowing it to set booleans
> directly doesn't really change much.
>
> There is simply no possibility to allow sulogin to do what it is intended to
> do without granting it access to destroy things (at least indirectly). If you
> don't want that then the only option is to remove sulogin. I guess you could
> submit a patch with a boolean to deny executing sulogin_exec_t for init if
> that's what you want.
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170421/a69154c2/attachment.bin
On Fri, Apr 21, 2017 at 02:42:46PM +0200, Dominick Grift wrote:
> On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via refpolicy wrote:
> > On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy wrote:
> > > > auth_read_shadow(sulogin_t)
> > > >
> > > >+auth_login_pgm_domain(sulogin_t)
> > > >+kernel_read_crypto_sysctls(sulogin_t)
> > > >+selinux_set_generic_booleans(sulogin_t)
> > > >
> > > >What usage need this access?
> > >
> > > They are dangerous permissions, especially the one that allows to set the
> > > SELinux booleans!
> > >
> > > Only the system administrator should be permitted to set the booleans
> > > interactively through the application...
> >
> > Sulogin only runs at the console when something goes wrong in the early boot
> > process, and the first thing it does is ask for a root password.
> >
> > It's simply impossible for sulogin to do what it does without the first line,
> > it is a login program.
>
> I don't think its a login program from an authlogin perspective. It has no pam config here on fedora. There are no default contexts for sulogin
Ok i might be wrong here with regard there not being default contexts. I do believe that it somehow uses default contexts but there does not seem to be a pam config here
>
> >
> > The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
> > user_mail_domain among others. If we need to restrict access to that then
> > exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all deal with
> > untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are exposed to
> > data from the Internet and have that access.
> >
> > The policy currently has sysadm_shell_domtrans(sulogin_t) which allows sulogin
> > to execute "bash -c setsebool" or similar. So allowing it to set booleans
> > directly doesn't really change much.
> >
> > There is simply no possibility to allow sulogin to do what it is intended to
> > do without granting it access to destroy things (at least indirectly). If you
> > don't want that then the only option is to remove sulogin. I guess you could
> > submit a patch with a boolean to deny executing sulogin_exec_t for init if
> > that's what you want.
> >
> > --
> > My Main Blog http://etbe.coker.com.au/
> > My Documents Blog http://doc.coker.com.au/
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
>
> --
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170421/4012fd4c/attachment-0001.bin
On Fri, 21 Apr 2017 10:30:12 PM Guido Trentalancia via refpolicy wrote:
> >> +auth_login_pgm_domain(sulogin_t)
> >> +kernel_read_crypto_sysctls(sulogin_t)
> >> +selinux_set_generic_booleans(sulogin_t)
> >>
> >> What usage need this access?
> >
> >Just the sulogin program.
>
> I also have the sulogin program, it comes from sysvinit, but it doesn't
> require the above dangerous permissions...
Mine comes from util-linux.
Again I don't think there's a benefit in stopping sulogin from doing things
directly when it is permitted to run "sh -c setsebool" for the same result.
If you were going to try and exploit sulogin would you try and trick the
executable into using the SE Linux API calls or would you aim for
system("setsebool...")?
> >Can you please configure your MUA to put "> " at the start of every
> >quoted
> >line? It makes it very difficult to read if you don't differentate the
> >quoted
> >text from what you write.
> >
> >If necessary just type "> " at the start of every line you quote.
>
> I read the message from Christian correctly. There is no line separation
> between quoted and non-quoted text, but apart from that the quoted text
> appears correctly marked. Strange problem...
Maybe you are reading the HTML version.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
It doesn't have a PAM configuration file for the simple reason that it doesn't use PAM...
I am now testing the other permissions, it should be easier and safer than just speculating on the possible behavior.
I getting a very different behavior!
Will get back shortly.
Regards,
Guido
On the 21st April 2017 14:48:48 CEST, Dominick Grift via refpolicy <[email protected]> wrote:
>On Fri, Apr 21, 2017 at 02:42:46PM +0200, Dominick Grift wrote:
>> On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via refpolicy
>wrote:
>> > On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy
>wrote:
>> > > > auth_read_shadow(sulogin_t)
>> > > >
>> > > >+auth_login_pgm_domain(sulogin_t)
>> > > >+kernel_read_crypto_sysctls(sulogin_t)
>> > > >+selinux_set_generic_booleans(sulogin_t)
>> > > >
>> > > >What usage need this access?
>> > >
>> > > They are dangerous permissions, especially the one that allows to
>set the
>> > > SELinux booleans!
>> > >
>> > > Only the system administrator should be permitted to set the
>booleans
>> > > interactively through the application...
>> >
>> > Sulogin only runs at the console when something goes wrong in the
>early boot
>> > process, and the first thing it does is ask for a root password.
>> >
>> > It's simply impossible for sulogin to do what it does without the
>first line,
>> > it is a login program.
>>
>> I don't think its a login program from an authlogin perspective. It
>has no pam config here on fedora. There are no default contexts for
>sulogin
>
>Ok i might be wrong here with regard there not being default contexts.
>I do believe that it somehow uses default contexts but there does not
>seem to be a pam config here
>
>>
>> >
>> > The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
>> > user_mail_domain among others. If we need to restrict access to
>that then
>> > exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all
>deal with
>> > untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are
>exposed to
>> > data from the Internet and have that access.
>> >
>> > The policy currently has sysadm_shell_domtrans(sulogin_t) which
>allows sulogin
>> > to execute "bash -c setsebool" or similar. So allowing it to set
>booleans
>> > directly doesn't really change much.
>> >
>> > There is simply no possibility to allow sulogin to do what it is
>intended to
>> > do without granting it access to destroy things (at least
>indirectly). If you
>> > don't want that then the only option is to remove sulogin. I guess
>you could
>> > submit a patch with a boolean to deny executing sulogin_exec_t for
>init if
>> > that's what you want.
>> >
>> > --
>> > My Main Blog http://etbe.coker.com.au/
>> > My Documents Blog http://doc.coker.com.au/
>> > _______________________________________________
>> > refpolicy mailing list
>> > refpolicy at oss.tresys.com
>> > http://oss.tresys.com/mailman/listinfo/refpolicy
>>
>> --
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
>>
>https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>> Dominick Grift
On Fri, Apr 21, 2017 at 03:33:50PM +0200, Guido Trentalancia via refpolicy wrote:
> It doesn't have a PAM configuration file for the simple reason that it doesn't use PAM...
And thus it is not a authlogin login program
>
> I am now testing the other permissions, it should be easier and safer than just speculating on the possible behavior.
>
> I getting a very different behavior!
>
> Will get back shortly.
>
> Regards,
>
> Guido
>
> On the 21st April 2017 14:48:48 CEST, Dominick Grift via refpolicy <[email protected]> wrote:
> >On Fri, Apr 21, 2017 at 02:42:46PM +0200, Dominick Grift wrote:
> >> On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via refpolicy
> >wrote:
> >> > On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy
> >wrote:
> >> > > > auth_read_shadow(sulogin_t)
> >> > > >
> >> > > >+auth_login_pgm_domain(sulogin_t)
> >> > > >+kernel_read_crypto_sysctls(sulogin_t)
> >> > > >+selinux_set_generic_booleans(sulogin_t)
> >> > > >
> >> > > >What usage need this access?
> >> > >
> >> > > They are dangerous permissions, especially the one that allows to
> >set the
> >> > > SELinux booleans!
> >> > >
> >> > > Only the system administrator should be permitted to set the
> >booleans
> >> > > interactively through the application...
> >> >
> >> > Sulogin only runs at the console when something goes wrong in the
> >early boot
> >> > process, and the first thing it does is ask for a root password.
> >> >
> >> > It's simply impossible for sulogin to do what it does without the
> >first line,
> >> > it is a login program.
> >>
> >> I don't think its a login program from an authlogin perspective. It
> >has no pam config here on fedora. There are no default contexts for
> >sulogin
> >
> >Ok i might be wrong here with regard there not being default contexts.
> >I do believe that it somehow uses default contexts but there does not
> >seem to be a pam config here
> >
> >>
> >> >
> >> > The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
> >> > user_mail_domain among others. If we need to restrict access to
> >that then
> >> > exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all
> >deal with
> >> > untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are
> >exposed to
> >> > data from the Internet and have that access.
> >> >
> >> > The policy currently has sysadm_shell_domtrans(sulogin_t) which
> >allows sulogin
> >> > to execute "bash -c setsebool" or similar. So allowing it to set
> >booleans
> >> > directly doesn't really change much.
> >> >
> >> > There is simply no possibility to allow sulogin to do what it is
> >intended to
> >> > do without granting it access to destroy things (at least
> >indirectly). If you
> >> > don't want that then the only option is to remove sulogin. I guess
> >you could
> >> > submit a patch with a boolean to deny executing sulogin_exec_t for
> >init if
> >> > that's what you want.
> >> >
> >> > --
> >> > My Main Blog http://etbe.coker.com.au/
> >> > My Documents Blog http://doc.coker.com.au/
> >> > _______________________________________________
> >> > refpolicy mailing list
> >> > refpolicy at oss.tresys.com
> >> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >>
> >> --
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> >>
> >https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170421/ca552e87/attachment.bin
I confirm that such auth permission is not needed. It uses shadow directly and it already has the appropriate auth_read_shadow() interface call!
I am now checking the details...
On the 21st of April 2017 15:42:01 CEST, Dominick Grift via refpolicy <[email protected]> wrote:
>On Fri, Apr 21, 2017 at 03:33:50PM +0200, Guido Trentalancia via
>refpolicy wrote:
>> It doesn't have a PAM configuration file for the simple reason that
>it doesn't use PAM...
>
>And thus it is not a authlogin login program
>
>>
>> I am now testing the other permissions, it should be easier and safer
>than just speculating on the possible behavior.
>>
>> I getting a very different behavior!
>>
>> Will get back shortly.
>>
>> Regards,
>>
>> Guido
>>
>> On the 21st April 2017 14:48:48 CEST, Dominick Grift via refpolicy
><[email protected]> wrote:
>> >On Fri, Apr 21, 2017 at 02:42:46PM +0200, Dominick Grift wrote:
>> >> On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via
>refpolicy
>> >wrote:
>> >> > On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy
>> >wrote:
>> >> > > > auth_read_shadow(sulogin_t)
>> >> > > >
>> >> > > >+auth_login_pgm_domain(sulogin_t)
>> >> > > >+kernel_read_crypto_sysctls(sulogin_t)
>> >> > > >+selinux_set_generic_booleans(sulogin_t)
>> >> > > >
>> >> > > >What usage need this access?
>> >> > >
>> >> > > They are dangerous permissions, especially the one that allows
>to
>> >set the
>> >> > > SELinux booleans!
>> >> > >
>> >> > > Only the system administrator should be permitted to set the
>> >booleans
>> >> > > interactively through the application...
>> >> >
>> >> > Sulogin only runs at the console when something goes wrong in
>the
>> >early boot
>> >> > process, and the first thing it does is ask for a root password.
>> >> >
>> >> > It's simply impossible for sulogin to do what it does without
>the
>> >first line,
>> >> > it is a login program.
>> >>
>> >> I don't think its a login program from an authlogin perspective.
>It
>> >has no pam config here on fedora. There are no default contexts for
>> >sulogin
>> >
>> >Ok i might be wrong here with regard there not being default
>contexts.
>> >I do believe that it somehow uses default contexts but there does
>not
>> >seem to be a pam config here
>> >
>> >>
>> >> >
>> >> > The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
>
>> >> > user_mail_domain among others. If we need to restrict access to
>> >that then
>> >> > exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all
>> >deal with
>> >> > untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t
>are
>> >exposed to
>> >> > data from the Internet and have that access.
>> >> >
>> >> > The policy currently has sysadm_shell_domtrans(sulogin_t) which
>> >allows sulogin
>> >> > to execute "bash -c setsebool" or similar. So allowing it to
>set
>> >booleans
>> >> > directly doesn't really change much.
>> >> >
>> >> > There is simply no possibility to allow sulogin to do what it is
>> >intended to
>> >> > do without granting it access to destroy things (at least
>> >indirectly). If you
>> >> > don't want that then the only option is to remove sulogin. I
>guess
>> >you could
>> >> > submit a patch with a boolean to deny executing sulogin_exec_t
>for
>> >init if
>> >> > that's what you want.
>> >> >
>> >> > --
>> >> > My Main Blog http://etbe.coker.com.au/
>> >> > My Documents Blog http://doc.coker.com.au/
>> >> > _______________________________________________
>> >> > refpolicy mailing list
>> >> > refpolicy at oss.tresys.com
>> >> > http://oss.tresys.com/mailman/listinfo/refpolicy
>> >>
>> >> --
>> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B
>6B02
>> >>
>>
>>https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>> >> Dominick Grift
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
On Fri, Apr 21, 2017 at 03:47:35PM +0200, Guido Trentalancia via refpolicy wrote:
> I confirm that such auth permission is not needed. It uses shadow directly and it already has the appropriate auth_read_shadow() interface call!
>
> I am now checking the details...
There seems to be bug though in refpolicy
in refpolicy sulogin seems to use an auto type transition to sysadm_t but , atleast in fedora, sulogin does actually look up default contexts
if you add system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0 to contexts/users/sysadm_u then sulogin will try to manually transition to that context provided that it has the permisisons to do so.
So its not a authlogin login program but it is selinux aware
>
> On the 21st of April 2017 15:42:01 CEST, Dominick Grift via refpolicy <[email protected]> wrote:
> >On Fri, Apr 21, 2017 at 03:33:50PM +0200, Guido Trentalancia via
> >refpolicy wrote:
> >> It doesn't have a PAM configuration file for the simple reason that
> >it doesn't use PAM...
> >
> >And thus it is not a authlogin login program
> >
> >>
> >> I am now testing the other permissions, it should be easier and safer
> >than just speculating on the possible behavior.
> >>
> >> I getting a very different behavior!
> >>
> >> Will get back shortly.
> >>
> >> Regards,
> >>
> >> Guido
> >>
> >> On the 21st April 2017 14:48:48 CEST, Dominick Grift via refpolicy
> ><[email protected]> wrote:
> >> >On Fri, Apr 21, 2017 at 02:42:46PM +0200, Dominick Grift wrote:
> >> >> On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via
> >refpolicy
> >> >wrote:
> >> >> > On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy
> >> >wrote:
> >> >> > > > auth_read_shadow(sulogin_t)
> >> >> > > >
> >> >> > > >+auth_login_pgm_domain(sulogin_t)
> >> >> > > >+kernel_read_crypto_sysctls(sulogin_t)
> >> >> > > >+selinux_set_generic_booleans(sulogin_t)
> >> >> > > >
> >> >> > > >What usage need this access?
> >> >> > >
> >> >> > > They are dangerous permissions, especially the one that allows
> >to
> >> >set the
> >> >> > > SELinux booleans!
> >> >> > >
> >> >> > > Only the system administrator should be permitted to set the
> >> >booleans
> >> >> > > interactively through the application...
> >> >> >
> >> >> > Sulogin only runs at the console when something goes wrong in
> >the
> >> >early boot
> >> >> > process, and the first thing it does is ask for a root password.
> >> >> >
> >> >> > It's simply impossible for sulogin to do what it does without
> >the
> >> >first line,
> >> >> > it is a login program.
> >> >>
> >> >> I don't think its a login program from an authlogin perspective.
> >It
> >> >has no pam config here on fedora. There are no default contexts for
> >> >sulogin
> >> >
> >> >Ok i might be wrong here with regard there not being default
> >contexts.
> >> >I do believe that it somehow uses default contexts but there does
> >not
> >> >seem to be a pam config here
> >> >
> >> >>
> >> >> >
> >> >> > The second is used by exim_t, lpr_t, boinc_t, mailman_cgi_t, and
> >
> >> >> > user_mail_domain among others. If we need to restrict access to
> >> >that then
> >> >> > exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all
> >> >deal with
> >> >> > untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t
> >are
> >> >exposed to
> >> >> > data from the Internet and have that access.
> >> >> >
> >> >> > The policy currently has sysadm_shell_domtrans(sulogin_t) which
> >> >allows sulogin
> >> >> > to execute "bash -c setsebool" or similar. So allowing it to
> >set
> >> >booleans
> >> >> > directly doesn't really change much.
> >> >> >
> >> >> > There is simply no possibility to allow sulogin to do what it is
> >> >intended to
> >> >> > do without granting it access to destroy things (at least
> >> >indirectly). If you
> >> >> > don't want that then the only option is to remove sulogin. I
> >guess
> >> >you could
> >> >> > submit a patch with a boolean to deny executing sulogin_exec_t
> >for
> >> >init if
> >> >> > that's what you want.
> >> >> >
> >> >> > --
> >> >> > My Main Blog http://etbe.coker.com.au/
> >> >> > My Documents Blog http://doc.coker.com.au/
> >> >> > _______________________________________________
> >> >> > refpolicy mailing list
> >> >> > refpolicy at oss.tresys.com
> >> >> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >> >>
> >> >> --
> >> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B
> >6B02
> >> >>
> >>
> >>https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> >> >> Dominick Grift
> >>
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy at oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170421/e4a6529b/attachment-0001.bin
On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy wrote:
> I confirm that such auth permission is not needed. It uses shadow directly
> and it already has the appropriate auth_read_shadow() interface call!
>
> I am now checking the details...
The interface auth_login_pgm_domain() does a lot more than providing PAM
access. One could make a case for splitting it into 2 or 3 interfaces that
perform different subsets of it's operations. If you think that is the case
then please submit a patch to the list and we can discuss that.
But I don't think there's much benefit to trying to restrict a domain that can
launch a shell as sysadm_t or unconfined_t.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Hello again.
I am afraid, but after testing it, I have to confirm that the three debated permissions that you are trying to introduce (auth, kernel and selinux) are not needed for the normal functioning of sulogin (from util-linux): they are redundant and dangerous.
Regards,
Guido
On the 21st of April 2017 16:23:24 CEST, Russell Coker <[email protected]> wrote:
>On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy wrote:
>> I confirm that such auth permission is not needed. It uses shadow
>directly
>> and it already has the appropriate auth_read_shadow() interface call!
>>
>> I am now checking the details...
>
>The interface auth_login_pgm_domain() does a lot more than providing
>PAM
>access. One could make a case for splitting it into 2 or 3 interfaces
>that
>perform different subsets of it's operations. If you think that is the
>case
>then please submit a patch to the list and we can discuss that.
>
>But I don't think there's much benefit to trying to restrict a domain
>that can
>launch a shell as sysadm_t or unconfined_t.
On the 21st of April 2017 16:39:09 CEST, Guido Trentalancia via refpolicy <[email protected]> wrote:
>Hello again.
>
>I am afraid, but after testing it, I have to confirm that the three
>debated permissions that you are trying to introduce (auth, kernel and
>selinux) are not needed for the normal functioning of sulogin (from
>util-linux): they are redundant and dangerous.
Only the kernel_read_crypto_sysctls() might be needed. But I am still completing the test...
>Regards,
>
>Guido
>
>On the 21st of April 2017 16:23:24 CEST, Russell Coker
><[email protected]> wrote:
>>On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy
>wrote:
>>> I confirm that such auth permission is not needed. It uses shadow
>>directly
>>> and it already has the appropriate auth_read_shadow() interface
>call!
>>>
>>> I am now checking the details...
>>
>>The interface auth_login_pgm_domain() does a lot more than providing
>>PAM
>>access. One could make a case for splitting it into 2 or 3 interfaces
>>that
>>perform different subsets of it's operations. If you think that is
>the
>>case
>>then please submit a patch to the list and we can discuss that.
>>
>>But I don't think there's much benefit to trying to restrict a domain
>>that can
>>launch a shell as sysadm_t or unconfined_t.
>
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy
On the 21st of April 2017 16:39:09 CEST, Guido Trentalancia via refpolicy <[email protected]> wrote:
>Hello again.
>
>I am afraid, but after testing it, I have to confirm that the three
>debated permissions that you are trying to introduce (auth, kernel and
>selinux) are not needed for the normal functioning of sulogin (from
>util-linux): they are redundant and dangerous.
The kernel_read_crypto_sysctls() can be substituted by the safer kernel_read_sysctl() and it gets away with it...
>Regards,
>
>Guido
>
>On the 21st of April 2017 16:23:24 CEST, Russell Coker
><[email protected]> wrote:
>>On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy
>wrote:
>>> I confirm that such auth permission is not needed. It uses shadow
>>directly
>>> and it already has the appropriate auth_read_shadow() interface
>call!
>>>
>>> I am now checking the details...
>>
>>The interface auth_login_pgm_domain() does a lot more than providing
>>PAM
>>access. One could make a case for splitting it into 2 or 3 interfaces
>>that
>>perform different subsets of it's operations. If you think that is
>the
>>case
>>then please submit a patch to the list and we can discuss that.
>>
>>But I don't think there's much benefit to trying to restrict a domain
>>that can
>>launch a shell as sysadm_t or unconfined_t.
>
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy
On the 21st of April 2017 17:08:19 CEST, Guido Trentalancia via refpolicy <[email protected]> wrote:
>
>
>On the 21st of April 2017 16:39:09 CEST, Guido Trentalancia via
>refpolicy <[email protected]> wrote:
>>Hello again.
>
[...]
>
>The kernel_read_crypto_sysctls() can be substituted by the safer
>kernel_read_sysctl() and it gets away with it...
Actually, I think I was wrong on the latter!
Because it looks for the "fips_enabled" sysctl, so it is better if it founds it, because otherwise there might be side-effects.
>>Regards,
>>
>>Guido
>>
>>On the 21st of April 2017 16:23:24 CEST, Russell Coker
>><[email protected]> wrote:
>>>On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy
>>wrote:
>>>> I confirm that such auth permission is not needed. It uses shadow
>>>directly
>>>> and it already has the appropriate auth_read_shadow() interface
>>call!
>>>>
>>>> I am now checking the details...
>>>
>>>The interface auth_login_pgm_domain() does a lot more than providing
>>>PAM
>>>access. One could make a case for splitting it into 2 or 3
>interfaces
>>>that
>>>perform different subsets of it's operations. If you think that is
>>the
>>>case
>>>then please submit a patch to the list and we can discuss that.
>>>
>>>But I don't think there's much benefit to trying to restrict a domain
>>>that can
>>>launch a shell as sysadm_t or unconfined_t.
>>
>>_______________________________________________
>>refpolicy mailing list
>>refpolicy at oss.tresys.com
>>http://oss.tresys.com/mailman/listinfo/refpolicy
>
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy