[lkml]   [2002]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] remove sys_security
Alan Cox wrote:

>On Thu, 2002-10-17 at 21:10, Greg KH wrote:
>>Ok, I think it's time for someone who actually cares about the security
>>syscall to step up here to try to defend the existing interface. I'm
>>pretty sure Ericsson, HP, SELinux, and WireX all use this, so they need
>>to be the ones defending it.
>The existing interface is basically the one Linus asked for, although
>perhaps with a little less thought on the structure side than it would
>have benefitted
The intent behind the syscall interface was that it needed to be generic
enough to support the 50+ syscalls that SELinux wants, and also be
generic enough to support potential modules that have not been invented
yet. That's why it is a MUX, and why the signature definition is enough
to deal with stacked modules and then pass a generic argv list to the
module itself.

Unfortunately, this design goal (highly generic interface) is
incompatible with the 32/64 bit transparancy layer that several
supported architectures need. As Christoph says, this is unfixable.
IMHO, it is unfixable because of conflicting design goals: you cannot
have a truly generic syscall interface and hope for it to port clean
from 32 bits to 64 bits.

Therefore, the sys_security syscall has been removed. LSM-aware
applications that want to talk to security modules can do so through a
file system interface. This will work for WireX, and Smalley says it
will work for SELinux. I hope it will work for others.

Again, my thanks for eveyone's help in cleaning up this issue, and my
apologies to anyone I may have offended. We should have thought about
the 32/64 bit issue when we defined that interface. Kudos to Greg K-H,
who told me that this syscall would be a problem.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:30    [W:0.147 / U:3.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site