Hi,

You were right, it does not show up in the logs.

And sadly adding the policy below does not work either :-(
#cat my-gssproxy.te
module my-gssproxy 2.0;

require {
        type init_t;
        type gssd_t;
        class process noatsecure;
}

#============= init_t ==============
allow init_t gssd_t:process noatsecure;

Then applied it :
checkmodule -M -m -o my-gssproxy.mod my-gssproxy.te
semodule_package -o my-gssproxy.pp -m my-gssproxy.mod
semodule -i my-gssproxy.pp

It needs more work
I think I'll dig a bit further into this and see if I can come up with something.

Rob



2017-03-31 21:12 GMT+02:00 Simo Sorce <simo@redhat.com>:
On Fri, 2017-03-31 at 20:39 +0200, Rob Verduijn wrote:
> In that case a workaround should not be so difficult :-)
>
> lets fire up ausearch

I do not know if it shouws up in the audit log becauxe this is a
decision made by libc based on the AT_SECURE flag that is set in the
process based on selinux policies.
So technically there isn't a violation happening.

In bz#1174915 there is a similar issue and the solution there was to add
this to the policy:
allow NetworkManager_t openvpn_t:process { noatsecure };

I am not sure what would be the policy in rpc.gssd case, perhaps
something like: allow init_t gssd_t:process { noatsecure }; ?

Simo.

> Rob.
>
> 2017-03-31 19:02 GMT+02:00 Simo Sorce <simo@redhat.com>:
>
> > Good news Rob,
> > apparently it ended up being a SELinux policy issue,
> > see: https://bugzilla.redhat.com/show_bug.cgi?id=1430963
> >
> > Simo.
> >
> > On Tue, 2017-03-28 at 17:44 +0200, Rob Verduijn wrote:
> > > I guess this has low priority for the nfs devs.
> > >
> > > Any workaround for this that does not require creating a service account
> > in
> > > ipa ?
> > >
> > > Rob Verduijn
> > >
> > >
> > > 2017-03-10 12:37 GMT+01:00 Rob Verduijn <rob.verduijn@gmail.com>:
> > >
> > > > Cool...this thing was driving me nuts
> > > >
> > > > Looking forward to the patch.
> > > >
> > > > Rob
> > > >
> > > > 2017-03-10 2:14 GMT+01:00 Robbie Harwood <rharwood@redhat.com>:
> > > >
> > > >> Rob Verduijn <rob.verduijn@gmail.com> writes:
> > > >>
> > > >> > I've tried quite a lot of things (including the very latest version
> > > >> 0.7.0
> > > >> > of gssproxy) but I keep failing to get it to work on fedora25.
> > > >> >
> > > >> > So in a last ditch attempt I created a reproducer in the form of a
> > > >> vagrant
> > > >> > script that creates a test environment that has the problem.
> > > >>
> > > >> Hi Rob,
> > > >>
> > > >> Thanks for the (maximally) detailed reproducer.  I was able to observe
> > > >> the issue on my end.  I observed that GSS_USE_PROXY=yes is indeed set
> > in
> > > >> rpc.gssd's environment.  gssproxy isn't logging anything because it
> > > >> never gets invoked.  rpc.gssd has broken the environment variable
> > which
> > > >> we check using secure_getenv().
> > > >>
> > > >> I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1430963 for
> > this
> > > >> issue.
> > > >>
> > > >> --Robbie
> > > >>
> > > >
> > > >
> > > _______________________________________________
> > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org
> >
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> > _______________________________________________
> > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org
> >
> _______________________________________________
> gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
> To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org


--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org
To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org