|
Message-ID: <20120225035653.GA5294@openwall.com> Date: Sat, 25 Feb 2012 07:56:53 +0400 From: Solar Designer <solar@...nwall.com> To: kernel-hardening@...ts.openwall.com Cc: Brad Spengler <spender@...ecurity.net> Subject: Re: procfs: infoleaks and DAC permissions On Fri, Feb 24, 2012 at 04:56:13AM +0400, Solar Designer wrote: > 1. The grsecurity patch for 2.6.32.x appears to need the counter > increment introduced into fs/compat.c: compat_do_execve(). It is > currently missing that, so I guess the protection is bypassable on > 64-bit kernels with 32-bit syscall wrappers present (only if the system > also has a suitable 32-bit SUID/SGID/fscaps-enabled binary). Fixed in grsecurity-2.9-2.6.32.57-201202242017.patch. > 2. /proc/<pid>/mem appears to be excluded from this protection - any > special reason why? I expected it to be one of the primary targets of > this protection. OK, my guess is that this is because mem_read() uses struct file, whereas the exec_id field is currently only implemented for seq_file. Instead, grsecurity's mem_read() currently has: + // XXX: temporary workaround + if (!task_dumpable(task) && task == current) { + ret = -EACCES; + goto out; + } > 3. These grsecurity patch revisions actually include a newer revision of > distros_should_sponsor_me_for_doing_their_jobs.patch. Notably, copying > of exec_id has been added to kernel/fork.c: copy_process(). I wonder > why such explicit copying was needed and whether it is possibly a no-op > given that this same function does: > > p = dup_task_struct(current); The explicit copying of exec_id is dropped in grsecurity-2.9-2.6.32.57-201202242017.patch. > I'd appreciate any comments. Got no comments, but the code changes suffice. ;-) I am now getting some of this stuff into the RHEL5'ish kernels that we use on Owl. Thanks, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.