Message-ID: <e7d8f83e0808130344x29fcb9aja00ce3f64a95ef7b@mail.gmail.com>
Date:	Wed, 13 Aug 2008 20:44:54 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Christoph Hellwig" <hch@...radead.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	"Mimi Zohar" <zohar@...ibm.com>, serue@...ux.vnet.ibm.com,
	"James Morris" <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	"Randy Dunlap" <randy.dunlap@...cle.com>, safford@...son.ibm.com,
	sailer@...son.ibm.com, "Stephen Smalley" <sds@...ho.nsa.gov>,
	"Al Viro" <viro@...iv.linux.org.uk>,
	"Mimi Zohar" <zohar@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/4] integrity: Linux Integrity Module(LIM)

On Wed, Aug 13, 2008 at 5:29 AM, Christoph Hellwig <hch@...radead.org> wrote:
> On Tue, Aug 12, 2008 at 06:41:16PM +1000, Peter Dolding wrote:
>> We really do need to get credentials patch in to common store all this
>> permission/secuirty data..  With a section for integrity related
>> entries.
>>
>> Anti-Virus Passes and fails, signed running programs support and so on.
>>
>> Lot of different things need ways of recording integrity status's.
>> Users also need to know if a application does not work is it TPM is it
>> Anti-virus is it lack of signature.
>
> Peter, please read up what the credentials patches do, or how struct
> cred/ucred is used in SVR4 and BSD for the last 20 years.  It is useful,
> but it's not going to help with any of the strange thigns the AV or
> Integrity people are doing.
>
The Issue I have.  By your answer you have not.   Credentials patch
for Linux allows more than the BSD one does.  Linux one is a complete
permission storage replacement.

http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-08/msg02682.html

Note the file credentials one.  That is reused by FS Cache and it
creates fake inodes.  So worst case event LIM blocks a valid file
because its coming from cache.

"vfs_permission and file_permission are just small wrappers around
inode_permission."  No longer both go to inote_permission after the
credentials patch is in.   file_permission instead goes to credentials
struct connected to the inode.  Most calls to inode_permission end up
wrapped to the credentials struct.

Basically by the way Linux Credentials patch is being done.
inode_permission could completely cease to exist.    Completely
replaced by the credentials structure.

Each filesystem having its own cache is one reason why Linux
Credentials Patch is being brought into live.   So a single cache can
store all the need information of the OS and for the file system.
Even better operate on filesystems lacking all the need permission
structs using a userspace program to fill in some of the blanks.

LSM's in Credentials can there own protected data sets since all
alterations to Credentials by the user space deamon have to go past
LSM for approval or rejection.  Linux Credentials only need a extra
protected zone added to cover you LIM needs and AV needs to store
data.

In simple terms permissions stored in inodes is basically deprecated
by Linux's Credentials patch.

Sorting out the Credentials patch is kinda key.   Nothing you AV or
Integrity people is strange to the Linux Credentials patch.   Without
embracing requires more processing when pulling data from a common
cache that has already been AV or Integrity scanned and maintained in
that state.  Now its really designing the struct that should exist in
Credentials.

Peter Dolding
--
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/

Powered by blists - more mailing lists