From: russell@coker.com.au (Russell Coker) Date: Fri, 21 Apr 2017 22:38:06 +1000 Subject: [refpolicy] [PATCH] login related stuff take 2 In-Reply-To: References: <20170421091025.kwn5wmevhmoyidj3@athena.coker.com.au> Message-ID: <201704212238.06684.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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/