lkml.org 
[lkml]   [2007]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [AppArmor 00/44] AppArmor security module overview
    On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
    > On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <jjohansen@suse.de> wrote:
    >
    > > >
    > > > so... where do we stand with this? Fundamental, irreconcilable
    > > > differences over the use of pathname-based security?
    > > >
    > > There certainly seems to be some differences of opinion over the use
    > > of pathname-based-security.
    >
    > I was refreshed to have not been cc'ed on a lkml thread for once. I guess
    > it couldn't last.
    >
    sorry about that

    > Do you agree with the "irreconcilable" part? I think I do.
    >
    I will concede that this may be the case for some. However I am still
    hopeful (perhaps naive) that this isn't the case in general.

    > I suspect that we're at the stage of having to decide between
    >
    > a) set aside the technical issues and grudgingly merge this stuff as a
    > service to Suse and to their users (both of which entities are very
    > important to us) and leave it all as an object lesson in
    > how-not-to-develop-kernel-features.
    >
    > Minimisation of the impact on the rest of the kernel is of course
    > very important here.
    Agreed, and I hope any changes that are made are for the benefit
    of the kernel in general and will find uses in other parts.

    >
    > versus
    >
    > b) leave it out and require that Suse wear the permanent cost and
    > quality impact of maintaining it out-of-tree. It will still be an
    > object lesson in how-not-to-develop-kernel-features.
    >
    > Sigh. Please don't put us in this position again. Get stuff upstream
    > before shipping it to customers, OK? It ain't rocket science.
    >
    Indeed, I can only appologize for the past, and offer reassurances
    that we intend to do our best to do, it right going forward.

    > > > Are there any other sticking points?
    > > >
    > > >
    > > The conditional passing of the vfsmnt mount in the vfs, as done in this
    > > patch series, has received a NAK. This problem results from NFS passing
    > > a NULL nameidata into the vfs. We have a second patch series that we
    > > have posted for discussion that addresses this by splitting the nameidata
    > > struct.
    > > Message-Id: <20070626231510.883881222@suse.de>
    > > Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to
    > > vfs_create/lookup/permission IOPs
    > >
    > > other issues that have been raised are:
    > > - AppArmor does not currently mediate IPC and network communications.
    > > Mediation of these is a wip
    > > - the use of d_path to generate the pathname used for mediation when a
    > > file is opened.
    > > - Generating the pathname using a reverse walk is considered ugly
    > > - A buffer is alloced to store the generated path name.
    > > - The buffer size has a configurable upper limit which will cause
    > > opens to fail if the pathname length exceeds this limit. This
    > > is a fail closed behavior.
    > > - there have been some concerns expressed about the performance
    > > of this approach
    > > We are evaluating our options on how best to address this issue.
    >
    > OK, useful summary, thanks. I'd encourage you to proceed apace.

    thankyou
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2007-06-27 08:47    [W:4.256 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site