Re: [PATCH 3/4] integrity: Linux Integrity Module(LIM)

[David Howells <dhowells@redhat.com>]

Peter Dolding <oiaohm@gmail.com> wrote:

> Credentials patch for Linux allows more than the BSD one does.  Linux one is
> a complete permission storage replacement.

No, it isn't.  It replaces the permission storage facility of a process but
does not change the way in which an inode caches its credentials in RAM.

> http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-08/msg02682.html
> 
> Note the file credentials one.

I said "Open file credentials".  I was referring to struct file which
designates an open file handle, not the file/inode itself.  What this means is
that the open file handle takes a reference to the subjective security context
of the process that opened it, at the time it opened it, so that accesses to
that file are (with exceptions) done with those credentials, no matter who is
actually using the handle.

For disk filesystems, for the most part, this makes no difference: an open file
is usable by anyone who has the handle.  However, for network filesystems,
where each request is marked with the details of who the request should be
accounted to and the server decides, it does matter.

> That is reused by FS Cache and it creates fake inodes.

FS-Cache+CacheFiles doesn't create fake inodes at all.  It creates real inodes
on disk in the cache.  The reason for these patches is that CacheFiles needs to
use its own subjective security context when creating or accessing these
inodes, rather than the subjective context of whoever invoked AFS or NFS, and
thus caused CacheFiles to touch the 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.

I don't understand what you're talking about.  Looking in fs/namei.c, I see:

	int vfs_permission(struct nameidata *nd, int mask)
	{
		return inode_permission(nd->path.dentry->d_inode, mask);
	}

And:

	int file_permission(struct file *file, int mask)
	{
		return inode_permission(file->f_path.dentry->d_inode, mask);
	}

That looks like they still both go to inode_permission().

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

Erm...  Why?  inode_permission() is a function, the creds struct is a data
type.

> Each filesystem having its own cache is one reason why Linux Credentials
> Patch is being brought into live.

Not as far as I know.  The credentials belonging to the filesystem and the
inodes in the filesystem belong to the filesystem and are not held in cred
structs.  Using cred structs for inodes would waste memory as a task's
credentials have a lot of bits an inode's don't.

> 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.

Are you suggesting the offloading of security data caching to userspace?

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

In simple terms, no they aren't.

> 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.

>From my quick glance over the integrity patches, I'd say that the cred struct
is entirely the wrong place to store this data.  It's nothing to do with a
task's subjective state, except, perhaps, in setting it up.  It appears to be
per-inode state.

David