> 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.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
