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:24:03 -0700
From:	John Johansen <jjohansen@...e.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	jjohansen@...e.de, 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, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 16:07:56 -0700
> jjohansen@...e.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@...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.

Content of type "application/pgp-signature" skipped