Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Best practice vsftpd writable root inside chroot()

106 views
Skip to first unread message

Maik Stubbe

unread,
Aug 8, 2013, 4:40:02 AM8/8/13
to
Hi,

I just came accross this new security feature of vsftpd whith which you cannot have your $HOME writable for a chrooted user.

Since this ftp server is a public accessable server with ~60 users and partial nested homedirs, there is no chance that there is no writable homedirectory. Another big point is, the directory structure increased over years. So there is even no possibility to change it and give users an writable directory inside their $HOME.

So what is the best practice to avoid security problems?

1. Using no ftp -> no chance
2. Avoid using chroot is in my opinion a bad idea on a public accessable ftpd.
3. Compiling vsftpd >3.0 from source and using allow_writeable_chroot=YES: This would lead in using non Debian packages and watching them seperatly.
4. Using packages from Jessie: My preffered choice. But how to control security updates?

Any suggestions from your side?


Regards


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013080808...@stubbi.org

Bob Proulx

unread,
Aug 9, 2013, 2:50:02 AM8/9/13
to
Maik Stubbe wrote:
> I just came accross this new security feature of vsftpd whith which
> you cannot have your $HOME writable for a chrooted user.

If the chroot file system is writable then that has the same security
issues as a writable root filesystem. Which is to say it has no
security. Simply write your own /etc/passwd and other files into it
and then you have root on the system.

> Since this ftp server is a public accessable server with ~60 users
> and partial nested homedirs, there is no chance that there is no
> writable homedirectory. Another big point is, the directory
> structure increased over years. So there is even no possibility to
> change it and give users an writable directory inside their $HOME.

Sounds important. Sounds very constrained. If you have no degrees of
freedom then you probably can't do it. :-(

> So what is the best practice to avoid security problems?

Use sftp instead of ftp. Use http for downloading instead of ftp.

> 1. Using no ftp -> no chance

You didn't say but are you using ftp for upload access? Since ftp
sends passwords in the clear it is unsuitable in these days of a
hostile Internet for any purpose other than anonymous downloading.

> 2. Avoid using chroot is in my opinion a bad idea on a public
> accessable ftpd.

But you are already using ftp. Talking about security at that point
is like putting a heavy duty lock on a screen door. No matter how
good the lock it is still a screen door and won't stop anyone who
wants to run through it.

> 3. Compiling vsftpd >3.0 from source and using
> allow_writeable_chroot=YES: This would lead in using non Debian
> packages and watching them seperatly.

Use a Debian watch file. See the 'uscan' program for details. But
you can have it automatically notify you when new versions arrive.

> 4. Using packages from Jessie: My preffered choice. But how to
> control security updates?

Does the Jessie vsftpd allow writable chroots? Sounds like a bug to
be filed to me.

> Any suggestions from your side?

Use sftp upload instead. All operating systems support it in various ways.
Use http download instead. All operating systems easily support it.

Bob
signature.asc

Maik Stubbe

unread,
Aug 9, 2013, 3:30:02 AM8/9/13
to
> > 1. Using no ftp -> no chance
>
> You didn't say but are you using ftp for upload access? Since ftp
> sends passwords in the clear it is unsuitable in these days of a
> hostile Internet for any purpose other than anonymous downloading.
>

I need full access from all clients to their home directory including uploads. I'm aware of the security risks using ftp. But there isn't another option like sftp. ~60 clients with a minimum of knowledge of security risks and technical understanding. It will be a hard and non-profitable way to switch over to sftp or even http.

> > 2. Avoid using chroot is in my opinion a bad idea on a public
> > accessable ftpd.
>
> But you are already using ftp. Talking about security at that point
> is like putting a heavy duty lock on a screen door. No matter how
> good the lock it is still a screen door and won't stop anyone who
> wants to run through it.
>
> > 3. Compiling vsftpd >3.0 from source and using
> > allow_writeable_chroot=YES: This would lead in using non Debian
> > packages and watching them seperatly.
>
> Use a Debian watch file. See the 'uscan' program for details. But
> you can have it automatically notify you when new versions arrive.
>

Sounds interessting. I will have a look...

> > 4. Using packages from Jessie: My preffered choice. But how to
> > control security updates?
>
> Does the Jessie vsftpd allow writable chroots? Sounds like a bug to
> be filed to me.
>

It is a "problem" of vsftpd. They decided to disable ftp with writable $HOME if chroot is enabled [1], [2]. It's a matter of old versions in Debian. Jessie provides the newer version with the new config setting.


Regards



[1]: https://security.appspot.com/vsftpd/Changelog.txt (Version 2.3.5)
[2]: https://security.appspot.com/vsftpd/FAQ.txt (Q3)



--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013080907...@stubbi.org

Bob Proulx

unread,
Aug 9, 2013, 2:30:02 PM8/9/13
to
Maik Stubbe wrote:
> I need full access from all clients to their home directory
> including uploads. I'm aware of the security risks using ftp. But
> there isn't another option like sftp. ~60 clients with a minimum of
> knowledge of security risks and technical understanding. It will be
> a hard and non-profitable way to switch over to sftp or even http.

To be completely blunt with that constraint I don't know why you worry
about proactive security. It is impossible. Sorry.

Instead I would set up intrusion monitoring and try to be reactive.
Hopefully you will be such a small fish that no one will poke at you
and you won't have any problems. But if you do then you can notice
with the intrusion detection and react quickly afterward. That might
be enough for you.

> > > 4. Using packages from Jessie: My preffered choice. But how to
> > > control security updates?
> >
> > Does the Jessie vsftpd allow writable chroots? Sounds like a bug to
> > be filed to me.
>
> It is a "problem" of vsftpd. They decided to disable ftp with
> writable $HOME if chroot is enabled [1], [2].
Good plan! :-) It looks like they did that in 2.3.4.

v2.3.4 - Add stronger checks for the configuration error of running
with a writeable root directory inside a chroot(). This may bite
people who carelessly turned on chroot_local_user but such is life.

Then gave some relief in 2.3.5.

v2.3.5 - Add new config setting "allow_writeable_chroot" to help
people in a bit of a spot with the v2.3.5 defensive change. Only
applies to non-anonymous.

Version 2.3.5 is in Wheezy 7 Stable. If you are running Stable then
you should already have that feature available to you. Are you
running Oldstable Squeeze 6? If so then an upgrade to Stable should
fix you right up.

> It's a matter of old versions in Debian. Jessie provides the newer
> version with the new config setting.

If it is a different feature then you could request a backport from
Testing to Stable.

http://backports.debian.org/

Bob
signature.asc
0 new messages