Why are processes not removed from /proc?

If there is a better place to ask this, please specify it.

I have a Slackware 10 box upgraded over the years from 3.4 or so. It
is possible that the /etc directory may be my culprit because of that.

PROBLEM: privoxy and in.identd fail to remove their subdirectories in
/proc so that - over time - I wind up with 1 privoxy and a variable
number of in.identd directories where there is no running process.

Please note that privoxy runs as a daemon while in.identd is run by
inetd (wrapper). There is always at least one running privoxy
process, usually 2. There should be (I think, based on the way
Slackware 10 does things) 7 in.identd processes. Right now, ps shows
one of each.

QUESTION: What prevents a program/child process from being able to
remove its /proc directory?

If anyone has any constructive comments/suggestions/reading
material/questions/Etc, feel free!

buck

buck, sáb20041211@19:57:04(CET):
>
> QUESTION: What prevents a program/child process from being able to
> remove its /proc directory?

You cannot create or delete files from /proc.

$ LC_ALL=C mkdir /proc/$$/hithere
mkdir: cannot create directory `/proc/943/hithere': No such file or directory
$ LC_ALL=C rmdir /proc/$$
rmdir: `/proc/943': Permission denied
$ LC_ALL=C touch /proc/$$/hithere
touch: cannot touch `/proc/943/hithere': No such file or directory
$ LC_ALL=C rm /proc/$$/stat
/bin/mv: cannot remove `/proc/943/stat': Permission denied

So that's probably a kernel issue, I think.


--
David Serrano

In article <fnfmr0tu2i6knirur0ap4hhcqa4hosvq6c@4ax.com>,
buck <buck@private.mil> wrote:
:If there is a better place to ask this, please specify it.
:
:I have a Slackware 10 box upgraded over the years from 3.4 or so. It
:is possible that the /etc directory may be my culprit because of that.
:
:PROBLEM: privoxy and in.identd fail to remove their subdirectories in
:/proc so that - over time - I wind up with 1 privoxy and a variable
:number of in.identd directories where there is no running process.
:
:Please note that privoxy runs as a daemon while in.identd is run by
:inetd (wrapper). There is always at least one running privoxy
:process, usually 2. There should be (I think, based on the way
:Slackware 10 does things) 7 in.identd processes. Right now, ps shows
:one of each.
:
:QUESTION: What prevents a program/child process from being able to
:remove its /proc directory?
:
:If anyone has any constructive comments/suggestions/reading
:material/questions/Etc, feel free!

If I saw disagreement between processes reported by 'ps' and the
directories in /proc I'd be running 'chkrootkit' right away (and
probably doing a complete reinstall soon after).

http://www.chkrootkit.org/

--
Bob Nichols AT comcast.net I am "rnichols42"

On Sun, 12 Dec 2004 00:46:22 +0000 (UTC), Robert Nichols
<SEE_SIGNATURE@localhost.localdomain.invalid> wrote:

>In article <fnfmr0tu2i6knirur0ap4hhcqa4hosvq6c@4ax.com>,
>buck <buck@private.mil> wrote:
:
>:If anyone has any constructive comments/suggestions/reading
>:material/questions/Etc, feel free!
>
>If I saw disagreement between processes reported by 'ps' and the
>directories in /proc I'd be running 'chkrootkit' right away (and
>probably doing a complete reinstall soon after).
>
> http://www.chkrootkit.org/

OK, exactly what am I looking for?

I've been running chkrootkit since version 0.35.

I would never say it is impossible for the machine to have been
rooted, but I have 5 "external" machines. One of those is a DMZ (the
real external box), also running Slackware. No services, just
iptables. It NATs for the other 4 boxes, one of which is a Windows
2000 Server. If the W2K machine had ever been compromized, I'd be a
LOT more inclined to believe that the Slackware box might have been
also.

Unless your suggestions lead elsewhere, I'm first going to try
building a new kernel on an isolated computer and then get that new
kernel to the Problem Child via CD. The kernel is heavily patched for
iproute2, netfilter, and I don't remember what all - except that there
was a "VM" kernel vulnerability that I hacked in a fix for manually...

buck

In article <s6anr0h3ibrs3mb17jspa99f86f2ulaact@4ax.com>,
buck <buck@private.mil> wrote:
:On Sun, 12 Dec 2004 00:46:22 +0000 (UTC), Robert Nichols
:<SEE_SIGNATURE@localhost.localdomain.invalid> wrote:
:
:>In article <fnfmr0tu2i6knirur0ap4hhcqa4hosvq6c@4ax.com>,
:>buck <buck@private.mil> wrote:
::
:>:If anyone has any constructive comments/suggestions/reading
:>:material/questions/Etc, feel free!
:>
:>If I saw disagreement between processes reported by 'ps' and the
:>directories in /proc I'd be running 'chkrootkit' right away (and
:>probably doing a complete reinstall soon after).
:>
:> http://www.chkrootkit.org/
:
:OK, exactly what am I looking for?
:
:I've been running chkrootkit since version 0.35.
:
:I would never say it is impossible for the machine to have been
:rooted, but I have 5 "external" machines. One of those is a DMZ (the
:real external box), also running Slackware. No services, just
:iptables. It NATs for the other 4 boxes, one of which is a Windows
:2000 Server. If the W2K machine had ever been compromized, I'd be a
:LOT more inclined to believe that the Slackware box might have been
:also.

Sorry, I had no way to judge your experience level. A compromised
'ps' that hides some processes from view is often a sign of a machine
that has been hacked. That's about all I had to go on.

--
Bob Nichols AT comcast.net I am "rnichols42"

On Mon, 13 Dec 2004 05:05:55 +0000 (UTC), Robert Nichols
<SEE_SIGNATURE@localhost.localdomain.invalid> wrote:

>Sorry, I had no way to judge your experience level. A compromised
>'ps' that hides some processes from view is often a sign of a machine
>that has been hacked. That's about all I had to go on.

Robert,

I mean this in the most friendly possible way: I would far rather
have suggestions than an apology. If it is rooted, what am I looking
for?

Why would only privoxy and in.identd be affected? Would not the ps
executable or in.identd 'cmp' or 'diff' from a known OK copy? ( I scp
them to a computer at home and get no differences. I do have
differences with privoxy but I compiled that so I expect differences).

TIA,

buck

In article <ccdsr05r7lebasarm05qdu59nb988gdu5v@4ax.com>,
buck <buck@private.mil> wrote:
:On Mon, 13 Dec 2004 05:05:55 +0000 (UTC), Robert Nichols
:<SEE_SIGNATURE@localhost.localdomain.invalid> wrote:
:
:>Sorry, I had no way to judge your experience level. A compromised
:>'ps' that hides some processes from view is often a sign of a machine
:>that has been hacked. That's about all I had to go on.
:
:Robert,
:
:I mean this in the most friendly possible way: I would far rather
:have suggestions than an apology. If it is rooted, what am I looking
:for?
:
:Why would only privoxy and in.identd be affected? Would not the ps
:executable or in.identd 'cmp' or 'diff' from a known OK copy? ( I scp
:them to a computer at home and get no differences. I do have
:differences with privoxy but I compiled that so I expect differences).

It's hard to be sure those are the _only_ hidden processes. What
doesn't make sense is that 'ps' gets its information from /proc, so a
corrupted 'ps', or perhaps a corrupted library, is the only explanation
I can think of for not displaying a process that exists in /proc. AFAIK
the stuff you see in /proc is created dynamically every time it is
fetched from the kernel. If you see a directory for PID 12345, that
means that a process table entry with PID==12345 existed at the time you
did the 'ls'. Nothing ever needs to delete a directory in /proc because
that directory structure isn't actually stored anywhere, just created on
demand and immediately discarded.

Here's an odd thought --
You aren't, by any chance, NFS mounting a remote system's /proc are you?
If so, you might be seeing cached data.

--
Bob Nichols AT comcast.net I am "rnichols42"