lkml.org 
[lkml]   [2007]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
    On Mon, 11 Jun 2007, Sean wrote:

    > david@lang.hm wrote:
    >
    >> say that we give each file a unique label, and for simplicity we set the
    >> label == path (note that this raises the issue, what will SELinux do when
    >> there are multiple paths to the same file)
    >
    > So don't do that then.
    >
    >> now say that you want to grant apache access to all files that have labels
    >> that follow the pattern '/home/*/http/* ?
    >>
    >> you are either going to use regex matching, or you are going to have to
    >> enumerate every label that matches this (potentially a very large list).
    >> and if you try to generate the enumerated list you need to add a label to
    >> the list if a file is renamed or created to match the pattern, and delete
    >> a file from the list if it is renamed to no longer match the pattern
    >
    > If AA requires regex matching in the kernel, perhaps it really isn't
    > appropriate for inclusion. Surely there has to be a better way than
    > requiring the kernel to do regex matches at runtime?
    >
    >> AA over SELinux would need for SELinux to figure out how to handle file
    >> creation, file renames, and multiple paths for the same file (hard-links
    >> and bind-mounts). In addition a userspace daemon would have to be written
    >> to re-label files and/or change policy on the fly as files are renamed.
    >> the result would still have race conditions due to the need to re-label
    >> large numbers of files
    >
    > WRONG. The labels would be obtained from AA as needed, never recorded in
    > the file attributes. This would change nothing about what AA needed
    > to compute at runtime, just the way it implements the result.

    Ok, you are proposing throwing out all the label handling that SELinux
    does, including any caching. forgive me if I agree with the SELinux people
    that this is a very bad idea.

    >> ACPI should have taught everyone that sometimes putting an interpreter in
    >> the kernel really is the best option. looking at the problems of bouncing
    >> back out to userspace for file creation and renames it looks like a regex
    >> in the kernel is a lot safer and more reliable.
    >
    > There hasn't yet been shown a requirement for a userspace daemon to implement
    > AA over SeLinux.

    I thought the userspace component was what you were proposing instead of
    doing the regex matching in the kernel. if this isn't it what exactly are
    you proposing?

    you don't want the regex matching in the kernel.

    you don't want a userspace component to do the regex matching when files
    are created or renamed.

    how exactly do you propose to figure out what should happen to a file when
    it is created or it (or a parent directory) is renamed?

    AA policies are defined in terms of regex expressions. you say that this
    should be able to be done on top of SELinux somehow without changing the
    policies. so somewhere, something needs to interpret the regex to see if
    it matches the path. this needs to be either kernel code or userspace
    code. you have ruled out kernel code and are now claiming that userspace
    isn't needed.

    David Lang
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-11 11:37    [W:5.538 / U:1.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site