Messages in this thread | | | From | Bryan Donlan <> | Date | Sun, 4 Oct 2009 22:21:12 -0400 | Subject | Re: [PATCH] Added PR_SET_PROCTITLE_AREA option for prctl() |
| |
On Sun, Oct 4, 2009 at 9:59 PM, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: >> On Sun, Oct 4, 2009 at 9:38 PM, KOSAKI Motohiro >> <kosaki.motohiro@jp.fujitsu.com> wrote: >> >> The improvement idea is here. >> >> >> >> Changelog >> >> - Added task_lock() to prctl(PR_SET_PROCTITLE_AREA) >> >> - Added small input sanity check to prctl(PR_SET_PROCTITLE_AREA) >> > >> > Doh, task_lock() is obviously wrong. please forget this. >> >> As another note, in general I think we'd need to hold a lock over the >> entire operation. After all, if userspace changes its PROCTITLE_AREA, >> and then reuses the memory for something else, we have an information >> leak. > > if reusing occur, it's obviously userland fault. I don't think we need to care this. > because current kernel also can be information leak by strcpy(argv[0], mypassword). > > I think they are userland bug both.
No, the scenario is:
Process B: Enter proc_pid_cmdline(), read arg_start and arg_end into CPU registers Process A: prctl(PR_SET_PROCTITLE_AREA).... Process A: free(old_arg_area); Process A: char *foo = malloc(...); Process A: strcpy(foo, super_secret_password); Process B: access_process_vm - using an area overlapping foo
Process B now has process A's secrets. This cannot be avoided by process A, as it cannot control when process B will complete proc_pid_cmdline(), and so the kernel must protect against this scenario. The only way a userspace process could prevent this is by only using PR_SET_PROCTITLE_AREA once, and never reusing that memory, ever. This does not seem like an appropriate restriction to pass down to userspace for me...
Anyway, I'm working on a patch that uses the generation-counter approach now :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |