From: russell@coker.com.au (Russell Coker) Date: Fri, 3 Mar 2017 22:05:06 +1100 Subject: [refpolicy] getty sys_admin access In-Reply-To: References: <201703031316.57473.russell@coker.com.au> Message-ID: <201703032205.06482.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Fri, 3 Mar 2017 09:40:47 PM cgzones via refpolicy wrote: > There were some discussions already at > http://oss.tresys.com/pipermail/refpolicy/2016-December/008831.html > and http://oss.tresys.com/pipermail/refpolicy/2016-November/008598.html. > I am getting these audits: Thanks for those references. I've been starting to catch up on list mail, and in addition I have been repeatedly unsubscribed and probably missed some of the messages. The latter of the 2 URLs you cited says: # So, my opinion is that it is much better to remove the sys_admin # capability permission from the getty module too, because it is # dangerous and it does not provide any practical benefit. # # Also, other versions of getty such as mingetty (commonly used on # virtual terminals) do not require the permission. FWIW I had a dontaudit rule in my policy for ages for this, it's only recently that I noticed that upstream had an allow rule. As an aside is there an easy way to get a list of allow rules and dontaudit rules that cover the same things? While there are some legitimate uses for this (EG dontaudit for an attribute and allow for one type that the attribute covers) there are others that are obviously wrong (EG self rules). https://lists.freedesktop.org/archives/plymouth/2009-March/000064.html Some Googling turned up the above URL about plymouth using that IOCTL to stop the term being "abused". Is there a security benefit in locking the terminal to prevent "abuse"? While granting sys_admin is an obvious security issue, getty has enough access that someone who exploits it can totally own the system anyway. Unless we are going to restrict which roles getty/login can launch a process in and require newrole for a sysadm_r/unconfined_r session at the console it's probably not worth trying too hard to restrict getty_t access. Maybe it would be good to have a wiki listing such access in the reference policy and giving reasons for each one. I am happy to contribute to such a wiki if it's considered a good idea. > type=PROCTITLE msg=audit(02/17/17 23:51:57.729:42) : > proctitle=/sbin/agetty --noclear tty1 linux > type=SYSCALL msg=audit(02/17/17 23:51:57.729:42) : arch=armeb > syscall=ioctl per=PER_LINUX_32BIT success=no exit=EPERM(Operation not > permitted) a0=0x0 a1=0x5457 a2=0x7e8bf69c a3=0x7e8bf6d8 items=0 ppid=1 > pid=524 auid=unset uid=root gid=root euid=root suid=root fsuid=root > egid=root sgid=root fsgid=root tty=tty1 ses=unset comm=agetty > exe=/sbin/agetty subj=system_u:system_r:getty_t:s0 key=(null) > type=AVC msg=audit(02/17/17 23:51:57.729:42) : avc: denied { sys_admin > } for pid=524 comm=agetty capability=sys_admin > scontext=system_u:system_r:getty_t:s0 > tcontext=system_u:system_r:getty_t:s0 tclass=capability permissive=0 > > which seems to be ioctl(stdin, TIOCSLCKTRMIOS) > > 2017-03-03 3:16 GMT+01:00 Russell Coker via refpolicy > > : > > Why does getty_t need the sys_admin capability? From looking at > > capability.h the only listed use of that capability that seems plausible > > is "setting up serial ports". Does getty fail on serial devices if it > > doesn't have sys_admin? > > > > -- > > 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 > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/