ldd with chroot ? - Slackware

This is a discussion on ldd with chroot ? - Slackware ; I've got an application which needs /lib/ . And /lib/ is in partition/installation B. So when I copied /lib/ from partnB, and more importantly edited the sym-link from to , the run attempt still showed the lib-missing-error. Q - is ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: ldd with chroot ?

  1. ldd with chroot ?

    I've got an application which needs /lib/.

    And /lib/ is in partition/installation B.

    So when I copied /lib/ from partnB, and more importantly
    edited the sym-link from to , the run attempt
    still showed the lib-missing-error.

    Q - is something cached once the is loaded ?

    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.

    Q - does chroot merely replace the dir tree ?
    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 ?

    Q - is it possible to mount partn-A, after chroot from A to B,
    to get access to files in the 'original' partition ?

    == TIA.



  2. Re: ldd with chroot ?

    problems@gmail wrote:

    > Q - is something cached once the is loaded ?


    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.

    > 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.


    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.

    > Q - does chroot merely replace the dir tree ?


    Chroot changes a process' view of its "root" directory, thus the name,
    from "change root".

    > 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 ?


    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.

    > Q - is it possible to mount partn-A, after chroot from A to B,
    > to get access to files in the 'original' partition ?


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

    I hope I've helped ...

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  3. Re: ldd with chroot ?

    Sylvain Robitaille wrote:

    > 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.


    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

    --
    http://www.petezilla.co.uk

  4. Re: ldd with chroot ?

    Peter Chant wrote:

    > 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.


    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).

    > I shied away at that point.


    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).

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

+ Reply to Thread