Re: A Comment from User Space

crispinat_private

David Wagner wrote:

> Milan Pikula - WWW  wrote:
> >this looks great for the userspace, but we have a problem with returning
> >one more return value. Of course, this can be handled by libc, by defining
> >more EPERM return codes.
>
> Whatever code that comes out of this project will need to be accepted
> by Linus before it makes its way into the kernel tree,

And that is paramount.  Otherwise we are all just wasting our time.

> and I expect that
> making changes like this may put this at risk.  You're asking for major
> changes to the semantics of the Linux system call interface, and speaking
> personally, I have yet to see a compelling argument for doing so.  Does
> anyone have an existing system (SELinux, capabilities, SubDomain, etc.)
> that requires this functionality?  I'm skeptical.

Immunix (SubDomain, CryptoMark, and possibly RaceGuard) need:

   * mediation/interposition of file system access system calls
   * mediation/interposition of fork/exec
   * some per-process state
   * SubDomain needs to add one new system call
   * mediation (largely to brutally block) some dangerous system calls

No, we don't need to return funny results to existing system calls.

On the "needs a new system call" issue:  what do people think of proposing
that a block of syscall numbers be allocated to LSM?  This would result in:

   * possibly some modules become incompatible with each other, if they use
     the same LSM syscall number(s)
   * ensures that LSM modules do *not* become incompatible with other emerging
     uses of new syscall numbers

Is there a kernel mainline protocol for allocating system call numbers?

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org

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