From: guido@trentalancia.net (Guido Trentalancia) Date: Fri, 21 Apr 2017 17:08:19 +0200 Subject: [refpolicy] [PATCH] login related stuff take 2 In-Reply-To: References: <20170421091025.kwn5wmevhmoyidj3@athena.coker.com.au> <20170421134201.GC2335@julius> <16C6159B-E15B-44E5-AFEC-2FB1FFBA339C@trentalancia.net> <201704220023.24414.russell@coker.com.au> Message-ID: <7F896D2C-880A-4DB0-9956-D43F162C3D1D@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On the 21st of April 2017 16:39:09 CEST, Guido Trentalancia via refpolicy 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 > 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