jockc@hammer.idsila.com (PRIV Account) (02/21/91)
How can a process change or obscure the command line that ps (and other programs like w or whodo) show for it? This could obviously be desirable for security reasons, but also for informational purposes. For example, when a program forks a child process to do something, the child proc might want to change its "command line" (what ps shows, which by now probably has little meaning) to something more descriptive of what its doing. I know this is going to vary depending on system type. I'm on DS3100 Ultrix, but I'd also like to know how its done on other common systems, or where that information would be found. Thanks for any insights. Jock Cooper uunet!hammer!jockc
towfiq@FTP.COM (Mark Towfiq) (02/22/91)
In article <JOCKC.91Feb20103537@hammer.idsila.com> jockc@hammer.idsila.com (PRIV Account) writes: How can a process change or obscure the command line that ps (and other programs like w or whodo) show for it? This could obviously be desirable for security reasons, but also for informational purposes. For example, when a program forks a child process to do something, the child proc might want to change its "command line" (what ps shows, which by now probably has little meaning) to something more descriptive of what its doing. Amazingly, the situation you describe and the reasons for it are exactly the ones met by the setproctitle() call in sendmail. When it forks a child, the child describes its current status by munging its argv array. This does not work on all systems, as you suggest (such as ones which malloc() argv entries and expect them not to be clobbered) but most BSD-type systems can handle it. Check out the source for sendmail, obtainable from many many anonymous FTP hosts (such as uunet.uu.net or ucbvax.berkeley.edu). Hope this helps. -- Mark Towfiq, FTP Software, Inc. towfiq@FTP.COM Work No.: +1 617 246 0900 Home No.: +1 617 488 2818 "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
mike (02/22/91)
In an article, hammer.idsila.com!jockc (PRIV Account) writes: >How can a process change or obscure the command line that >ps (and other programs like w or whodo) show for it? > >This could obviously be desirable for security reasons, but also for >informational purposes. For example, when a program forks a child >process to do something, the child proc might want to change >its "command line" (what ps shows, which by now probably has little >meaning) to something more descriptive of what its doing. In a general sense, what you need to do is read the kernel namelist, get the symbol value for _proc which is the offset into /dev/kmem. Read the proc table, and determine if the process is in core or swapped; if it is in core, read /dev/mem, otherwise read /dev/swap, seeking to the u block forthat process (the address of the u block is in the proc table). Once you have the proc table entry and the u block for that process, you can proceed to alter u_comm and/or u_psargs to your heart's content. Obviously, you must be root to do these wonderful things. Further note that your swap device is probably not called /dev/swap. Cheers, -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
art@pilikia.pegasus.com (Art Neilson) (02/22/91)
In article <JOCKC.91Feb20103537@hammer.idsila.com> jockc@hammer.idsila.com (PRIV Account) writes: >How can a process change or obscure the command line that >ps (and other programs like w or whodo) show for it? Well, on SYSV.3 there's a field in the user struct called u_psargs which holds the args passed by exec to execute a given process. These show up as the command field in ps listings. You need to be root to write to the user struct, unless of course you are running ISC or ESIX ;^(. I don't know how this is done on berzerkley based systems like Ultrix. -- Arthur W. Neilson III | INET: art@pilikia.pegasus.com Bank of Hawaii Tech Support | UUCP: uunet!ucsd!nosc!pegasus!pilikia!art
scottl@convergent.com (Scott Lurndal) (02/22/91)
In article <JOCKC.91Feb20103537@hammer.idsila.com>, jockc@hammer.idsila.com (PRIV Account) writes: |> How can a process change or obscure the command line that |> ps (and other programs like w or whodo) show for it? |> |> This could obviously be desirable for security reasons, but also for |> informational purposes. For example, when a program forks a child |> process to do something, the child proc might want to change |> its "command line" (what ps shows, which by now probably has little |> meaning) to something more descriptive of what its doing. |> |> I know this is going to vary depending on system type. I'm on |> DS3100 Ultrix, but I'd also like to know how its done on other common |> systems, or where that information would be found. |> |> Thanks for any insights. |> |> Jock Cooper |> uunet!hammer!jockc This data is kept in the u area for the process at exec(2) time. Most operating systems don't allow a program to write to the u area; therefore you cannot change it.
lavinus@csgrad.cs.vt.edu (02/23/91)
Hi! In a C program, anyway, the way this is done is by modifying the argument vector (argv). This argument vector is what finger, w, etc. check to get the name of the process. FYI, the Internet Worm randomly changed its argument vector to various commonly-seen process names, and also occasionally forked off a copy of itself and killed off the parent, in order to change the process ID indicated by ps. So long... Joe Lavinus -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Joseph W. Lavinus = \ / = = Virginia Tech, Blacksburg, Virginia = \/__V = = email: lavinus@csgrad.cs.vt.edu = /\ =
mike@bria.commodore.com (02/23/91)
In an article, scottl@convergent.com (Scott Lurndal) writes: >This data is kept in the u area for the process at exec(2) time. >Most operating systems don't allow a program to write to the u area; >therefore you cannot change it. Untrue. Any process that can read /unix and read and write /dev/kmem and the swap device can modify the proc table and/or u block of another process. -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
guy@auspex.auspex.com (Guy Harris) (02/24/91)
>In a general sense, what you need to do is read the kernel namelist, >get the symbol value for _proc which is the offset into /dev/kmem. Read >the proc table, and determine if the process is in core or swapped; if it >is in core, read /dev/mem, otherwise read /dev/swap, seeking to the u block >forthat process (the address of the u block is in the proc table). Overly general - I suspect Ultrix doesn't keep the command line in the U area. That was done by, possibly among other, AT&T, in one of the S5 releases, for reasons not entirely obvious to me; other systems require "ps" to grab it from the process's stack, so just stomping on top of your arguments (being careful, of course, 1) to make copies of any you may need later and 2) not to stop on stuff *outside* the argument list) should suffice.
rbj@uunet.UU.NET (Root Boy Jim) (02/26/91)
In article <JOCKC.91Feb20103537@hammer.idsila.com> jockc@hammer.idsila.com (PRIV Account) writes: >How can a process change or obscure the command line that >ps (and other programs like w or whodo) show for it? Get a copy of the sendmail source and look at setproctitle. Basicly, it overwrites it's arguments. We include a line in our /etc/rc that says: FILLER=" " to leave lots to environment space to trash (comes after arguments). This works for BSD. I dunno what SV does. -- [rbj@uunet 1] stty sane unknown mode: sane