Mike Gerdts wrote: > On 4/4/06, Chris Rijk <chris at aceshardware.com> wrote: >> Going even further would be to integrate overall package mangament >> with security settings for them and things like security alerts. Many> >> security alerts aren't very useful in terms of what sys-admin should >> do. "Wait for a patch and disable program if possible in the meantime" >> isn't that handy. For example, if a vulnerability depends on a >> buffer-overflow attack but you have an UltraSPARC chip or an x86 >> chip with NX-bit support then such attacks *may* be rendered useless - >> would be nice to get a security alert from Solaris along the lines of "You >> have XYZ installed but because you have anti-stack cracking support >> active, you don't have to worry about this vulnerability". In other cases, >> the following would be interesting too: "The current application suffers >> from this security vulnerability. There are no known exploits currently >> available but it is recommended that you disable this program until a >> patch is available. If this program is needed, then in the meantime, the >> following list of PRM setting changes can be made to reduce the scope >> for damage in case of an attack - see this web-page for more information". > > This seems to be going the same direction I was going with "Optional Modules" > I proposed as possibly being useful with fault management. > > http://www.opensolaris.org/jive/thread.jspa?forumID=49&threadID=3214 > > This particular type of "fault management" would really be more of > risk management, which seems to be what predictive self-healing is > all about. In this case, it would be just optional self-diagnosis. >
Yes, we do seem to have a lot of pieces (as is often the case). Putting them together is really where much of our investment needs to focus. Dave
