How much can chrooted programs interact with non-chrooted ones?

Discussion in 'all things UNIX' started by Gullible Jones, Sep 20, 2012.

Thread Status:
Not open for further replies.
  1. Say I'm running some program as my limited user in a normal chroot sandbox, and it gets compromised.

    From what I know about chroot, I'm not entirely certain, but I believe the chrooted program can use kill to send signals to programs running as the same user outside the chroot.

    How difficult would it be for the compromised program to inject code into a program running outside the chroot, as the same (limited) user? If it's not too difficult, could it be mitigated depending on the chroot setup, e.g. by somehow restricting access to /proc?
     
  2. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,215
    You are building scenarios that may be improbably and then try to rationalize from there. You should start with how/when/why something gets compromized, and then you can move on to everything else. Otherwise, your question has no meaning. Compromised, as in kernel? Then, everything is visible. Etc.
    Mrk
     
  3. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    He said a compromised program. The question seems very straightforward.

    edit: Couldn't write more on my phone.

    As far as I know IPC is not restricted and a Chroot can see nonChroot'd processes. You can't just inject a shared library into the other process though - I doubt it at least.

    Grsecurity restricts access to outside processes among other things - it doesn't stop it, it just controls what can be done. Being able to communicate between a chroot'd and unconfined process is important.

    And a Chroot process can still only see the files within the Chroot'd directories. That's really the main goal of a Chroot.
     
    Last edited: Sep 21, 2012
  4. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,215
    Not straightforward at all.
    What is a compromised program?
    Something with its own syscalls?
    Something with a driver?
    Mrk
     
  5. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Its own syscalls?

    edit: Anyways, moving beyond Syscalls being provided by the kernel. Usermode device drivers don't change anything.

    A compromised program would be one in which an attacker has gained control over the program ie: shell within that programs address space.

    Seems straightforward. Naturally if the attacker gets kernel level they can do anything, they just have to leave the chroot first. But regardless of the program (hacked or not) the restrictions of a chroot are the same.
     
    Last edited: Sep 21, 2012
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.