RE: Possible system call interface for LSM

lachlanat_private

> -----Original Message-----
> From: linux-security-module-adminat_private
> [mailto:linux-security-module-adminat_private]On Behalf Of 
> richard offer
> Sent: Friday, August 10, 2001 1:51 AM
> To: linux-security-moduleat_private
> Subject: Re: Possible system call interface for LSM
> 
> 
> 
> 
> * frm sdsat_private "08/09/01 09:11:32 -0400" | sed '1,$s/^/* /'
> *
> * 
> * On Thu, 9 Aug 2001, Stephen Smalley wrote:
> * 
> *> While I understand the appeal of doing all of the copyin/copyout
> *> from the entrypoint function, it seems unnecessarily limiting.
> * 
> * To be more specific, this would be very problematic for some of our
> * new operations, which are merely extended forms of existing system 
> * calls (e.g. extended forms of stat, mkdir, execve, ... that have
> * additional input or output parameters for security attributes).
> * These operations actually invoke the ordinary system calls 
> * (in between some pre and post processing to handle the additional
> * parameters), so they don't want to have to do the copyin/copyout
> * as a block on entry and exit.
> 
> In light of that case does it make sense to change the prototype from 
> 
>     int  (* syscall)        (int cmd, char *data, int length);
> 
> to
>     int  (* syscall)        (int cmd, int copy_flag, void *data, int
> *length);
> 
> 
> I personally would rather have length pass by value than reference.
I prefer this too.  When an application or library uses this
system call it will need to know the format of the arguments
that the module will expect.  This implies that the application
should also know what to expect back from the module and
consequently the length of the returned data.
> 
> 
> with copy_flag either DATA_IS_USER_SPACE or 
> DATA_IS_KERNEL_SPACE ? (ToDo:
> make up better names)
> 
> 
> It seems that the general case would be to copy data (so 
> removing the code
> seems like a bad idea), SELinux has specific requirements 
> where that would
> cause a significant problem, so lets let them not have to 
> copy when they
> don't want too.
> 
> The only problem I have about having security.h maintaining 
> the list of
> policy ID numbers is that that is going to have to change 
> everytime someone
> writes a new policy. 
> 
> And we're going to get into the issue of "we're not going to 
> accept your
> policy in phase 1" even if all that's required is an ID number.
> 
> Perhaps it should be vendor rather than policy specific ? It 
> forces the
> vendor of the policy to be self consistant withing their 
> organisation in
> terms of cmd codes and would require less changes to 
> security.h before and
> after the code is mainlined ?
> 
> * 
> * --
> * Stephen D. Smalley, NAI Labs
> * ssmalleyat_private
> * 
> 
> 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
> 


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