[lkml]   [2008]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [TOMOYO #11 (linux-next) 01/11] Introduce new LSM hooks where vfsmount is available.
    Kentaro Takeda wrote:
    > ----- What is this patch for? -----
    > There are security_inode_*() LSM hooks for attribute-based MAC, but they are not
    > suitable for pathname-based MAC because they don't receive "struct vfsmount"
    > information.
    > ----- How this patch was developed? -----
    > Two pathname-based MACs, AppArmor and TOMOYO Linux, are trying to merge
    > upstream. But because of "struct vfsmount" problem, they have been unable to
    e> merge upstream.
    > Here are the list of approaches and the reasons of denial.

    I know I'm late to the game in this, but as I recently asked about this
    and didn't get an answer, I'll re-ask my approach.

    Why can't you do this

    in lookup()

    - resolve rules (not for single process, but for all processes) for said
    path and tag dentry (seem to already have a hook)

    in permission()

    - check tag based on current security context

    in rename(),....

    - drop dentry tag and force a lookup next time its used (invalidate dentry)

    you then don't have to jump through hoops to handle things like symbolic
    links as they are handled implicitly.

    the only place I can see this approach "failing" (as in different
    semantics than your approach) is

    - hard links within a single namespace and bind mounts shared between
    namespaces (in that different rules would be resolved for different path
    names for the same file).

    But from a security perspective, both would seem like a very bad idea in
    general that one would ant to prevent. or to rephrase, why would you
    want to allow that? What's the benefit in allowing that?

     \ /
      Last update: 2008-10-20 15:05    [W:0.021 / U:75.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site