lkml.org 
[lkml]   [2008]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
    Crispin Cowan wrote:
    > Of *course* AppArmor protects the integrity of /etc/shadow, and
    > unauthorized parties are not permitted to feed data into that file
    > unless explicit access is granted. The difference is in how it is done:
    >
    > * SELinux marks the inode with a label, and only processes with the
    > right permissions can mess with the label.
    > o Residual problem: someone could rename the inode and drop a
    > new inode into place named "/etc/shadow". SELinux addresses
    > this with access control on the parent directory.

    <small> I have actually hacked a system by renaming /etc/passwd in
    this way. /etc was owned by user "bin", and I had a login as "bin"
    due to a misfeature in some program. So I substituted another
    /etc/passwd, and gave myself a root shell. </small>

    The trouble with access control on the parent directory is that
    occasionally some human accidentally forgets how important that is,
    thinking that permissions on the /etc/shadow file are important.

    Also *programs* care about a file with that name. They reference it
    by name, apply security decisions based on a process which starts with
    that name. So the name is the most relevant point of communication
    between the policy setter and programs which need to be affected.

    So I think AppArmor's approach is good here.

    > * AppArmor checks the name "/etc/shadow" so that you cannot access
    > that name without explicit permission.
    > o AppArmor cares about the integrity of what the OS returns
    > when you access the name "/etc/shadow" and does not care a
    > wit what happens to the inode that was *previously* named
    > "/etc/shadow".
    >
    > Now, without running off into the weeds again, tell me again why I
    > should care about the *integrity* of an inode that was *previously*
    > known as "/etc/shadow"?

    But insufficient here.

    If you rename /etc/shadow legitimately, after changing a password,
    there might be a program which still has a handle to the _old_ inode
    and is still reading it, still comparing a password against its contents.

    If policy was entirely name based, so modifications may be possible to
    that file after it's renamed from /etc/shadow to /etc/shadow.bak,
    _while_ some programs are still reading it (because it was /etc/shadow
    when they opened it, and they got swapped for a moment), that's a failure.

    So you *should* care about the integrity of an inode that was
    previously known as /etc/shadow - at least until you can prove that
    nobody is still dependent on it's earlier security properties. That's
    a garbage collection problem.

    > So associating a security property with a name is ok if you do it
    > statically at some arbitrary point in time, but not if you consider it
    > at the time of access? WtF? Isn't that a gigantic race condition?

    Both are race conditions.

    > To the contrary, I argue that the *current* name of a file is vastly
    > more meaningful for security properties than the name the file had some
    > months ago when someone ran restorecon over the file system.

    I agree that the current name is meaningful, but it's not watertight
    when your systems change. To avoid unexpected weaknesses, you'll need
    to apply the intersection of permissions over a time period, using
    name based policy but having it follow renames until you can prove
    it's safe to release the following.

    -- Jamie


    \
     
     \ /
      Last update: 2008-04-17 10:49    [W:2.968 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site