From: guido@trentalancia.net (Guido Trentalancia) Date: Wed, 26 Apr 2017 18:32:05 +0200 Subject: [refpolicy] [PATCH v2] locallogin: fix the sulogin submodule (emergency shell!) In-Reply-To: <201704270220.27679.russell@coker.com.au> References: <1492802281.4493.1.camel@trentalancia.net> <20170426130544.GA3729@julius> <5D3FFC2A-F6BB-4056-AA55-CF89D485F79C@trentalancia.net> <201704270220.27679.russell@coker.com.au> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Russell. Unfortunately, your sulogin patch didn't work, so it was not just a matter of unneeded permissions! You can check by yourself that it was missing critical permissions while granting unneeded ones... Also, I have already stressed out several times that getty should probably run without the sys_admin capability. They didn't want to change it, I am not going to tell that again. Feel free to submit your sys_admin capability patch for getty, sulogin or both. Consider, I have not tested other variations for sulogin, I consider the change of minor importance compared to this patch. I hope this helps. Regards, Guido On the 26th of April 2017 18:20:27 CEST, Russell Coker wrote: >On Thu, 27 Apr 2017 01:42:31 AM Guido Trentalancia via refpolicy wrote: >> >> @@ -215,7 +215,8 @@ optional_policy(` >> >> >> >> # Sulogin local policy >> >> # >> >> >> >> -allow sulogin_t self:capability dac_override; >> >> +allow sulogin_t self:capability { dac_override sys_admin >> > >> >sys_tty_config }; >> > >> >I suspect that cap_sys_admin can be safely dontaudited >> >> Yes, I thought the same, but then considering it is a sysadmin shell, >I did >> not even check. >> >> Also, remember we probably still have sys_admin for getty which runs >> unprivileged shells... > >http://oss.tresys.com/pipermail/refpolicy/2016-March/007901.html > >Above is the list discussion from last time this came up. If you can >get >sulogin to operate correctly without sys_admin then the next thing to >do would >be to try and get getty to do the same. As you note getty runs >unprivileged >shells, but also it tends to be run from les secure devices such as >serial >consoles, modems, etc that sulogin will never be run from. > >I'm a little surprised at your "considering it is a sysadmin shell" >argument >given that the reason you started working on sulogin policy is that you > >believed that I was giving it excess permissions. Previously you >didn't >accept my argument that sulogin is permitted to run "bash -c setsebool" >etc.