Re: Authoritative Hooks

From: Casey Schaufler (caseyat_private)
Date: Thu Nov 08 2001 - 17:39:35 PST

  • Next message: Stephen Smalley: "Re: Authoritative Hooks"

    Stephen Smalley wrote:
    > On Mon, 5 Nov 2001, Casey Schaufler wrote:
    > > Unless the branch is the official Phase II. We believe that would
    > > address all of the issues We can think of from my side. We expect
    > > it would raise a bunch elsewhere, and that's fair.
    > It sounds like you are asking for a commitment to pursue authoritative
    > hooks in Phase II.  That seems premature since we haven't even submitted
    > the current LSM yet.  I think it would be confusing to have a Phase II
    > branch before we even have Phase I accepted, and possibly wasteful since
    > Phase I may undergo radical changes prior to acceptance.  Certainly we
    > should consider authoritative hooks and "logic out" in subsequent phases
    > of LSM, but I think it would be a mistake to make such a commitment now.
    > On a different but related topic, I wondered whether you really need
    > authoritative hooks for POSIX ACLs.  Seems like you can achieve
    > authoritative behavior for file access controls via the existing
    > capable+restrictive scheme, even though this isn't sufficient for all
    > kernel access controls.
    My goodness, but you're a fan of that particular hack!
    (hack, as in clever coding trick, not a disparaging term, BTW)
    If I have an ACL:
    on a file owned by greg.committers
    the mode bits will appear as rw-rw-r--+
    An unprivileged process owned by stephen.nai ought to have
    write access to the file, based on the ACL. It will fail the
    mode bit check, however. Not to be denied, the capable() call
    will be made. The capable call will look in the security blob
    to determine what kind of object (file, SVIPC, socket, ...)
    being accessed so that it knows what kind of data to look for.
    It then looks for that data, in this case an ACL, and
    upon finding it, checks it against the process attributes. This
    will yield success, and the access will be granted.
    The check has to be done on each component. Are there hooks
    in the pathname resolution to allow resetting the security
    blob for each component?
    I concede that by changing capable() from an inline function
    to a set of nested switches (a big set) and by carefully copying
    copious quantities of carefully crafted data into the blob
    it Might be possible to do this. I certanly wouldn't
    recommend a scheme that requires one to do so to anyone I care
    about or who's respect I value, but I think it might be possible.
    I don't plan to suggest it to the XFS people. They'd laugh at me.
    Casey Schaufler				Manager, Trust Technology, SGI
    caseyat_private				voice: 650.933.1634
    casey_pat_private			Pager: 888.220.0607
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Nov 08 2001 - 17:42:42 PST