login related stuff take 2

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

policy/modules/system/locallogin.te +0 -0

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

policy/modules/system/locallogin.te +3 -0

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

policy/modules/contrib/policykit.te +4 -0

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

policy/modules/contrib/dbus.te +6 -0

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

policy/modules/system/authlogin.te +2 -0

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

policy/modules/contrib/gpg.te +6 -0

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

Quoted 6 lines

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

+auth_login_pgm_domain(sulogin_t)
+kernel_read_crypto_sysctls(sulogin_t)
+selinux_set_generic_booleans(sulogin_t)

Quoted 1 line

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

Quoted 11 lines · Guido Trentalancia via refpolicy

Quoted 7 lines

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

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

Quoted 2 lines

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.

Signature · 6 lines

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

Quoted 15 lines · Russell Coker via refpolicy

Quoted 13 lines · Guido Trentalancia via refpolicy

Quoted 7 lines

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

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

Quoted 5 lines

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

Quoted 25 lines

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.

Signature · 6 lines

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

Signature · 3 lines

Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Quoted 1 line · Dominick Grift

On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via refpolicy

Quoted 1 line · wrote:

Quoted 1 line

On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy

Quoted 9 lines · wrote:

Quoted 9 lines

Quoted 9 lines

Quoted 7 lines

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

+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

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SELinux booleans!

Only the system administrator should be permitted to set the

booleans

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

interactively through the application...

Sulogin only runs at the console when something goes wrong in the

early boot

Quoted 3 lines

Quoted 3 lines

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,

Quoted 3 lines

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

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all

deal with

Quoted 1 line

Quoted 1 line

untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are

exposed to

Quoted 3 lines

Quoted 3 lines

data from the Internet and have that access.

The policy currently has sysadm_shell_domtrans(sulogin_t) which

allows sulogin

Quoted 1 line

Quoted 1 line

to execute "bash -c setsebool" or similar. So allowing it to set

booleans

Quoted 3 lines

Quoted 3 lines

directly doesn't really change much.

There is simply no possibility to allow sulogin to do what it is

intended to

Quoted 1 line

Quoted 1 line

do without granting it access to destroy things (at least

indirectly). If you

Quoted 1 line

Quoted 1 line

don't want that then the only option is to remove sulogin. I guess

you could

Quoted 1 line

Quoted 1 line

submit a patch with a boolean to deny executing sulogin_exec_t for

init if

Quoted 13 lines

Quoted 9 lines

that's what you want.

Signature · 6 lines

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

Signature · 1 line

Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02

https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02

Quoted 1 line

Dominick Grift

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

Quoted 72 lines · Dominick Grift via refpolicy

Quoted 1 line · Dominick Grift

On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via refpolicy

Quoted 1 line · wrote:

Quoted 1 line

On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy

Quoted 9 lines · wrote:

Quoted 9 lines

Quoted 9 lines

Quoted 7 lines

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

+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

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SELinux booleans!

Only the system administrator should be permitted to set the

booleans

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

interactively through the application...

Sulogin only runs at the console when something goes wrong in the

early boot

Quoted 3 lines

Quoted 3 lines

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,

Quoted 3 lines

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

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all

deal with

Quoted 1 line

Quoted 1 line

untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t are

exposed to

Quoted 3 lines

Quoted 3 lines

data from the Internet and have that access.

The policy currently has sysadm_shell_domtrans(sulogin_t) which

allows sulogin

Quoted 1 line

Quoted 1 line

to execute "bash -c setsebool" or similar. So allowing it to set

booleans

Quoted 3 lines

Quoted 3 lines

directly doesn't really change much.

There is simply no possibility to allow sulogin to do what it is

intended to

Quoted 1 line

Quoted 1 line

do without granting it access to destroy things (at least

indirectly). If you

Quoted 1 line

Quoted 1 line

don't want that then the only option is to remove sulogin. I guess

you could

Quoted 1 line

Quoted 1 line

submit a patch with a boolean to deny executing sulogin_exec_t for

init if

Quoted 10 lines

Quoted 9 lines

that's what you want.

Signature · 6 lines

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

Quoted 5 lines

Quoted 3 lines

Signature · 1 line

Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02

https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02

Quoted 1 line

Dominick Grift

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 1 line · Guido Trentalancia via refpolicy

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

Quoted 2 lines

I am now testing the other permissions, it should be easier and safer

than just speculating on the possible behavior.

Quoted 10 lines

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

Quoted 2 lines · <[email protected]> wrote:

Quoted 2 lines · Dominick Grift

Quoted 1 line

On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via

refpolicy

Quoted 5 lines

Quoted 5 lines

Quoted 1 line · wrote:

Quoted 1 line

On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

auth_read_shadow(sulogin_t)

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

(quoted diff) +3 -0

+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

Quoted 8 lines

Quoted 8 lines

set the

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SELinux booleans!

Only the system administrator should be permitted to set the

booleans

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

interactively through the application...

Sulogin only runs at the console when something goes wrong in

the

Quoted 4 lines

Quoted 4 lines

early boot

Quoted 3 lines

Quoted 3 lines

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

Quoted 4 lines

Quoted 4 lines

first line,

Quoted 3 lines

Quoted 1 line

it is a login program.

I don't think its a login program from an authlogin perspective.

It

Quoted 4 lines

Quoted 4 lines

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.

Quoted 1 line

Quoted 1 line

I do believe that it somehow uses default contexts but there does

not

Quoted 11 lines

Quoted 11 lines

seem to be a pam config here

Quoted 5 lines

Quoted 5 lines

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

Quoted 1 line

Quoted 1 line

exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all

deal with

Quoted 1 line

Quoted 1 line

untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t

are

Quoted 6 lines

Quoted 6 lines

exposed to

Quoted 3 lines

Quoted 3 lines

data from the Internet and have that access.

The policy currently has sysadm_shell_domtrans(sulogin_t) which

allows sulogin

Quoted 1 line

Quoted 1 line

to execute "bash -c setsebool" or similar. So allowing it to

set

Quoted 8 lines

Quoted 8 lines

booleans

Quoted 3 lines

Quoted 3 lines

directly doesn't really change much.

There is simply no possibility to allow sulogin to do what it is

intended to

Quoted 1 line

Quoted 1 line

do without granting it access to destroy things (at least

indirectly). If you

Quoted 1 line

Quoted 1 line

don't want that then the only option is to remove sulogin. I

guess

Quoted 2 lines

Quoted 2 lines

you could

Quoted 1 line

Quoted 1 line

submit a patch with a boolean to deny executing sulogin_exec_t

for

Quoted 11 lines

Quoted 11 lines

init if

Quoted 10 lines

Quoted 9 lines

that's what you want.

Signature · 6 lines

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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Signature · 1 line

Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B

6B02

Quoted 9 lines

Quoted 1 line

Quoted 1 line

https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02

Quoted 1 line

Quoted 1 line

Dominick Grift

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

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

Quoted 105 lines

Quoted 1 line · Guido Trentalancia via refpolicy

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

Quoted 2 lines

I am now testing the other permissions, it should be easier and safer

than just speculating on the possible behavior.

Quoted 10 lines

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

Quoted 2 lines · <[email protected]> wrote:

Quoted 2 lines · Dominick Grift

Quoted 1 line

On Fri, Apr 21, 2017 at 10:38:06PM +1000, Russell Coker via

refpolicy

Quoted 5 lines

Quoted 5 lines

Quoted 1 line · wrote:

Quoted 1 line

On Fri, 21 Apr 2017 10:06:29 PM Guido Trentalancia via refpolicy

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

auth_read_shadow(sulogin_t)

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

(quoted diff) +3 -0

+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

Quoted 8 lines

Quoted 8 lines

set the

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SELinux booleans!

Only the system administrator should be permitted to set the

booleans

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

interactively through the application...

Sulogin only runs at the console when something goes wrong in

the

Quoted 4 lines

Quoted 4 lines

early boot

Quoted 3 lines

Quoted 3 lines

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

Quoted 4 lines

Quoted 4 lines

first line,

Quoted 3 lines

Quoted 1 line

it is a login program.

I don't think its a login program from an authlogin perspective.

It

Quoted 4 lines

Quoted 4 lines

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.

Quoted 1 line

Quoted 1 line

I do believe that it somehow uses default contexts but there does

not

Quoted 11 lines

Quoted 11 lines

seem to be a pam config here

Quoted 5 lines

Quoted 5 lines

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

Quoted 1 line

Quoted 1 line

exim_t, lpr_t, boinc_t, mailman_cgi_t, and user_mail_domain all

deal with

Quoted 1 line

Quoted 1 line

untrusted data. The domains exim_t, boinc_t, and mailman_cgi_t

are

Quoted 6 lines

Quoted 6 lines

exposed to

Quoted 3 lines

Quoted 3 lines

data from the Internet and have that access.

The policy currently has sysadm_shell_domtrans(sulogin_t) which

allows sulogin

Quoted 1 line

Quoted 1 line

to execute "bash -c setsebool" or similar. So allowing it to

set

Quoted 8 lines

Quoted 8 lines

booleans

Quoted 3 lines

Quoted 3 lines

directly doesn't really change much.

There is simply no possibility to allow sulogin to do what it is

intended to

Quoted 1 line

Quoted 1 line

do without granting it access to destroy things (at least

indirectly). If you

Quoted 1 line

Quoted 1 line

don't want that then the only option is to remove sulogin. I

guess

Quoted 2 lines

Quoted 2 lines

you could

Quoted 1 line

Quoted 1 line

submit a patch with a boolean to deny executing sulogin_exec_t

for

Quoted 11 lines

Quoted 11 lines

init if

Quoted 10 lines

Quoted 9 lines

that's what you want.

Signature · 6 lines

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

Quoted 12 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Signature · 1 line

Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B

6B02

Quoted 9 lines

Quoted 1 line

Quoted 1 line

https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02

Quoted 1 line

Quoted 1 line

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

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

Quoted 1 line · Guido Trentalancia via refpolicy

I confirm that such auth permission is not needed. It uses shadow

directly

Quoted 3 lines

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.

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

Quoted 1 line · Russell Coker

On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy

Quoted 3 lines · wrote:

Quoted 1 line

I confirm that such auth permission is not needed. It uses shadow

directly

Quoted 1 line

and it already has the appropriate auth_read_shadow() interface

call!

Quoted 8 lines

Quoted 2 lines

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

Quoted 6 lines

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

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

Quoted 1 line · Russell Coker

On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy

Quoted 3 lines · wrote:

Quoted 1 line

I confirm that such auth permission is not needed. It uses shadow

directly

Quoted 1 line

and it already has the appropriate auth_read_shadow() interface

call!

Quoted 8 lines

Quoted 2 lines

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

Quoted 6 lines

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

Quoted 1 line · Guido Trentalancia via refpolicy

Hello again.

The kernel_read_crypto_sysctls() can be substituted by the safer kernel_read_sysctl() and it gets away with it...

Quoted 4 lines

Regards,

Guido

Quoted 14 lines

Quoted 1 line · Russell Coker

On Fri, 21 Apr 2017 11:47:35 PM Guido Trentalancia via refpolicy

Quoted 3 lines · wrote:

Quoted 1 line

I confirm that such auth permission is not needed. It uses shadow

directly

Quoted 1 line

and it already has the appropriate auth_read_shadow() interface

call!

Quoted 6 lines

Quoted 2 lines

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

Quoted 6 lines

Quoted 2 lines

that
perform different subsets of it's operations. If you think that is

the

Quoted 3 lines

case
then please submit a patch to the list and we can discuss that.

Quoted 8 lines

Quoted 3 lines

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

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

+auth_login_pgm_domain(sulogin_t)
+kernel_read_crypto_sysctls(sulogin_t)
+selinux_set_generic_booleans(sulogin_t)

What usage need this access?

Quoted 6 lines · Christian G?ttsche

auth_read_shadow(sulogin_t)

(quoted diff) +3 -0

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

Quoted 7 lines

Quoted 5 lines

(quoted diff) +3 -0

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

Quoted 7 lines

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