Re: Problems with some of the current hooks

From: Stephen Smalley (sdsat_private)
Date: Mon Aug 06 2001 - 06:43:14 PDT

  • Next message: Stephen Smalley: "Re: Problems with some of the current hooks"

    On Fri, 3 Aug 2001, richard offer wrote:
    > I have no problem with collapsing hooks into one to shrink the structure
    > size as long as its possible to identify the operation. 
    > In the case of truncate it seems that I could, the is_valid should contain
    > ATTR_SIZE.
    Yes, the setattr hook can distinguish truncate operations by checking
    ia_valid.  Also, the setattr hook can propagate errors back to the caller
    (unlike the truncate hook, which is currently called from the void
    vmtruncate function), and the setattr hook has the dentry available
    (unlike the truncate hook, which only has the inode available).  So,
    the setattr hook offers richer functionality and should cover the
    truncate operation.
    > However, by passing a dentry we're again in the problem of being able to
    > absolutly identify what is being trucated (path, fd). I'd like to see some
    > way of addressing that.
    Well, the setattr hook seems slightly preferable to the truncate hook 
    with regard to reconstructing pathnames, since it provides a dentry
    instead of just an inode.  But I think your concern is really orthogonal
    to the question of whether the existing truncate hook can be eliminated.
    > I'd like to suggest dropping the read/readv, write/writev hooks, extending
    > permission to cope with being called from
    > read/readv/write/writev/pread/pwrite (with enough information for the
    > module to determine where it is called from), Then having separate hooks
    > for sendfile and readdir.
    I'm not sure what you mean by "with enough information for the
    module to determine where it is called from."  Currently, the
    file_ops->permission hook does pass a flag indicating whether
    it is a read or write operation.  Why would you want to know
    specifically whether it is a read vs. readv vs. pread?  And
    why exactly do you want separate hooks for readdir and sendfile?
    The file_ops->permission hook can check the inode mode to see
    if the object is a directory, if you want that distinction.  And
    I'm not sure what kind of distinction you are seeking in sendfile,
    although I guess it might be nice to have a single hook call
    there instead of two separate calls.
    > * The acct hook belongs in the file_ops structure.  FIX:  Move it.
    > Not sure about this. While it passes a struct file * (boo hiss :-) I don't
    > really think of acct being a file operation in the same way that read is. I
    > think it makes reasonable sense to leave it where it is.
    > But I have no strong feelings either way.
    I don't especially care about this change either.  I didn't make
    these changes (moving hooks to different structures) in my patch.
    > * The setcapability hook is not called by the kernel and it has no
    > * parameters defined.  
    > Our previous work did include a patch to add parameters to the call.
    True, but your patch still leaves a lot of capability-specific logic
    in the base kernel.
    > Hmmm, not sure I like the idea of changing system calls on a policy module
    > basis. In particular you're now affecting application behaviour. Until now
    > LSM has avidly avoided the problem of application issues, which I think is
    > shortsighted, but I'm in the minority of 1. 
    SELinux is concerned with application issues, and we've tried to
    provide policy-flexible extended APIs in SELinux.  Creating
    a set of even more general APIs for LSM security modules would
    be interesting, but probably needs to wait a little bit.
    > If SELinux wants to add its own system calls (with its own set of
    > applications) thats one thing, breaking exising applications unless the
    > capability module is loaded is not something I'd like to see.
    Right, I understand this concern.  But if we really want to
    make capabilities an optional module, and if we really want to
    allow the capabilities module to evolve separately from the base kernel,
    then I think we need to allow the capability plug to completely redefine
    the interface and implementation of these system calls.  I don't
    think it would be sufficient to just move the access control logic
    out of setcapability.
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon Aug 06 2001 - 06:44:51 PDT