Comment 6 for bug 1219857

Hi Chris,

I couldn't find any other details on how to submit contributions to
vsftpd, nor a public VCS or bugtracker or anything. Is emailing you
directly appropriate?

In Ubuntu, it seems that seccomp support never worked since vsftpd 3.0.2
landed in 13.10, and now in 14.04 LTS also. I tracked this down to
gettimeofday() not being permitted, which is used in the logging code.

Our bug is https://launchpad.net/bugs/1219857.

This trivial patch fixes the issue:

--- a/seccompsandbox.c
+++ b/seccompsandbox.c
@@ -300,6 +300,7 @@
   reject_nr(__NR_mremap, ENOSYS);

   /* Misc simple low-risk calls. */
+ allow_nr(__NR_gettimeofday); /* Used by logging */
   allow_nr(__NR_rt_sigreturn); /* Used to handle SIGPIPE. */
   allow_nr(__NR_restart_syscall);
   allow_nr(__NR_close);

Is there any reason that I shouldn't apply this to Ubuntu straight away?
It seems to me that this is a harmless call that shouldn't be a problem
to enable in the seccomp sandbox?

I also noticed that if syslog is enabled (syslog_enable=YES), then
seccomp also fails on a socket() call. Socket communication is perhaps
something that should not be permitted in the sandbox, so I've not gone
further on this, especially as it's non-default on Ubuntu anyway.

Would you consider these two bugs in vsftpd 3.0.2?

On a related note, various distributions (at least Debian, Ubuntu and
SUSE) are carrying another patch:
http://sources.debian.net/src/vsftpd/3.0.2-14/debian/patches/0015-disable-clone-newpid.patch.
I'm not sure if you are aware of this. All of Debian's patches are here
if you're interested:
http://sources.debian.net/src/vsftpd/3.0.2-14/debian/patches

Thanks,

Robie