[...]
> you are in a chroot, the libraries will be taken from there. I can
> image large problems, when a RH7.3 library will be loaded into a FC2
> application.
I don't understand the statement above. How will you manage to load
a RH7.3 *library* in an FC2 *application*? The only thing using
the rpm environment is Lua itself. If you start an application it'll
be using the environment from the chroot.
> When the crash happens within the main-rpm process (no forking), I can
> imagine database corruptions. Within a separately forked script-process,
> the damage can be limited more easily ("disconnect" database before
> doing anything).
If rpm has bugs and is segfaulting, nothing is separating it from
itself. One of our tasks is preventing this, by fixing bugs in the
provided functionality. OTOH, if you're afraid that someone will
try to break RPM intentionally, that's something hard to prevent.
I can easily break rpm with a hacked database, for example.
[...]
> The linux-vserver concept is, that there are untrusted virtual hosts;
> their processes are isolated and there are some tricks to make the
> chroot secure (special flags in filesystem, or Linux namespaces in
> development branch). It is similarly to UML and BSD jails but much more
> lighweighted and powerful.
You seem to be using a heavily hacked environment, with preloaded
execv() on top of rpm and other custom protections. This means, as
I expected, that the standard rpm is not safe for you either.
[...]
> But when there are lua scripts which can be influenced by the chroot
> content, lots of new attack vectors will be opened.
Which ones!? loadlib? os.date? They may easily be locally disabled
or replaced by something you trust. What else?
[...]
> No; I am just not sure if glibc's localtime file-parser is prepared to
> operate in untrusted environments, or if overflows can be caused by
> special content.
Are you sure that rpm itself is prepared to operate on untrusted
environments, and that overflows can't be caused by special content
inside the environment!?
If you have a security demanding environment as you exposed, a much
better option would be protecting rpm execution itself, not just
execv.
[...]
> I am not familiarly with Lua, but I would wonder when there is no API
> for hostname or uid lookup.
Lua is a language developed to be embedded. I'd be surprised
if it included hostname/uid lookup in its standard library.
--
Gustavo Niemeyer
http://niemeyer.net
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
