From: pebenito@ieee.org (Chris PeBenito) Date: Sat, 4 Mar 2017 07:27:14 -0500 Subject: [refpolicy] getty sys_admin access In-Reply-To: <201703032205.06482.russell@coker.com.au> References: <201703031316.57473.russell@coker.com.au> <201703032205.06482.russell@coker.com.au> Message-ID: <3836aa3b-f392-7214-5b62-45f4ea203ebc@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 03/03/17 06:05, Russell Coker via refpolicy wrote: > 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 Not that I'm aware of. Patches are welcome for setools, if you'd like to write it. > 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. My opinion is that local login should generally have the possibility of all logins. It's remote ones where it's better not to have direct login to sysadm/unconfined. > 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. I'd prefer comments in the policy instead. Otherwise it's very easy for one to be out of sync with the other. >> 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? -- Chris PeBenito