This is also happening on Fedora 24, and now in the Cockpit integration tests. 

Mirek, do you know how can we find out what is accessing /proc/net/unix. I cannot find a reference like this in the cockpit code.

*** Bug 1319934 has been marked as a duplicate of this bug. ***

It comes from ssh-transport-c. It seems to be reasonable to allow it.

The question I have is 'ssh-transport-c'? And why should it read the /proc/net/unix file? 

I see nothing with the name ssh-transport-c in the file system. The /proc/net/unix file contains a list of all open unix socket connections. 

So how do I figure out what in the world is ssh-transport-c is doing in that file? I don't feel comfortable opening this without knowing what it is and why it's doing that.

Autarch, 
Could you reproduce this issue?

Stef,
We can dontaudit this rule, if we don't figure out whats happening here.

Jakub, 
Any hint with "ssh-transport-c" ? 

Thank you.

Lukas, using 'git grep ssh-transport-c' on the Cockpit source code produces this line:

src/ws/cockpitsshtransport.c:  self->connect_thread = g_thread_new ("ssh-transport-connect",

Is that related? It seems to be a different string, but perhaps the audit message is truncated?

Hi Mirek. Do you know how I could get a backtrace from the position in the cockpit-ws code (and libraries) that is triggering this issue? Simply looking for /proc/net in code doesn't turn up anything.

(In reply to Stef Walter from comment #6)
> Lukas, using 'git grep ssh-transport-c' on the Cockpit source code produces
> this line:
> 
> src/ws/cockpitsshtransport.c:  self->connect_thread = g_thread_new
> ("ssh-transport-connect",
> 
> Is that related? It seems to be a different string, but perhaps the audit
> message is truncated?


It seems to be related. The field comm="ssh-transport-c" comes from kernel's task->comm which is generally truncated  to 16 characters.

If this is reproducible, it could help to turn auditd full auditing on so that audit will log PATH , SYSCALL and other useful parts of audit event together with an AVC denial message:

# auditctl -w /etc/shadow -p w

When you have a SYSCALL and PATH, systemtap could help you to find the position which triggers the AVC denial.


It looks like something tries to list opened UNIX sockets of the current process, maybe libssh.

Thanks for the help. But I hate that I had to be the one to do this. Shows that it's a rare thing to run tests with SELinux enabled, and paying attention to the audit logs. We do that in Cockpit integration tests.

The access to /proc/net/unix is in glibc and from __opensock().

 0x7fab87f83027 : access+0x7/0x30 [/usr/lib64/libc-2.23.so]
 0x7fab87f94210 : __opensock+0x120/0x1d0 [/usr/lib64/libc-2.23.so]
 0x7fab87fadef0 : if_nametoindex+0x10/0x90 [/usr/lib64/libc-2.23.so]
 0x7fab87fb3964 : __res_vinit+0xb54/0xb70 [/usr/lib64/libc-2.23.so]
 0x7fab87f77bed : gaih_inet+0xc0d/0x2410 [/usr/lib64/libc-2.23.so]
 0x7fab87f7afdb : getaddrinfo+0xfb/0xc60 [/usr/lib64/libc-2.23.so]
 0x7fab88ff26fa : getai+0x8a/0xf0 [/usr/lib64/libssh.so.4.4.1]
 0x7fab88ff2ccb : ssh_connect_host_nonblocking+0x2b/0x2c0 [/usr/lib64/libssh.so.4.4.1]
 0x7fab89007920 : ssh_socket_connect+0x20/0x90 [/usr/lib64/libssh.so.4.4.1]
 0x7fab88ff1c62 : ssh_connect+0x382/0x3a0 [/usr/lib64/libssh.so.4.4.1]
 0x559814cd5e7a : cockpit_ssh_connect_thread+0x1a/0xc00 [/usr/libexec/cockpit-ws]

The code is in sysdeps/unix/sysv/linux/opensock.c:

	  if (__access (fname, R_OK) == -1)

This is just to check if the file exists or not. However it results in an audit log to try and read the file:

cockpit-ws[19968] audit(1467886786.676:670): avc:  denied  { read } for  pid=19968 comm="cockpit-ws" name="unix" dev="proc" ino=4026532021 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file permissive=0


So there are several bugs here:

 1. access() should not result in denied { read }. There should be a way
    to whitelist access(), while not permitting read. For reference the glibc
    code to __access() is a simple:

    return INLINE_SYSCALL (faccessat, 3, AT_FDCWD, file, type);

 2. SELinux should not block access() calls to /proc/net/unix by default
    given that this can/will happen to many proccesses.

 3. The SELinux policy for cockpit should hide failures to access()
    /proc/net/unix for cockpit-ws.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.