lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DFB7605.9000909@redhat.com>
Date:	Fri, 17 Jun 2011 11:43:01 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Vasiliy Kulikov <segoon@...nwall.com>
CC:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, apparmor@...ts.ubuntu.com,
	"selinux@...ho.nsa.gov Stephen Smalley" <sds@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>,
	John Johansen <john.johansen@...onical.com>,
	kernel-hardening@...ts.openwall.com
Subject: Re: [RFC v1] security: introduce ptrace_task_access_check()

On 06/17/2011 11:29 AM, Vasiliy Kulikov wrote:
> Hi,
>
> This patch introduces ptrace_task_access_check() to be able to check
> whether a specific task (not current) is able to ptrace another task
> (might be current).  I need it to call "reversed" ptrace_may_access()
> with swapped current and target task.
>
> Specifically, I need it to filter taskstats and proc connector requests
> for a restriction of getting other processes' information:
>
> http://permalink.gmane.org/gmane.linux.kernel/1155354
>
>
> Please help me to figure out how such patch should be divided to be
> applied.  I think about such scheme:
>
> 1) add generic security/* functions.
> 2-4) add ptrace_task_access_check() for SMACK, AppArmor and SELinux.
> 5) change ptrace_access_check() in security ops and all LSMs to
>      ptrace_task_access_check().
>
> But I'd like to hear maintainers' oppinions not to put useless efforts.

Not a real review, but I didn't instantly grok the need for the new cap 
functions.  So maybe that's it's own patch with it's own change log.  
After that you should just add the 'parent' task to 
ptrace_access_check() and fix all of the LSMs to handle the new 
semantics at once.  No need to rename the function or do a bunch of 
seperate patchs.  All of us LSM authors can just ACK our little part and 
James can take the patch when everyone has their say.  I think that will 
make history the cleanest.....

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ