avc: smartcard token login

[Mr Dash Four]

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