On Fri, 10 Aug 2001 19:33:01 PDT, Crispin Cowan said: > I suspect that this will not be a problem in practice. I don't believe that > module removal will be all that common, other than for shutdown and massive > reconfigurations anyway. An application that wants to be non-brittle should > inspect error codes coming back from sys_lsm, looking for a return code of > "EWTF?" ;-) and react appropriately. I have to agree with this. I thought for quite some time, and was unable to come up with a scenario that this would be an issue for. 1) 24x7 boxes that basically aren't allowed to reboot - but 24x7 has it's own issues and usually involve a hot fallover. 2) Sysadmin doing config testing of various modules - but he'd probably be rebooting each time around anyhow - I know *my* test machines rarely make it to 3-4 days uptime unless we're doing a stability test ;) 3) I even thought about a site that needed SELinux during the day to support office workers but wanted to sell spare cycles at night to a group that needed some other package - but THAT will last only until a VP has to work past the cutover time to get a big deal closed ;) This *does* however raise a side issue - the suggestion was made that the module reap processes as needed if it was unloaded. Now, given that the kernel *does* know some processes that are LSM-aware (those that specifically ask), there could exist processes that are aware, but haven't made it clear to the kernel (for instance, they may have poked in /proc/modules - but lots of things do that). So reaping at unload time seems problematic. On the other hand, I've seen little discussion of a standardized way for the kernel to tell a process that there's been a change. A *much* more likely scenario is that a long-running process has its security context invalidated (either due to a sysadmin updating a control table, or perhaps a time-of-day policy enforced by the module). I *was* going to suggest that the module send the affected process a SIGSECCONTEXT (with a default handling of SIG_IGN), but looking at /usr/include/bits/signums.h it appears there's no room to define one (as the realtime stuff grabs __SIGRTMIN == 32 and up). There's precident for this in other Unixoid systems - AIX defines a SIGSAK to tell the process there's been a secure attention key press. Any thoughts? (Yes, I know callbacks were discussed. ON the other hand, do we want something better than 'open(fd,"/proc/my_lsm/context") and wait for a SIGPIPE if it's changed on you'? Or is that what we will be recommending? /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 : Sun Aug 12 2001 - 21:30:05 PDT