What are "security implications" of FTP chroot jails?
C. J. Clegg
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...
Moe Trin
<pan.2006.10.30....@nospam.no>, 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
C. J. Clegg
> 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?
Johny be Good
> 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.
Moe Trin
<pan.2006.10.31....@nospam.no>, 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
Moe Trin
<1162320026.2...@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
C. J. Clegg
> 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.
C. J. Clegg
> 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.