ALERT ALERT plaintext passwords in linux ALERT ALERT

[silvio () big net au (silvio () big net au)]

On Sun, Sep 15, 2002 at 07:22:33PM -0400, Michal Zalewski wrote:
> Yes and no. A fair number of PIDs is not available to mere mortals. On a
> typical Linux, 0-300 and 32768-65535 are protected one way or another, yet
> it's perfectly possible for a hiding process to claim one of those...

yes. the point isnt that this is 100% garaunteed to work.. but probably gets
back to DOS AV days since everyone has full access to the system.

> plus, "exclusive" use is not really guaranteed, two processes can share a
> single PID (older Linuxes, 2.0, even allowed you to do that from
> user-space with clone(), now it requires some hacking).
 
correct.. CLONE_PID can do some stuff with this.  of course, gdb doesnt
support clone directly btw, but just the linuxthreads debugging api
sitting ontop of it.. likewise for strace/ltrace etc.

of course, posix gets broken by linux here in current linuxthreads
implementation (i think ngpt comes close to posix - almost fully?).

> > note that on linux recycling the pid's goes back to 300..  a sysctl
> > would be nice here to set this figure.
>
> This mechanism is fairly bogus. I imagine it is supposed to speed things
> up and perhaps keep things in order - lower pids are supposed to be
> occupied by daemons after boot-up. In reality, however, a typical start-up
> sequence for recent Red Hat distros - and, I imagine, most other Linuxes -
> is so blown up that first daemons will be started with PIDs closer to
> 400-500. The mechanism, as such, is quite pointless, just wasting 300
> PIDs.

yah.. the theory is that daemon processes are occuping this range.

--
Silvio