On 11/28/2014 11:43 AM, Jakub Hrozek wrote:
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 :-)
This is very useful, thank you. It was silly of me to not look for such a
document in the first place.
> On 11/27/2014 04:25 PM, Simo Sorce wrote:
>> On Thu, 27 Nov 2014 15:09:32 +0200
>> Nikolai Kondrashov <Nikolai.Kondrashov(a)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.
Do you mean just using environment variables or also restricting socket
permissions?
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..
Yes, but theoretically somebody else might gain control of the environment
variables. I'm not sure how bad that is in practice, though.
Nick