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/
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:
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
<[email protected]>:
> 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
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
>
> <[email protected]>:
> > 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/
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
>>
>> <[email protected]>:
>>> 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