On Mon, 23 Apr 2001 21:09:17 PDT, Greg KH said: > What? Wait a second. Exactly how are we going to implement lsm_perror? > A new syscall? If so, you can't just return a pointer to a constant > kernel string, that doesn't work... I never specified how it was implemented.. ;) It may require a new syscall that would fill in a struct (or at least pass back enough information that a liblsm.so can finish the work in user space). But we *know* how to do that - there's plenty of ioctl's that get terminal/network interface/whatever info out of the kernel and into user space (I'd suggest an ioctl, except for the obvious problem that a file descriptor may not be involved/available ;) Think 'stty -a' as a straw-man model - do ioctls to kernel, and then format in user space... > Who's going to write the userspace library? I'd suspect the same people who wrote th LSM. The SELinux folks would provide their lsm_perror(), the RBACS folks would provide theirs. If IBM decides to port RACF, they'd have a RACF module.. ;) > Who's going to provide the localization (the kernel sure isn't going to have > localized strings in it)? See above... > Does this mean that the kernel module needs to keep around for every > task the last error that it had? Where is it going to store this? (ok, > it can just store it on the task structure, in its anonymous "blob"). That works... ;) > Remember, there is no way to hold a "global last security error" in the > kernel, as there are zillions of tasks running. That just doesn't work. I never said it was global. As you noted, the LSM can easily keep a per-thread or per-process last-error value in the security context for the thread/process. > And most important of all, who is going to write code to actually use > such a thing? I don't see the current Linux security projects offering > up secure userspace tools to match their kernel patches (SELinux being > an exception here, from what I have heard, but I might be wrong here.) The fact that SELinux does some stuff in user space was a major factor in why I suggested it. Maybe none of the projects offer secure userspace tools because there's no good interfaces? It's been a while, but we ran VMSECURE on IBM's VM operating system. That came with a whole *book* of different errors that could be encountered. Our MVS system had Top Secret - which was equally excruciatingly detailed in saying exactly what went wrong. Remember - right *now*, we're roughing out kernel hooks to support 3-4 research-class projects (SELinux, RBSAC, etc). 3 years from now, there *will* be commercial vendors wanting to write commercial-quality code. Saying "I don't see anybody using the interface that doesn't exist yet" as a justification for not providing at least the *hooks* needed is.. well.. umm... ;) /Valdis _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 21:50:11 PDT