On Wed, Jan 18, 2012 at 4:12 AM, Indan Zupancic <indan@xxxxxx> wrote: > On Wed, January 18, 2012 06:43, Chris Evans wrote: >>> As far as I know, we fixed all races except symlink races caused by malicious >>> code outside the jail. >> >> Are you sure? I've remembered possibly the worst one I encountered, >> since my previous e-mail to Jamie: >> >> 1) Tracee is compromised; executes fork() which is syscall that isn't allowed > > How do you mean compromised? Tracees aren't trusted by definition. And fork is > allowed in our jail, we're ptracing all tasks within the jail. Right, the tracee isn't trusted because you're worried it _might_ get compromised. If it _does_ get compromised, you don't want it playing various tricks to break our of the ptrace() sandbox. > >> 2) Tracee traps >> 2b) Tracee could take a SIGKILL here >> 3) Tracer looks at registers; bad syscall >> 3b) Or tracee could take a SIGKILL here >> 4) The only way to stop the bad syscall from executing is to rewrite >> orig_eax (PTRACE_CONT + SIGKILL only kills the process after the >> syscall has finished) > > Yes, we rewrite it to -1. > >> 5) Disaster: the tracee took a SIGKILL so any attempt to address it by >> pid (such as PTRACE_SETREGS) fails. > > I assume that if a task can execute system calls and we get ptrace events > for that, that we can do other ptrace operations too. Are you saying that > the kernel has this ptrace gap between SIGKILL and task exit where ptrace > doesn't work but the task continues executing system calls? That would be > a huge bug, but it seems very unlikely too, as the task is stopped and > shouldn't be able to disappear till it is continued by the tracer. > > I mean, really? That would be stupid. > > If true we have to work around it by disallowing SIGKILL and just sending > them ourselves within the jail. Meh. > >> 6) Syscall fork() executes; possible unsupervised process now running >> since the tracer wasn't expecting the fork() to be allowed. > > We use PTRACE_O_TRACEFORK (or replace it with clone and set CLONE_PTRACE > for 2.4 kernels. Yes, I check for CLONE_UNTRACED in clone calls.) > >> >> All this ptrace() security headache is why vsftpd is waiting for >> Will's seccomp enhancements to hit the kernel. Then they will be used >> pronto. > > How will you avoid file path races with BPF? There is typically no need for file-path based access control in an FTP server. Take for example anonymous FTP, which will typically be inside a chroot() to /var/ftp. Inside that filesystem tree -- if you can open() it, you can have it. Cheers Chris > > Greetings, > > Indan > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
