What are "security implications" of FTP chroot jails? - Security

This is a discussion on What are "security implications" of FTP chroot jails? - Security ; I did a little reading on chroot() jails and vsftpd support for same, and came up with a bit of a puzzle... The vsftpd man page says: "chroot_local_user - If set to YES, local users will be (by default) placed ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: What are "security implications" of FTP chroot jails?

  1. What are "security implications" of FTP chroot jails?


    I did a little reading on chroot() jails and vsftpd support for same, and
    came up with a bit of a puzzle...

    The vsftpd man page says:

    "chroot_local_user - If set to YES, local users will be (by default)
    placed in a chroot() jail in their home directory after login. Warning:
    This option has security implications, especially if the users have upload
    permission, or shell access. Only enable if you know what you are doing.
    Note that these security implications are not vsftpd specific. They apply
    to all FTP daemons which offer to put local users in chroot() jails."

    I looked around and could not find what the "security implications" are.

    Can anyone tell me what I should look out for in placing people in chroot
    jails?

    Thanks...


  2. Re: What are "security implications" of FTP chroot jails?

    On Sun, 29 Oct 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , C. J. Clegg wrote:

    >This option has security implications, especially if the users have upload
    >permission, or shell access. Only enable if you know what you are doing.


    >I looked around and could not find what the "security implications" are.


    A 'chroot() jail' is only as secure as the lack of skills of the chroot'ed
    user. There are a number of _relatively_ simple mechanisms to break out of
    jail - and this becomes easier when they have the ability to grab software
    from "outside". They need only to obtain 'root' access through some local
    exploit and they're out.

    >Can anyone tell me what I should look out for in placing people in chroot
    >jails?


    Do you trust the individuals? (If not, why are they granted access?)
    Is your system updated such that root exploits are going to be Day Zero
    type exploits? The later means you have to stay on top of the system,
    patching problems as soon as they are known.

    Old guy

  3. Re: What are "security implications" of FTP chroot jails?

    On Mon, 30 Oct 2006 14:22:06 -0600, Moe Trin wrote:

    > Do you trust the individuals? (If not, why are they granted access?)


    The users are either employees or customers. No one else is supposed to
    get access EXCEPT via HTTP since we have a public-access website running
    on that machine.

    Do I trust them not to be malicious? Sure.

    Do I trust them not to do something stupid out of ignorance? Uh.. not
    really.

    > Is your system updated such that root exploits are going to be Day Zero
    > type exploits? The later means you have to stay on top of the system,
    > patching problems as soon as they are known.


    And, therein lies the problem. I cannot do that on this machine, at least
    not right now. It is what it is, we're stuck with FC2, and there is
    nothing we can do about it for the near or mid-term future.

    Believe me I have fought this fight and it's not a fight that can be won
    any time soon.

    One thing... you mention that it's relatively simple to break out of jail.
    The only access that non-trusted users have is HTTP and FTP, and the FTP
    users are chroot'd. No telnet for anybody, and no ssh for anyone but
    employees, all of whom are trusted, and all of whom need to access via
    more-or-less-trusted networks.

    Still a problem?


  4. Re: What are "security implications" of FTP chroot jails?

    On Mon, 2006-10-30 at 14:22 -0600, Moe Trin wrote:

    > A 'chroot() jail' is only as secure as the lack of skills of the chroot'ed
    > user. There are a number of _relatively_ simple mechanisms to break out of
    > jail - and this becomes easier when they have the ability to grab software
    > from "outside". They need only to obtain 'root' access through some local
    > exploit and they're out.


    FUD.

    Moe, he is talking about *FTP* Jail/Chroot environment.

    I would love if you can demonstrate or reference how to escape
    ftp-jail-chroot in vsftpd.

    Thank you for your future enlightenment.


  5. Re: What are "security implications" of FTP chroot jails?

    On Mon, 30 Oct 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , C. J. Clegg wrote:

    >Moe Trin wrote:


    >> Do you trust the individuals? (If not, why are they granted access?)


    >Do I trust them not to be malicious? Sure.
    >
    >Do I trust them not to do something stupid out of ignorance? Uh.. not
    >really.


    Witty sayings abound - generally translating to

    Do not attribute to malice that which can be explained by blatant stupidity.

    or

    "Sufficiently advanced incompetence is indistinguishable from malice."`

    and

    The number one computer bug is mankind!

    There's two lines of thinking for this. Permissions, especially the ACL
    functions that are part of Security Enhanced Linux (SELinux - components of
    which have been part of Red Hat since NSA started playing with it in 2000 -
    look for selinux-doc on your distribution CD) can handle this with ease.
    The problem is that it becomes a _severe_ pain in the donkey to use. But
    it, and even a chroot() jail may be overkill for stupidity (or, it may not
    be enough - depends).

    >> Is your system updated such that root exploits are going to be Day Zero
    >> type exploits? The later means you have to stay on top of the system,
    >> patching problems as soon as they are known.

    >
    >And, therein lies the problem. I cannot do that on this machine, at least
    >not right now. It is what it is, we're stuck with FC2, and there is
    >nothing we can do about it for the near or mid-term future.


    That's your bigger problem. Everyone is aware of the problem, but you're
    the one who has to live with it. 'nuff said.

    >One thing... you mention that it's relatively simple to break out of jail.


    Yes - if you think about what you are doing.

    > The only access that non-trusted users have is HTTP and FTP, and the FTP
    > users are chroot'd. No telnet for anybody, and no ssh for anyone but
    > employees, all of whom are trusted, and all of whom need to access via
    > more-or-less-trusted networks.


    Some one throws your ??? in jail. But unlike a real jail, you can bring in
    anything you want, and nobody is watching you. How long are you going to be
    staying there? Minutes? Seconds? If people are _prevented_ from bringing
    in anything they want (read "ftp access" or equal) then it will be much more
    difficult - though still not impossible.

    >Still a problem?


    Depends - but probably yes.

    Old guy

  6. Re: What are "security implications" of FTP chroot jails?

    On Tue, 31 Oct 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1162320026.2277.40.camel@start.domain.com>, Johny be Good wrote:

    >Moe Trin wrote:
    >
    >> A 'chroot() jail' is only as secure as the lack of skills of the chroot'ed
    >> user. There are a number of _relatively_ simple mechanisms to break out of
    >> jail - and this becomes easier when they have the ability to grab software
    >> from "outside". They need only to obtain 'root' access through some local
    >> exploit and they're out.

    >
    >FUD.
    >
    >Moe, he is talking about *FTP* Jail/Chroot environment.


    I'm glad to hear that you are sure it's impossible. Please note that FTP
    is not the only access that the O/P is granting.

    >I would love if you can demonstrate or reference how to escape
    >ftp-jail-chroot in vsftpd.


    With FTP access _alone_ on a properly configured system, I'll agree it is
    not an easy task. But there are two assumptions - FTP only, and properly
    configured. If either is not true, then vsftpd (or any other single
    application) does not control everything, especially when the sole purpose
    of having FTP access is to upload files for use elsewhere on the system.

    >Thank you for your future enlightenment.


    The world does not exist in splendid isolation. Look at the rest of the
    picture.

    Old guy

  7. Re: What are "security implications" of FTP chroot jails?

    On Tue, 31 Oct 2006 19:25:34 -0600, Moe Trin wrote:

    > I'm glad to hear that you are sure it's impossible. Please note that FTP
    > is not the only access that the O/P is granting.


    FTP and HTTP are the only access granted to untrusted users. HTTP is the
    only access granted to the world. chroot'd FTP is granted to customers
    and employees. We trust the latter, not necessarily the former.

    Everything else is shut down including telnet / rlogin / rsh / rexec / etc.



  8. Re: What are "security implications" of FTP chroot jails?

    On Wed, 01 Nov 2006 00:50:56 -0500, C. J. Clegg wrote:

    > Everything else is shut down including telnet / rlogin / rsh / rexec / etc.


    What I meant to say was that everything else is shut down to untrusted
    users. SSH including SFTP is available to (trusted) employees.
    Everything else including telnet/rlogin/etc. is shut down to everybody.

    That raises another question for which I'll start a new thread.


+ Reply to Thread