[lkml]   [2007]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [AppArmor 00/41] AppArmor security module overview 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

    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

    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

    anyways, just a thought
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-12 12:37    [W:0.020 / U:10.540 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site