You probably need to run ldconfig. See "man ldconfig" for details, as
I gather from the rest of your message that this has to do with trying
to run an application under a chroot environment.
[color=blue]
> I don't want to run the apl. from partition/installation B, and
> I don't understand exectly how 'chroot' works when I use it to
> run other apls. which are on other partitions.[/color]

If you want to use chroot, it might be worth your while to understand
how it works. It takes some reading (see in particular "man 2 chroot"
followed by "man 1 chroot"), but I think that once you understand how it
works, you'll have the answer to your problem.
[color=blue]
> Q - does chroot merely replace the dir tree ?[/color]

Chroot changes a process' view of its "root" directory, thus the name,
from "change root".
[color=blue]
> and what about the environment variables which expect files;
> do that just hope to find the files in the corresponding
> position on the new-dir-tree ?[/color]

Everything that the application "sees" and tries to (and can) access is
relative to the new root directory. This is why running some
applications under a chroot is even desirable.
[color=blue]
> Q - is it possible to mount partn-A, after chroot from A to B,
> to get access to files in the 'original' partition ?[/color]

See "man mount", and look for the "bind" option. That should help with
this.

Sylvain Robitaille wrote:
[color=blue]
> Everything that the application "sees" and tries to (and can) access is
> relative to the new root directory. This is why running some
> applications under a chroot is even desirable.[/color]

Hmm, when I looked into chroot there were dire warnings that great care was
needed as it was not designed as a security tool and if you got it wrong
you would make things worse as the chroot jailed user could escalate their
priviedges to root level.

I shied away at that point.

Pete

--
[url]http://www.petezilla.co.uk[/url]

08-21-2008, 03:05 AM

unix

Re: ldd with chroot ?

Peter Chant wrote:
[color=blue]
> Hmm, when I looked into chroot there were dire warnings that great
> care was needed as it was not designed as a security tool and if you
> got it wrong you would make things worse as the chroot jailed user
> could escalate their priviedges to root level.[/color]

If you read a warning that chmod was not designed as a security tool
and if you got it wrong you would make things worse as an unprivileged
user could escalate their privileges to root level, would you avoid
using chmod? The warning (about chmod, at least) is true. There are
numerous ways you can get that wrong, and leave your system open to
privilege escalation, but I bet you use chmod regularly.

As for chroot, I'm sure that warning is also true, but the reaction
should be the same as with chmod: learn how it works. An intruder can
escalate privileges on a poorly configured system (ie. one where the
sysadmin "got it wrong") that makes no use of chroot, so avoiding the
use of chroot on that account doesn't help, does it?

The point is not to perceive the chroot environment as inherently any more
"secure" than the rest of the system. It's only as secure as you make
it, and the application running within it. If the application is weak,
and the chroot environment is full of security holes, then the system
will certainly be compromised, but that would be just as true without
the chroot environment anyway.

If you have an application that is visible to the world at large
(or to any set including untrusted users) there is a non-zero chance
that some subset of those using your application will attempt to break
through it and acquire access to the system. Would you prefer at that
point that they have access to the complete system, including the many
possible ways that they might potentially elevate privileges, or would
you prefer that they are able to access only a subset of the system that
provides a controlled minimal set of functionality that is required by
the application (in other words, be able to do nothing more than the
application itself could do).
[color=blue]
> I shied away at that point.[/color]

I consider two scenarios as prime candidates for a chroot environment:

- you're deploying a service, such as (but not limitted to) a web
service, that will be accessed from unknown or untrusted sources (such
as the public Internet).

- you're deploying software that you don't trust for some reason
(closed-source, unknown or untrusted programmers, known poor
programming) to perform only as intended.

There are of course plenty of situations where both those scenarios apply,
and probably additional scenarios that would be just as good candidates,
that I'm not thinking of at the moment.

If you're going to "shy away" from anything, wouldn't it be better to
shy away from potentially letting an intruder have immediate access to
your complete system? Using a chroot environment is a tool towards
that. It's by no means the only tool that should be used, but it's
certainly not one that should be avoided either.

I'll give you some simple examples, using a web server because that's a
common service that a lot of people deploy and understand, and that
likely is accessible from the public Internet:

- a web server typically does not create content, but rather serves it
up. Thus the web server runs as an unprivileged user that is unable
to write to any files, except perhaps a small number of log files
(perhaps even log files with an "append-only" attribute, so they can't
easily be deleted). That might not seem like the chroot environment
is particularly helpful, but it certainly is if there is no chattr
command, or any command that would permit the intruding user to
acquire a different userid within the chroot.

- a web server typically does not need to run any suid-root programs
(there are exceptions to this, for example if a web service provider
wants to permit its users to use CGI programs on their web sites,
it might use cgiwrap to force the web server to run those programs as
the userid of the owner, but the point stands, in the general case).
The chroot environment, then, should not contain any setuid-root
programs, eliminating one common mechanism used to elevate privileges.

- a web server typically does not need access to users' passwords, so
it has no access to them. In the days before shadow-passwords, we
used to provide a copy of the /etc/password file, where the passwords
had been sanitized out, in the chroot environment of a web server that
provided web sites for our user community (thus the web server needed
to be able to access a list of users and their "home" directories).
Now, you simply don't put the shadow file within the chroot environment.

You should be starting to understand that with a chroot environment that
doesn't provide more functionality than is required by the application,
the potential intruder's options are quite limited. Can the "www"
user run the "sudo" command (for example)? Maybe outside of the chroot
(although I can't think of any reason why anyone would permit that on
purpose), but if there's no "sudo" command inside the chroot space,
that's not available to an intruder (one coming in through a chrooted
application, that is).