On Thursday 08 May 2003 02:55, GertJan Spoelman wrote:
On Thursday 08 May 2003 04:31, Paul Kozlenko wrote:
On Wednesday 07 May 2003 18:58, GertJan Spoelman wrote:
On Thursday 08 May 2003 00:12, Paul Kozlenko wrote:
FWIW netstat -patn|grep 33270 gives me:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity)
You're probably running a kernel which has the fix for the ptrace hole. The downside of that fix was that even root doesn't seem to have the right to show the information for all processes anymore, for example if I look at nfs which uses port 2049 I see the same, there is no PID or Program name shown for that port. On my systems I also see such lines for high ports, I don't know which process uses them, but you should be able to find that out by shutting them down one by one and watch when that port disappears.
My kernel version is Linux version 2.4.19-4GB (SuSE 8.1 Professional) How do I find out if this has the "ptrace hole" fix?
Check the changelog of your kernel package, the first entry here says: - fix ptrace security hole you can extract the changelog by doing: rpm -q --changelog
You probably have a k_deflt kernel rpm package installed, the exact name and version you can find by: rpm -qa | grep k_deflt The latest which I have is k_deflt-2.4.19-274 and that has the fix.
On Thursday 08 May 2003 04:41, Paul Kozlenko wrote:
More info (... reminder to self, always check log files ....)
/var/log/warn contains a line: May 7 22:00:07 machinename kernel: lockd: connect from unprivileged port: 172.20.43.21:52353
For each attempted connect. This is a good thing that this is detected. YES? Does it mean that I am safe though?
I don't think so, it's only detected and logged. --
GertJan
Email address is invalid, so don't reply directly, I'm on the list. The kernel patch level on this machine is 74 not 274. Am I that far behind? Anyhow. No reference to "ptrace" when I do an rpm -q --chnagelog k_deflt.
A netstat -ean shows one piece of info - the inode is "31464". Does this equal the inode for a file. If so 31464 is the inode for a directory. In my case "/usr/libexec/webmin/mscstyle3/acl/images". I haven't rebooted the machine yet. I don't want to unless this is a threat. Thanks Again - Paul