-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fail check upload files with directive DefaultRoot #12
Comments
Hi, You cannot use A possible fix is to enable TCP-based Clamd and set Best regards, |
Hi @jbenden , very thaks your fastly response Via FTP it was solved by changing from local socket to stream. I compiled the proFTPD with mod_clamav and the modules: mod_sftp and mod_vroot. Via FTP clamav + vroot works normally, but when using sftp the clamav seems to use the relative path from file to make the transfer via stream. The relative path is: "/ my_file" (I'm using the "DefaultRoot ~" directive) and full path is: "/home/.../my_file". So the file supposedly copied via stream has a size of 0 (because no copy efftively) and for that reason it returns to the sftp client: "Couldn't close file: Permission denied". Below the output of proFTPD in debug mode: # ./proftpd -n d10:
I did the test by placing a file in the root of the system with the same name as the file that was being uploaded via sftp and really clamav is considering the relative path of the file to transfer via stream. |
If you increase the debugging, mod_clamav will output a ton of information about how the filename/filepath was translated. This is key to understanding what happened. Additionally, I would need to build a test case for this problem, so I can then fix it. :) |
Relative the mod_clamav it is only these. It doesn't even send a file via stream, but a file with size 0 is created in the temporary folder defined in the clamav settings. Complete debug of the moment of sending the file: *
If I can help with something else, i available. See you |
Hi @jbenden it seems that the problem is with mod_vroot which changes variables when "VRootEngine on". I open issue in mod_vroot. If you want to follow: Castaglia/proftpd-mod_vroot#issue23. Probably the directive VRootEngine changes variables, that are used by mod_clamav Regards. |
Hi @jbenden , I inserted some additional logs in the file mod_clamav.c and this is the result of the transfer via FTP and SFTP. I changed the abs_path variable to the global scope to access it from outside the "clamav_fsio_close" function and include it in the log output. Changing abs_path to global, the problem started via FTP and via SFTP everything works fine (more details in the logs below). Following are the changes made to mod_clamav.c:
I don't know if there is a solution because VRoot directly affects the environment variables. Directories and paths:
The use case isusing mod_sftp + mod_vroot (VRootEngine on) + mod_clamav + directive "DefaultRoot ~" the behavior of mod_clamav is as follows: SFTP upload in home e directories from user::
SFTP upload in symbolic link:
FTP upload in home e directories from user:
FTP upload in symbolic link:
I tried to make a work around but the verification in some of the points still fails. We continued talking, the disposition. proftpd.conf:
proftpd -vv
|
Thank you for all you've looked into! So, we probably need some sort of answer or advice from @Castaglia on this. But, would you re-run tests with logging the output of Thanks, |
Hi Joe, Just check only |
Hello! I was hoping you could add it to the logging performed in the line Thanks! |
Hi benden, sorry delay, I remounted the environment. FTP upload in home e directories from user:
FTP upload in symbolic link:
SFTP upload in home e directories from user:
SFTP upload in symbolic link:
|
Thank you for running the tests, @willyamcts ! Unfortunately, I don't see a solution on my end. To fix this, I'd really need @Castaglia to help and find a workable solution for both his module and any downstream modules. Thanks, |
What I find most interesting, in the provided logs (thank you!), are the |
@Castaglia Well, it's been awhile so I'm a bit rusty on the problems... But yes. Your module does not seem to set all the components of the path properly, thus mine is completely unable to reconstruct an absolute path to the file. |
Hi @jbenden, Castaglia has recently committed a possible fix for this issue. @Castaglia I will test and see the result. Anyway I made a change in mod_clamav.c to work around the mentioned problem, but I understand that there may be problems with future updates. If the Cataglia change doesn't work correctly, I open a pull request with my change for you to evaluate. |
I'm playing with mod_clamav with the current versions of ProFTPd and mod_vroot, and I've found the following: For vrooted DefaultRoot file uploads, the relpath is the correct filesystem path, and the abspath is /abspath - so that the path begins with //... For those files, STREAM scanning works properly, but not SCAN scanning. Here's a bit from the tracelog:
Looking at those logs and mod_clamav.c line 507-525, fsio has the correct path, and both fh_path (abs_path) and buf (getcwd()) are also correct, but since cwd (pr_fs_getcwd()) is not the same as buf (getcwd()), it prepends buf to abs_path to get what it thinks is the non-chrooted abs_path. But since chroot (session.chroot_path) is '/', there's no need to prepend anything. I don't know mod_vroot at all, but I suspect that there needs to be a check to see if session.chroot_path is '/', and if so don't modify abs_path. Let me know if you think this is the correct solution, and I'll test it on my end as I'd really prefer to use SCAN scanning rather than STREAM for speed purposes. |
Addendum: turning vroot engine off results in the following tracelog, and proftpd was unable to connect to the clamd socket (because of the chroot, I'm assuming). So I suspect that a check for session.chroot_path may be the way to go since the pathing here was correct.
|
I patched mod_clamav so that it checks if session.chroot_path is set and not '/' before doing the the check for buf vs pr_fs_getcwd(), and that now works for doing SCAN rather than STREAM scans even with DefaultRoot set. The patch I used is this:
|
The above mentioned patch is now PR #21. |
I'am attempt using mod_clamav via socket file, but occurent errors related a permissions.
In using directive DefaultRoot from jail user in your home (consider your home with root / and he not access / from system), mod_clamav return in /var/log/syslog:
And in client CLI i attempt upload from file eicar by test and he return:
If i remove or comment directive "DefaultRoot ~" mod_clamav worked normally. Below content files and result the commands from help:
############### ###############
# cat /etc/issue
Debian GNU/Linux 6.0 \n \l
# proftpd.conf:
# /usr/local/proftpd/sbin/proftpd -V
The text was updated successfully, but these errors were encountered: