Re: Possible system call interface for LSM

pollardat_private

Seth Arnold <sarnoldat_private>:
> On Thu, Aug 09, 2001 at 08:50:46AM -0700, richard offer wrote:
> > 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.
> > 
> > 
> > with copy_flag either DATA_IS_USER_SPACE or DATA_IS_KERNEL_SPACE ? (ToDo:
> > make up better names)
> 
> Please forgive my ignorance, but is it common for kernel space to call
> syscalls? (The gist of my question is actually aimed at a specific
> point: why would the pointers in the arguments to this syscall ever be
> kernel space?)

Not common, but I am working on some specs to provide application isolation
for network daemons that calls for being able to do that. One isolation
technique is to not allow a daemon to perform a fork/exec, that would be
done by the security module.
For example:

  1. a host makes a tcp connection to a known local port (say the telnet).
  2. inetd spawns a "daemon" that can only interface between an authentication
	helper daemon, and the remote connection - It handles prompts, echo
	(or no echo) and general terminal like characteristics.
  3. The authentication helper daemon passes info back to the security module
	on the identity of the remote user, and approval/disaproval for
	a continued connection. The daemon also identifies the process
	(not fully worked out) of the interface "daemon", and completes the
	IO back to the interface daemon.
  4. The interface daemon makes a request to the security module to switch
	to user (identity not specified - this daemon might have been
	compromized)
  5. The security module then forces an exec of a previously specified
	(where/how to be determined) image on the interface "daemon", or
	terminates the process (connection denied). The forced exec would
	also setup the processes capabilities, user identitiy, and any
	other setup and logging function required.

I intend to disable the interface processes ability to:
	1. open/close files (they will have been opened by inetd).
	2. fork/exec (it will have no busines doing that)
	3. make system calls other than read/write/send/recv, and a security
	   request (which may itself be read/write of a domain socket instead
	   of a system call).

The authentication helper daemon will not be able to use any system calls
except read/write/seek, and make security requests (again possibly via
a domain socket). The user database would already have been open before
the helper daemon is started. It might have to be able to query process states
and maybe fork. (Equivalently - it might open the user db, connect to the
security module, create a domain socket THEN surrender the capabilities
to do these things.)

The experiment is to completely isolate the network connection from being
able to do anything if it gets compromized. Any attempt to perform
disallowed system calls would terminate the process.

If this works then one goal would be to make multiple authentication helper
daemons, one for each method of authentication (ssl, kerberos, ...) to allow
for a "plugin" to extend the methods available for identification,
authentication, and authorization.

> > 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.
> 
> Hmm. My initial reaction is to suggest just copying the pointers about,
> and let the module handle copy_from_user and copy_to_user. If SELinux
> wants the original pointers, it is possible someone else will want the
> original pointers too.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

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