On 01/24/2011 02:47 PM, [email protected] wrote: > On Mon, 24 Jan 2011, Phil Pennock wrote: > >> On 2011-01-24 at 17:34 -0500, Luke S Crawford wrote: >>> Right, but it sounds like the hole was quite possibly in the closed-source >>> binaries they are running. a re-install, without fixing the hole, will >>> just result in a new compromise. it seems to me like the owner of >>> those closed-source binaries needs to be involved in that, to me. >> >> This is the point at which swallowing the pain of dealing with SELinux >> might become worthwhile -- if you can track what access those binaries >> ever normally need and can get confirmation that's all they need, then >> you can lock it down so that the app can't, eg, make outbound network >> connections, right? > > Or AppArmor, if you are needing to lock down just the network accessable > software, it could be much simpler to configure than trying to do a solid > job with SELinux (and for a case like this, you really need a solid job, > just useing a distro default is not likely to be tight enough to help > against this specific threat) > > David Lang
Based on an off-list response I got, I am very inclined to believe the problem is in the vendor supplied files (either the binaries or the php files) and not the framework or our code. Google results show similar symptoms at other installs of the same software (http://www.google.com/search?hl=en&biw=1243&bih=848&q=inurl%3A.edu+inurl%3Acdm4+viagra&aq=f&aqi=&aql=&oq=). As a result of that we are holding off on any restoration until we can get an answer from the vendor. (We've been trying unsuccessfully to contact their support.) -- Thanks Jefferson Cowart [email protected] _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
