Clark asks > What are the security implications of allowing uninvited snooping?
It depends on who is doing the snooping and why they are doing it. All of the major commercial monitoring products and even the non-commercial ones need access to "other" address spaces from time to time. The only way they can "see" what's going on in another address space is to schedule an SRB (or other even more dastardly techniques we won't discuss) and "sniff around". There is basically ZERO security implication in what these tools do and your only risk is from design or coding errors. You're hardly likely to have a system outage from RMF, but it has happened once or twice. In general they need access ONLY to sniff around in system control blocks and report on the state they found. That's what they're doing when you use the tool to examine performance problems. Other cases like the application profiling tools (Inspect, InTune and Strobe, plus Dave Cole's XDCCDF) are more specifically interested in what code each TCB is executing in the address space being monitored/profiled. They have a much deeper/more invasive view of what's going on, but they are "invited in" FSVO "invited" because they don't do anything at all unless you specifically ask them to. Those tools do allow you to see code or data (and in XDC's case, change it on the fly) and in that respect they might be considered a yawning security hole except for one thing. They each require the user to have a security privilege to access any other address space than their own. So the security question is handed off to the installation's security policy. If you've got the stones for it, you get access. Otherwise nada. > Is this a good way to pick up confidential information if someone > understands the application? Yes, but you would have had to have security permission to do it anyway (see above) so the tool would only be a convenience for you. You could have gotten that information yourself by other means. So (IMNSHO) the tools are not a security risk at all, provided the installation's security policies are properly administered. Now if your shop allows any grinning idiot access to the secret druid stuff then anyone could be a black hat and you'd never know. > How does Omegamon handle this and can > the method used be made available assuming the security concerns are > met? Omegamon, like all of the other commercial tools, follows the security rules. It isn't a security risk unless your shop has sloppy administration of security policy. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
