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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



jjohansen@xxxxxxx wrote:
This post contains patches to include the AppArmor application security
framework, with request for inclusion.

question in general, these seems like a fairly invasive series of patches. back when I first started graduate school, I prototyped a relatively simple stackable file system on 2.4 that seems to be able to do a lot of what app armor does (or at least seems to be easily extensible to o everything app armor does) from an fs perspective, without having to modify the kernel at all, why not use that approach?

What I did back then was I took Erez Zadok's fist, created his base0fs, which basically does nothing, just passes everything directly down. I viewed it as a null stackable fs. I then modified it to

a) contain a set of rules (be able to add, delete, modify them)

b) fs's private lookup() determines if a dentry matches a rule and tags
it (stored in dentry private data, but inode can be used as well)

c) fs's private permission() checks the rule data stored in private data to determine if the generic_permission should be even called.

what I didn't do is mmap or hard link, but those are additional checks one can do in those specific f_ops.

Basically, why force the VFS to change, when one can create an apparmorfs that stacks on top of whatever fs you want to use app armor rules with, create a namespace containing that new stacked fs only (to contain processes within the stacked fs).

This approach doesn't suffer from the normal stackable file system "issue" since there should be no complex what I'll call "cache coherency" issues due to the stackable "directory entry" namespace being the same exact as the underlying namespace and it passing down page cache operations directly to the lower fs. So one could stack on top of a file system one is using for both apparmor protected and unprotected processes.

I could imagine there might be an issue w/ how one deals with special file systems (ala proc and others). But the way we approached this in general, is that this is an aspect of containers. namely, each protected area is a container itself, and hence has its own private virtualized proc....

my code was mostly prototype level (As well as only for 2.4), but it would seem to very easily to duplicate in a production level quailty for 2.6.

anyways, just a thought
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux