Re: [PATCH] remove sys_security

["David S. Miller" <davem@redhat.com>]

   From: Greg KH <greg@kroah.com>
   Date: Thu, 17 Oct 2002 11:53:52 -0700
   
   No, don't remove this!
   Yes, it's a big switch, but what do you propose otherwise?  SELinux
   would need a _lot_ of different security calls, which would be fine, but
   we don't want to force every security module to try to go through the
   process of getting their own syscalls.
   
   And other subsystems in the kernel do the same thing with their syscall,
   like networking, so there is a past history of this usage.

Well, here is another issue about opaque interfaces, how are we
supposed to audit whether 32-bit/64-bit execution environments
will be able to work correctly?

If there is no description available of what the types are going
through these system calls, it cannot be handled properly.

It is one thing if some existing legacy user interface we can't make
go away creates this kind of problem, but when we add new system calls
we ought to be much much more careful.

I brought this up months ago, and I believe someone (perhaps you :),
said "oh I'll bring that up with the folks, thanks" and I've seen
no action taken since.

Are the LSM modules that exist now using portable types in the objects
passed into sys_security?  Note that pointers and things like "long"
are not allowed as types, for example, those would need to be translated.

The more I look at LSM the more and more I dislike it, it sticks it's
fingers everywhere.  Who is going to use this stuff?  %99.999 of users
will never load a security module, and the distribution makers are
going to enable this NOP overhead for _everyone_ just so a few telcos
or government installations can get their LSM bits?

This doesn't make any sense to me, including LSM appears to be quite
against one of the basic maxims of Linux kernel ideology if you ask me
:-)  (said maxim is: If %99 of users won't use it, they better not
even notice it is there or be affected by it in any way)