lkml.org 
[lkml]   [2008]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 01/11] Security: Add hook to get full maclabel xattr name
    From
    Date

    On Thu, 2008-02-28 at 18:29 -0800, Casey Schaufler wrote:
    > --- Dave Quigley <dpquigl@tycho.nsa.gov> wrote:
    >
    > >
    > > On Thu, 2008-02-28 at 17:04 -0800, Casey Schaufler wrote:
    > > > --- Dave Quigley <dpquigl@tycho.nsa.gov> wrote:
    > > >
    > > > >
    > > > > ...
    > > > >
    > > > > I can only speak for myself but honestly I've only seen Casey act
    > > > > confrontational to this idea from the beginning.
    > > >
    > > > That is simply because I don't care for your design and implementation
    > > > choices, I think they're a bad way to go, I've suggested what I
    > > > think you should do, and I'm sorry that that comes off as
    > > > confrontational but that does not change what I see as flaws in
    > > > your approach. I understand what you're trying to do and I think
    > > > it's wrong.
    > > >
    > > > > There is absolutely
    > > > > nothing in here that is SELinux specific, tecnically its not even MAC
    > > > > specific.
    > > >
    > > > Then why are you putting "mac" in the interface name?
    > > >
    > > > > I said from the beginning that this was perhaps not the best
    > > > > name and we are willing to change it.
    > > >
    > > > If you read back in the thread, that is what I suggested you do.
    > >
    > > I know but for some odd reason we kept arguing about it. Unless you want
    > > me to repost the patch on it's own with the name changed you are going
    > > to have to wait for version two :)
    >
    > No trouble there.
    >
    > > >
    > > > > There is nothing in this hook that
    > > > > wasn't in LSM before. This is almost identical functionality to what
    > > > > Adrian removed in 2.6.24. The only difference between this and
    > > > > security_inode_getsuffix is that this returns security.suffix and that
    > > > > the name is different. I don't have a SMACK box to test it on but I'm
    > > > > 99% sure that if Casey tried to use SMACK with this patch set that he
    > > > > would have labeled nfs working with SMACK.
    > > >
    > > > You're very possibly right. I am not argueing from what's right for
    > > > Smack, I am argueing from what's right for the LSM. Smack is a label
    > > > based MAC LSM, like SELinux. I would expect that it would be easy for
    > > > the NFS implementation to accomodate both.
    > > >
    > > > > If it doesn't work with SMACK
    > > > > right now I'm willing to help him with that and even include it in the
    > > > > patch set. But spreading FUD about how we are including SELinux specific
    > > > > code in here is just that.
    > > >
    > > > Sorry, but I'm not argueing that it's SELinux specific at this point.
    > > > I'm argueing that it's specific to single label stored in an xattr
    > > > based MAC systems (a set of which both SELinux and Smack are members)
    > > > and that it is file system specific to NFS. Any of these attributes
    > > > makes it questionable as an LSM interface.
    > > >
    > > > As I said before, trying to be helpful, call it security_blob_name(),
    > > > and the upcoming Discretionary Time Lock module can return NULL,
    > > > indicating that it wants to share no blob name. Or call it
    > > > security_xattr_names() and DTL can return NULL and B&L+Biba can
    > > > return "security.Bell&LaPadula security.Biba", hoping that everyone
    > > > who uses the interface accepts the blank seperation as an indication
    > > > that there are multiple xattrs involved.
    > >
    > > I agree with your suggestion here but nowhere in earlier emails did you
    > > outline this. You just vaguely described a method that sounds like the
    > > selinux sidtab. If you had described it this way in the beginning we
    > > would have be done with after the first response. If we are going to
    > > work well in the future you need to be more clear when you make
    > > constructive criticisms (or even destructive ones *wink* ).
    >
    > Sorry 'bout that.
    >
    > > >
    > > > I am saying that security_maclabel() is a bad choice, and I think
    > > > that as an LSM (not MAC, not xattr, not NFS) interface it should
    > > > serve the LSM, making the LSM interface better first, and being
    > > > the specific interface that a particular file system finds
    > > > convenient second.
    > > >
    > > > And before we go any further, I have personally been involved in
    > > > doing labeled NFS three times, and I know where the bodies are
    > > > buried. Your approach is fine for single label stored in xattr based
    > > > MAC systems. It does not generalize worth catfish whiskers, whereas
    > > > the two other schemes I've done do so flawlessly. I am critical of
    > > > this approach only because I know that y'all can do better.
    > >
    > > That is fine. I welcome constructive criticism but you have a tendency
    > > of being vague with what you mean and at times it comes off the wrong
    > > way. This is the whole reason the patch set was posted to begin with. We
    > > have been working on it for so long without much outside input so we
    > > decided to get criticism on it.
    >
    > Thank you for doing so.
    >
    > > > Great. Now I owe the entire labeled NFS team beer.
    >
    > Phew, he missed that one.

    Hehe I didn't miss it but I don't drink (A coke would be greatly
    appreciated though). Can't speak for the rest of the team though.

    >
    >
    > Casey Schaufler
    > casey@schaufler-ca.com



    \
     
     \ /
      Last update: 2008-02-29 03:37    [W:0.047 / U:93.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site