lkml.org 
[lkml]   [2011]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v1] security: introduce ptrace_task_access_check()
On Fri, Jun 17, 2011 at 11:43 -0400, Eric Paris wrote:
> >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.

It is needed because of capable(CAP_SYS_PTRACE) and similar inside of
ptrace_may_access() implementations.

> 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.

I thought it would represent function's semantic changes more strongly.

> 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.....

Great! It would be much simple for me too :)

Thanks,

--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments


\
 
 \ /
  Last update: 2011-06-17 17:53    [W:1.823 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site