[refpolicy] getty sys_admin access

[refpolicy] getty sys_admin access

[Russell Coker]

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] getty sys_admin access

[cgzones]

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
<refpolicy@oss.tresys.com>:
> 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] getty sys_admin access

[Russell Coker]

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
> 
> <refpolicy@oss.tresys.com>:
> > 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/

[refpolicy] getty sys_admin access

[Chris PeBenito]

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
>>
>> <refpolicy@oss.tresys.com>:
>>> 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