Hi,
Le 12.08.2013 21:05, Jason Gunthorpe a écrit :
On Thu, Aug 08, 2013 at 09:24:16PM +0200, Yann Droneaud wrote:
Loading shared object as part of a setuid binary should be handled
with extra care. Adding checks to the configuration loader is
required so that only trusted shared object get loaded.
Well, still, I'm not sure this is required. IBV_CONFIG_DIR is
hardwired and not overriable (via environment, etc), so it is a simple
installation error to have the wrong permissions for your environment
on these files.
It's an installation error that can allow an attackant to tamper
the configuration files. Once the configuration files are modified
to load a payload, the attackant can either trick root to execute
a verbs/RDMA program or use a verbs/RDMA setuid program to gain root
access.
libibverbs should protect its users from loading arbitrary shared
object/library.
I fixed the code regarding Roland remarks on user's own libibverbs,
so I think there's no more use case were my proposed check would harm.
But I cannot imagine all of them alone, so I need your help to find
some valid use case broken by my proposed checks.
But lots of files need to have the correct permissions for setuid to
be secure (the binary, the library itself, the libraries it dlopens,
the directories that contain all of these things, etc) - not sure it
makes any sense at all to single out the config files for special
checking.
It took a lot of time to fixes those setuid programs and the libraries
used by them. And it still an on-going work.
We don't have to wait for exploit to secure the loading mechanism of
libibverbs.
In any event, if these checks really are necessary they should be only
done if running in a setuid context, and they almost certainly need to
extend to the dlopen paths as well..
They need to be done when the configuration files are owned by a
different user
that the one using the library (eg. running a program tied to the
library).
I put the emphasis on setuid use case, but a program run as root using
configuration file
owned by another user is more likely to happen (for devel, test
purpose).
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
