Tim lawless wrote: >On 13 Apr 2001, David Wagner wrote: >> Why is this a problem? >> The 'execve() returned' event is not meaningful unless execve() failed. > >It can be meaningful. For example, if a setuid program is execve()'d , >and we are monitoring via a wrapper of the systemcall, we would not >be able to catch the setuid execution event within the wrapper. Uh, maybe we have a miscommunication. I'm not talking about 'execve() requested', I'm talking about 'execve() completed successfully'. If you don't want to allow execution of setuid programs, then you need to trap on the former event, not the latter (the latter is too late). >[1] I learned this the hard way when trying to handle a > vfork-execve sequence would generate a systemcrash, it was > traced down to a staticly declared varable that when pushed > on the stack would trash current. replacing vfork with fork > eliminated the problems and was how I began to debug and > narrow down the cause. Could you elaborate? This sounds like a user-space issue that won't affect a in-kernel security policy module, but I don't see enough details to know for sure. _______________________________________________ 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 : Fri Apr 20 2001 - 18:56:51 PDT