[SSSD] cwrap test roadblock

Jakub Hrozek jhrozek at redhat.com
Fri Nov 28 09:43:32 UTC 2014


On Fri, Nov 28, 2014 at 12:00:21AM +0200, Nikolai Kondrashov wrote:
> Thank you, Simo.
> 
> First of all a disclaimer: I have very little knowledge of libnss_sss
> communication with sssd so my judgement is based on a sort of fog.

Does this help?
https://fedorahosted.org/sssd/wiki/InternalsDocs#a3.3.1.1.SSSClientLibrary

If not, we need to improve the document :-)

> 
> On 11/27/2014 04:25 PM, Simo Sorce wrote:
> >On Thu, 27 Nov 2014 15:09:32 +0200
> >Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
> >>While trying to arrange running sssd under cwrap in "make check" I
> >>came upon this roadblock:
> >>
> >>There doesn't seem to be a way to make libnsss_sss use server sockets
> >>in non-default location at runtime, only at build time. And it seems
> >>that doing it at runtime would be a security issue.
> >
> >Why would it be a security issue ?
> 
> I was primarily thinking about environment variables, which I thought would
> make it possible to change the libnss_sss responses completely with an
> environment variable pointing to a different socket. And environment variables
> are sometimes difficult to track and can come from various places.
> 
> >>That means that we can't include tests involving libnss_sss into
> >>"make check", as that is not guaranteed to be invoked on a build with
> >>a special location where the current user can write to.
> >
> >We can use environment variables to find the socket as long as use
> >secure_getenv() (which means they will not work when running as a
> >setuid process, but otherwise will).
> 
> Wouldn't the non-setuid processes be also endangered by the possibility of
> subverting their communication with sssd via environment variables?
> 
> If they would, what if we placed some restriction on the socket
> ownership/permissions?  Wouldn't it make it simpler? OTOH, I'm not sure how
> that would work under cwrap.

So far I like this idea best. Keep in mind that libnss_sss runs in the
context of the application, so unless the application can elevate
privileges (which would be taken care of by using secure_getenv()) then
a malicious user would only be able to redirect applications running as
his own UID to another socket..



More information about the sssd-devel mailing list