Re: Possible system call interface for LSM

gregat_private

Wow, ignore the mailing list for 1 day, and look what happens, a nice
technical debate :)

Anyway, thanks Lachlan for the patch that started everything off, and
for everyone else's discussion.

Here's my comments on the whole thing (just go look at the attached
patch if you don't care about my comments and just want to see what I've
actually applied to the tree...)

  - we need a syscall, that is a given.  Lots of different projects want
    it.  So like Stephan said, the best interface is the same interface
    that is already being used by the network stack.  Hence a hook that
    looks like:
  	syscall (int call, unsigned long *args);

  - In the core lsm code, we do not need to do any copying from
    userspace.  That's up to the module to know what is going on and get
    it right themselves.  This doesn't penalize the people who want a
    very simple syscall with the overhead of the others.  It also allows
    the LSM core to totally ignore the format of the call, and rely on
    the fact that the loaded module knows what to expect, and how to
    deal with it.

  - Non of this registered numbers loonacy.  That way is madness.  If
    you are going to stack modules, the modules themselves are going to
    have to handle this themselves.  End of story.  If you want
    userspace to know that the SELinux module is loaded, examine some
    userspace visable thing (like a mounted file system, see next
    point.)

  - About /proc.  One word: Don't!  If you dig through the archives I
    have explained how a module should be exporting information that it
    wants to userspace, create a filesystem.  It's easy, fast, and the
    way to do things.  See the current sockfs, ramfs, tempfs, usbdevfs,
    and others for examples of how to do this very simply.  This is the
    way of the future, get used to it.  In fact, I recommend this over
    using a syscall for most interactions with the module (like for
    instance, loading profiles into SubDomain.)  syscalls do have their
    place, hence our need for 1.

I think that about covers the whole thread.  Comments on the attached
patch, and why it doesn't work for your module?

thanks,

greg k-h