Re: Problems with some of the current hooks

sdsat_private

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
ssmalleyat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module