niemeyer@xxxxxxxxxxxxx (Gustavo Niemeyer) writes:
>> What happens with the directory-fd's pointing outside chroots? Will
>> bad dynamical loaded libraries kill the entire rpm?
>
> What kind of bad dynamical loaded libraries?
Especially the libnss* ones. E.g. think of a chroot installation of a
RH7.3 system within a Fedora Core 2 host. When a lua script makes
e.g. getpwnam() or a DNS lookup, the NSS libraries will be loaded. When
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.
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).
> The main target is not self-made shared-objects, while it is possible
> with the current implementation. The current main target is allowing
> filesystem operations and other usual operations without the need for
> an external interpreter.
>
> I'm curious. Do you have an environment where you don't trust the
> packagers even though you install the packages made by them?
I do not trust the libraries or datafiles within the chroot...
> Can you describe how it works?
It is used by the util-vserver package; see http://linux-vserver.org/
and http://savannah.nongnu.org/projects/util-vserver/. Please look at
lib/rpm-fake.c in CVS for implementation details (currently down, like
the entire Savannah).
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.
The rpm package-management can happen from the outside; currently there
were only two cases which must be handled:
* getpwnam/getgrnam lookups while cpio
* the execv() of scriptlets
The NSS lookup (which is an issue with "normal" chroot install too), is
solved by a dietlibc linked wrapper executed within the chroot; and the
execv() case by entering the context before doing the real execv().
But when there are lua scripts which can be influenced by the chroot
content, lots of new attack vectors will be opened.
> I'm sure you're not using root, are you? Then, what kind of problems
> might result from running it? I also belive you don't have any
> packages with proc filesystem, devices, etc, right?
This is protected by linux capabilities and there are kernel extensions
which are hiding some /proc entries not covered by capabilities
(e.g. sysrq-trigger, scsi). Every vserver has a minimal /dev filesystem
and new devices can not be created without CAP_MKNOD.
>> operations, will /etc/localtime from host or chrootfilesystem be
>> used?
>
> The Lua API itself will use whatever is loaded in rpm. Do you think
> using in the Lua API the same time as is available to rpm is a
> problem?
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.
>> Or on name-lookups, will the libnss* libraries from host or the chroot
>> be loaded (related to non-fork questions above)?
>
> The Lua API itself does no name-lookups. Can you give me an example
> where this might cause problems for you?
I am not familiarly with Lua, but I would wonder when there is no API
for hostname or uid lookup.
Enrico
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
