Bug 1438036

Simo, 
Do you have any AVCS related to this issue?

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Robbie reproduced the issue, turning to him.

Btw are we really expcting an AVC ?
The way I understand this issue is that SeLinux sets AT_SECURE on the process at startup, and glibc, much later simply fails secure_getenv() when it see AT_SECURE set.
Do you really expect to find AVCs ? Does glibc issue audit logs when secure_getenv() is invoked ?

# seinfo -cprocess -x | grep secure
      noatsecure
#

If you want to see { noatsecure } AVCs, which are usually hidden, you need to disable dontaudit rules via:

# semodule -DB

(In reply to Milos Malik from comment #4)
> # ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

type=AVC msg=audit(04/03/2017 16:27:49.203:1094) : avc:  denied  { noatsecure } for  pid=8377 comm=mount scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:mount_t:s0 tclass=process permissive=0 

This looks relevant (showed after running `semodule -DB`).

Not sure it is, this sounds like autofs simply calling a mount command, not related to the gss_t context which is the one affected by this bug.

You're right, I grabbed the wrong one.  Here are all of them:

type=AVC msg=audit(04/03/2017 17:00:27.684:1174) : avc:  denied  { rlimitinh } for  pid=8643 comm=nfs-utils_env.s scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 
----
type=AVC msg=audit(04/03/2017 17:00:27.684:1175) : avc:  denied  { siginh } for  pid=8643 comm=nfs-utils_env.s scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 
----
type=AVC msg=audit(04/03/2017 17:00:27.684:1176) : avc:  denied  { noatsecure } for  pid=8643 comm=nfs-utils_env.s scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 
----
type=AVC msg=audit(04/03/2017 17:00:27.684:1177) : avc:  denied  { read write } for  pid=1 comm=systemd path=socket:[463910] dev="sockfs" ino=463910 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket permissive=0 
----
type=AVC msg=audit(04/03/2017 17:00:27.689:1180) : avc:  denied  { rlimitinh } for  pid=8646 comm=rpc.gssd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=process permissive=0 
----
type=AVC msg=audit(04/03/2017 17:00:27.689:1181) : avc:  denied  { read write } for  pid=1 comm=systemd path=socket:[463438] dev="sockfs" ino=463438 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket permissive=0 
----
type=AVC msg=audit(04/03/2017 17:00:27.689:1182) : avc:  denied  { noatsecure } for  pid=8646 comm=rpc.gssd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=process permissive=0 

These happen when rpc-gssd is restarted.  (The one earlier for mount happens when I actually try to access the directory in the reproducer.)

With gssd_t, gssproxy_t, and init_t added to permissive, the attached are generated on gssproxy restart.

No messages seem to be triggered on rpc-gssd restart or on the original reproducer.

Created attachment 1268456 [details]
gssproxy avcs

Thanks Robbie,
Lukas, I think the policy needs to enable all of these.

Lukas, can we get this in Fedora too so we can test more easily on our side that the policy indeed covers all the cases now ?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1861