Messages in this thread |  | | | From | KOSAKI Motohiro <> | | Subject | Re: [PATCH] Added PR_SET_PROCTITLE_AREA option for prctl() | | Date | Mon, 5 Oct 2009 11:24:08 +0900 (JST) |
| |
> 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 :)
Ok, you are right. Plus, I've finished to made generation-counter approach patch :)
-- 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/
|  |