avc: smartcard token login

Sun Dec 5 20:37:11 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/05/2010 09:35 PM, Dominick Grift wrote:
> On 12/05/2010 09:29 PM, Mr Dash Four wrote:
> 
>>> looks like a bug in policy (redhat.bugzilla.com in the selinux-policy
>>> component)
>>>   
>> Looks like it, though I've gone further with this today...
> 
>>> but before you consider that verify that there is no boolean available
>>> that you can toggle to provide this access:
>>>
>>> sesearch --allow -SC -s local_login_t -t openct_var_run_t
>>>
>>> If there is a line that allows local_login_t openct_var_run_t:file read
>>> then see if the line is prefixed with DT or ET (disabled tunable,
>>> enabled tunable respectively)
>>>   
>> There is nothing - I actually looked at locallogin.te/if before posting
>> this, executing the above (and seeing nothing) just reaffirmed what I
>> already knew.
> 
>>> But chances are youve just stumbled upon a bug or you've misconfigured
>>> something.
>>>   
>> OK, I played a bit of a mischief. I did not wait for an answer to this
>> and looked at openct.if  to see if there is something which might help me.
> 
>> The idea was that if I find something I will then create a custom module
>> implementing it (that does not cure the bug though - if it is a bug it
>> needs to be fixed). So I found this in openct.if -
>> "openct_read_pid_files" which looked like it grants the necessary
>> permissions to the specified domain (local_login_t) and prepared a
>> custom module executing "openct_read_pid_files(local_login_t)". That
>> worked on the test harness, but failed to produce the desired result on
>> my other, non-test machine for which I was building this. I am getting 2
>> further AVC types below:
> 
>> type=AVC msg=audit(1291573359.027:5): avc:  denied  { signull } for 
>> pid=1553 comm="login"
>> scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
>> tcontext=system_u:system_r:openct_t:s0-s0:c0.c1023 tclass=process
>> type=SYSCALL msg=audit(1291573359.027:5): arch=40000003 syscall=37
>> success=no exit=-13 a0=624 a1=0 a2=2ad788 a3=0 items=0 ppid=1 pid=1553
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>> tty=tty1 ses=4294967295 comm="login" exe="/bin/login"
>> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
>> type=AVC msg=audit(1291573359.046:6): avc:  denied  { write } for 
>> pid=1553 comm="login" name="0" dev=dm-0 ino=8250
>> scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:openct_var_run_t:s0 tclass=sock_file
>> type=SYSCALL msg=audit(1291573359.046:6): arch=40000003 syscall=102
>> success=no exit=-13 a0=3 a1=bf853ab0 a2=2ad788 a3=89e11e0 items=0 ppid=1
>> pid=1553 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=tty1 ses=4294967295 comm="login" exe="/bin/login"
>> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
> 
>> When I do echo 0 > /selinux/enforce and try again I am getting a 3rd AVC
>> in addition to the ones above:
> 
>> type=AVC msg=audit(1291574143.421:66): avc:  denied  { signull } for 
>> pid=1580 comm="login"
>> scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
>> tcontext=system_u:system_r:openct_t:s0-s0:c0.c1023 tclass=process
>> type=SYSCALL msg=audit(1291574143.421:66): arch=40000003 syscall=37
>> success=yes exit=0 a0=65e a1=0 a2=d97788 a3=0 items=0 ppid=1 pid=1580
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>> tty=tty1 ses=4294967295 comm="login" exe="/bin/login"
>> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
>> type=AVC msg=audit(1291574143.430:67): avc:  denied  { write } for 
>> pid=1580 comm="login" name="0" dev=dm-0 ino=8250
>> scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:openct_var_run_t:s0 tclass=sock_file
>> type=AVC msg=audit(1291574143.430:67): avc:  denied  { connectto } for 

Actually it wants to stream connect as i suspected.

>> pid=1580 comm="login" path="/var/run/openct/0"
>> scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
>> tcontext=system_u:system_r:openct_t:s0-s0:c0.c1023
>> tclass=unix_stream_socket
>> type=SYSCALL msg=audit(1291574143.430:67): arch=40000003 syscall=102
>> success=yes exit=0 a0=3 a1=bfe9fbb0 a2=d97788 a3=92b51e0 items=0 ppid=1
>> pid=1580 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=tty1 ses=4294967295 comm="login" exe="/bin/login"
>> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
> 
>> That stems from the fact that openct opens a socket in /var/run/openct
>> (the socket is called '0' for the first available 'slot' with a token on
>> my smartcard device or has a different number - 1,2,3... if there is a
>> specific token number which needs to be used) and uses it to retrieve
>> the login token for me to login with.
> 
>> So, what I'll do (probably tomorrow when I have the time) is see if
>> there is something else in openct.if which helps with the above problem.
>> In any case I will submit this as a bug though as it needs to be
>> incorporated - at least as a boolean - in the standard policy. Smartcard
>> tokens will be used for login, they may not be widely used now, but that
>> would definitely change in the near future.
> 
> 
> add these two:
> 
> openct_stream_connect(local_login_t)
> 
> # assuming it may also want to stream connect to openct, in either case
> this is the only existing interface that allows access to write
> openct_var_run_t pid sock files.
> 
> openct_signull(local_login_t)
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkz79/cACgkQMlxVo39jgT+H5wCeOrN3VOufc/werc3xM9isbSkn
wGMAnRaxpXgcn2zizYnUgIkoqNx37+Qr
=NRdJ
-----END PGP SIGNATURE-----