Re: Potenitial security hole in the kernel
> > Hi folks, > > Please correct me if i'm wrong but it seems to me that i've stumbled on > really BIG security hole in the signal handling code. > The problem IMO is that the signal handling code stores a processor context > on the user-mode stack frame which is active while > the signal handler is running. Then sys_sigreturn restores back the context > from user mode stack... > Suppose the signal handler modifies this context frame for example by > storing into the PC slot address of the panic routine > then when handler will exit panic will be called with obvious results. > > > Please CC your comments to me directly as i'm not subscibed to this list > > Vadim Lebedev > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Hi folks, Please correct me if i'm wrong but it seems to me that i've stumbled on really BIG security hole in the signal handling code. The problem IMO is that the signal handling code stores a processor context on the user-mode stack frame which is active while the signal handler is running. Then sys_sigreturn restores back the context from user mode stack... Suppose the signal handler modifies this context frame for example by storing into the PC slot address of the panic routine then when handler will exit panic will be called with obvious results. Please CC your comments to me directly as i'm not subscibed to this list Vadim Lebedev - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
> > S/390 folks run 70,000 sessions active within the same 60 second period off > one big box. Not on Linux (yet ;)) but its worth bearing in mind. Yes, but they don't do it with 7 separate processes (or "address spaces" to use the 390 terminology). They have a few processes/address spaces accepting a transaction, processing it, and spitting out the result. (Or, in some cases, accepting a transaction, processing it, issuing an async disk I/O requerst, and then doing another transaction while the first disk I/O waits). (Think of, say, a Web Server, which might be providing service for thousands of simultaneous clients, with just a relative handfull of web server daemon processes running.) I don't think 7 Unix login users, or 7 TSO users, or 7 processes/address spaces of any kind, would fly. Not that I have a problem with 32 bit process IDs. -- Brett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
S/390 folks run 70,000 sessions active within the same 60 second period off one big box. Not on Linux (yet ;)) but its worth bearing in mind. Yes, but they don't do it with 7 separate processes (or "address spaces" to use the 390 terminology). They have a few processes/address spaces accepting a transaction, processing it, and spitting out the result. (Or, in some cases, accepting a transaction, processing it, issuing an async disk I/O requerst, and then doing another transaction while the first disk I/O waits). (Think of, say, a Web Server, which might be providing service for thousands of simultaneous clients, with just a relative handfull of web server daemon processes running.) I don't think 7 Unix login users, or 7 TSO users, or 7 processes/address spaces of any kind, would fly. Not that I have a problem with 32 bit process IDs. -- Brett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
