Re: [AppArmor 00/44] AppArmor security module overview

John Johansen
2007-06-27T02:24:57Z

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 16:07:56 -0700
> jjohansen@suse.de 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: <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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]