linux-kernel - Re: [AppArmor 00/44] AppArmor security module overview

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]

Date:	Tue, 26 Jun 2007 19:47:00 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	John Johansen <jjohansen@...e.de>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview

On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <jjohansen@...e.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.

Do you agree with the "irreconcilable" part?  I think I do.

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.

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.

> > 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@...e.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.
-
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/