Messages in this thread |  | | Date | Wed, 18 Jan 2012 13:13:02 -0800 | | Subject | Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF] | | From | Chris Evans <> |
| |
On Wed, Jan 18, 2012 at 4:12 AM, Indan Zupancic <indan@nul.nu> 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 > >
|  |