RE: Possible system call interface for LSM

lachlanat_private

> -----Original Message-----
> From: Stephen Smalley [mailto:sdsat_private]
> Sent: Thursday, August 09, 2001 10:49 PM
> To: Lachlan McIlroy
> Cc: linux-security-moduleat_private
> Subject: Re: Possible system call interface for LSM
> 
> 
> 
> On Thu, 9 Aug 2001, Lachlan McIlroy wrote:
> 
> > There was some minor discussion recently about modules
> > needing to modify the system call table to create module
> > specific system calls.  It prompted me to investigate a
> > fixed system call for LSM that will multiplex the variety
> > of system calls required for each different security
> > scheme.  I've attached a patch of the proposed idea for
> > people to comment on.
> 
> For the SELinux module, I multiplexed our new operations through
> an interface based on the existing Linux socketcall interface for
> multiplexing socket operations - See net/socket.c:sys_socketcall.
> I added a magic number parameter similar to your module id.
> In that form, the entrypoint function only copies in the args 
> array, leaving the copyin/copyout of particular pointer args to the
> individual operations.
> 
> While I understand the appeal of doing all of the copyin/copyout
> from the entrypoint function, it seems unnecessarily limiting.
> Also, even if we were to take your approach, shouldn't the length
> parameter be in/out (unsigned long *length) so that the output
> data can have a different length than the input data?
I considered this approach.  If the module returns a new
length which is greater than the old length then in order
to do the copy_to_user the system call will have to
kmalloc(GFP_USER, new_length).  If this new memory is to
be passed back to the application (and why wouldn't it?)
then the data argument would have to be a 'pointer to a
pointer' which would clobber the previous value.  If the
data argument is the only reference the application has
to some alloc'ed memory then it will no longer have that
reference to pass to a free.  This problem isn't difficult
to work around though.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalleyat_private
> 
> 
> 
> 
> 
> 
---
Lachlan McIlroy                    Phone: +61 3 9596 4155
Trusted Linux                        Fax: +61 3 9596 2960
Adacel Technologies Ltd                    www.adacel.com


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