Re: Problems with some of the current hooks

offerat_private

* frm sdsat_private "08/03/01 14:03:34 -0400" | sed '1,$s/^/* /'
*
* 
* I've made a quick review of the non-networking LSM hooks, and listed
* below some notes about problems I saw.  When a fix was obvious and
* didn't appear to require further discussion, I also listed a FIX.
* Otherwise, I mention that the problem is left UNRESOLVED.  I plan on
* creating a patch to implement the FIXes unless I hear objections to
* some of them.  Here are my notes:
* 
* 
* inode_ops->truncate seems redundant with inode_ops->setattr.  
* Does it need to be kept as a separate hook?  UNRESOLVED.

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.

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.

* 
* The file_ops->read, file_ops->readv, file_ops->write, and
* file_ops->writev hooks are not called by the kernel.  Instead,
* file_ops->permission is used for the read (and readv and pread), write
* (and writev and pwrite), readdir, and sendfile operations.  This is
* sufficient for access control purposes.  Should the read, readv, write
* and writev hooks be removed from file_ops?  Or should these hooks be
* used in these operations (with expanded parameters) and new hooks
* added for pread, pwrite, sendfile and readdir.  UNRESOLVED.

One of the problems with audit was that we needed to pass
LSM_NOFD_AVAILABLE in the readdir call to permission. Having a separate
readdir() hook would remove that aberation. Of course using "audit" in an
argument, I fully expect it to stay as it is :-)

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.

* 
* file_ops->lock doesn't currently take the cmd parameter.  This might
* be useful for general purpose usage.  FIX: Add the cmd parameter.
* 
* file_ops->fcntl and file_ops->fcntl64 take the same parameters.  The
* only difference is that fcntl64 has some additional possible cmd
* values.  But this doesn't seem to require separate hooks.  FIX:
* Coalesce these two hooks into a single hook, but continue to call it
* from both sys_fcntl and sys_fcntl64.

Sounds good.

[snip]

* 
* The ptrace and capable hooks belong in the task_ops structure.  FIX:
* Move them.

Okay.

* 
* 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.

* 
* 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.

* My current thinking is that we should move the
* entire capset and capget system calls out of the base kernel into the
* capability plug (so the base kernel would have sys_ni_syscall for
* these entries, and the capability module would insert them into the
* syscall table just as the SELinux module does with its new calls).

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. 

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.

I need to think about this some more, maybe dust off my PACM paper....

* Both the interface and the logic of these calls seems like it should
* be encapsulated by the capability plug, so that the Linux-Privs people
* are free to evolve them as desired.  So, if we move these system calls
* in their entirety into the module, then we probably don't need a
* setcapability hook at all.  UNRESOLVED.
* 
* --
* Stephen D. Smalley, NAI Labs

richard.

-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

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