avc: smartcard token login

[Dominick Grift]

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

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 
> 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/

iEYEARECAAYFAkz795AACgkQMlxVo39jgT9fKwCeN9Gs4x1erWtefOYstXQexjIc
rnEAnAoChnglw+JCJOFHkMVs6thR49eV
=kETq
-----END PGP SIGNATURE-----