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.kondras...@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
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
