On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote: > On Tue, 26 Jun 2007 16:07:56 -0700 > [EMAIL PROTECTED] wrote: > > > This post contains patches to include the AppArmor application security > > framework, with request for inclusion into -mm for wider testing. > > Patches 24 and 31 didn't come through. > yes, sorry about that I had a very odd failure authetication failure with those two mails and missed it.
They have been recent.
>
> 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.
> 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: <[EMAIL PROTECTED]>
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.
pgpHKUsFfcLeK.pgp
Description: PGP signature
