Daemons
hoog...@my-deja.com
I have a customer who wants all unneeded daemons deleted (not just
disabled) if they are not used. I have three issues now:
1) How do I identify all daemons that are resident on my system,
2) how do I identify which ones are used/needed?
3) Once my first issue is addressed, how do I delete the code?
TIA. Responses to list and to <choog...@acm.org>.
Sent via Deja.com http://www.deja.com/
Before you buy.
hoog...@my-deja.com
Jim Richardson
choog...@acm.org wrote:
> I am running SCO OpenServer 5.0.5 Enterprise on a Dell xps300.
>
> I have a customer who wants all unneeded daemons deleted (not just
> disabled) if they are not used. I have three issues now:
>
> 1) How do I identify all daemons that are resident on my system,
>
This is not simple or for the inexperienced. My prefered method is to
recite the twelve names of UNIX and listen for responses.
> 2) how do I identify which ones are used/needed?
>
Good daemons wear white, bad daemons green.
> 3) Once my first issue is addressed, how do I delete the code?
>
I use two chickens and a goat.
> TIA. Responses to list and to <choog...@acm.org>.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
Jim Richardson
I like NT because it constantly reminds me of my daughter.
"Honest Daddy, I wasn't doing anything and it just broke."
Tony Lawrence
>
> I am running SCO OpenServer 5.0.5 Enterprise on a Dell xps300.
>
> I have a customer who wants all unneeded daemons deleted (not just
> disabled) if they are not used. I have three issues now:
>
> 1) How do I identify all daemons that are resident on my system,
That's the easier of the two questions. Everything that SCO
supplied either starts from /etc/rc2.d, from cron, or from
/etc/indetd.conf. See http://aplawrence.com/Security for
starters.
>
> 2) how do I identify which ones are used/needed?
That's the tougher part. It's part knowledge, but you have
to realize that what you don't need today, you may need
tomorrow. And a LOT of things are inter-related.
You can identify network listeners that don't start from
inetd by a netstat -a. Everything else you'd need to track
down through ps and cron.
> 3) Once my first issue is addressed, how do I delete the code?
>
Well, I'd certainly archive them, 'cause you may regret this
foolishness. But how do you delete anything? You find that
stuff that calls it, comment out the call, and then rm the
program it called. With SCO, you have to also be aware of
symlinks, so you'd have to follow those, and if you don't
want bitching from the verification programs, you have to
adjust that database to make it happy. A lot of work.
One trick that could help is not to immediately delete, but
to rename. That way, if something fails, you can quickly
name it back.
--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com
hoog...@my-deja.com
Tony Lawrence <to...@aplawrence.com> wrote:
> hoog...@my-deja.com wrote:
<<snip>>
> That's the easier of the two questions. Everything that SCO
> supplied either starts from /etc/rc2.d, from cron, or from
> /etc/indetd.conf. See http://aplawrence.com/Security for
> starters.
Thanks, some good stuff to read.
>
> >
> > 2) how do I identify which ones are used/needed?
>
> That's the tougher part. It's part knowledge, but you have
> to realize that what you don't need today, you may need
> tomorrow. And a LOT of things are inter-related.
>
> You can identify network listeners that don't start from
> inetd by a netstat -a. Everything else you'd need to track
> down through ps and cron.
ps is a snapshot of the system. Is there any way of capturing a list of
what is run over time? I.e., if I run my system for a couple of days,
could I get a list of what has been run during that time?
>
> > 3) Once my first issue is addressed, how do I delete the code?
> >
>
> Well, I'd certainly archive them, 'cause you may regret this
> foolishness. But how do you delete anything? You find that
> stuff that calls it, comment out the call, and then rm the
> program it called. With SCO, you have to also be aware of
> symlinks, so you'd have to follow those, and if you don't
> want bitching from the verification programs, you have to
> adjust that database to make it happy. A lot of work.
>
> One trick that could help is not to immediately delete, but
> to rename. That way, if something fails, you can quickly
> name it back.
Foolishness? Maybe, maybe not. Unfortunately, we are in the business
of getting paid by our customer. We have advised them that this may be
a bit more work than it is worth, but....
Thanks a bunch for the suggestions.
Tom Parsons
| I am running SCO OpenServer 5.0.5 Enterprise on a Dell xps300.
|
|
| I have a customer who wants all unneeded daemons deleted (not just
| disabled) if they are not used. I have three issues now:
Three step process:
Tell the customer it can't be done
He fires you and eventually finds someone who tries it.
He comes back to you to fix the mess (and the rate goes up, up, up).
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Tony Lawrence
>
> In article <38BFD010...@aplawrence.com>,
> Tony Lawrence <to...@aplawrence.com> wrote:
>
> > You can identify network listeners that don't start from
> > inetd by a netstat -a. Everything else you'd need to track
> > down through ps and cron.
>
> ps is a snapshot of the system. Is there any way of capturing a list of
> what is run over time? I.e., if I run my system for a couple of days,
> could I get a list of what has been run during that time?
Sure. Something like:
while true
do
ps -e -o args= >> /tmp/t1
sort -u -o /tmp/t1 /tmp/t1
sleep 60
done
would catch all but the shortest lived things. You'd need
to be much more sophisticated to capture when they ran.
Another way to identify things that run is to do find
looking for executables with new atimes.
Abid Khan
James R. Sullivan
Tom Parsons wrote:
>
> hoog...@my-deja.com enscribed:
> | I am running SCO OpenServer 5.0.5 Enterprise on a Dell xps300.
> |
> |
> | I have a customer who wants all unneeded daemons deleted (not just
> | disabled) if they are not used. I have three issues now:
>
> Three step process:
>
> Tell the customer it can't be done
>
> He fires you and eventually finds someone who tries it.
>
> He comes back to you to fix the mess (and the rate goes up, up, up).
Best answer I've seen yet. Unneeded daemons consume little to no
resources on the system. Their only cost is a slower startup, but
with parallel startups, even this is minimal. Once a daemon is running,
it generally sits in the sleep queue waiting for the event which it
is designed for. It consumes no CPU, small amount of disk, and,
on a busy system, eventually no memory, since it will get swapped out.
The cost of removing them far exceeds the benefits. And will result
in such a non-standard, borken system that any other UNIX admin who
comes along will think you an idiot for doing it and curse your name
to the customer, even though it isn't your fault.
Just say no.
--
Jim Sullivan
Manager, Applied Technology Group
SCO www.sco.com
831 427 7108 - j...@sco.com
Tony Lawrence
> > hoog...@my-deja.com enscribed:
> > | I am running SCO OpenServer 5.0.5 Enterprise on a Dell xps300.
> > |
> > |
> > | I have a customer who wants all unneeded daemons deleted (not just
> > | disabled) if they are not used. I have three issues now:
> >
> > Three step process:
> >
> > Tell the customer it can't be done
> >
> > He fires you and eventually finds someone who tries it.
> >
> > He comes back to you to fix the mess (and the rate goes up, up, up).
> >
> ========================================================================
> ==
> > Tom Parsons t...@tegan.com
> >
> ========================================================================
> ==
> >
> Perfect answer.
Nonsense.
There are many unnecessary daemons running on any given SCO
system. As I said in another post in this thread, though,
what's unnecessary now may not be tomorrow, so the deletion
idea is likely to cause more work than it is worth. But
disabling unwanted programs makes sense both for performance
and security.
And if, in fact, it can be shown that you never will need
certain processes, then I guess you might as well delete
them. It would bother me because I can't be sure that I'm
sure :-)
but someone else may be. For example, you might have a
firewall that you just plain are never going to allow
incoming telnet or ftp sessions. Why not remove the
binaries? It's just one extra security step- a step that
most of us wouldn't consider necessary, but it makes it that
much harder for someone to compromise the machine. Look at
it upside down for a moment: suppose you had a machine where
you had NOT installed ftp because you don't want it. Does
it make sense to install it and then uncomment it from
inetd.conf? Of course not- you'd just leave it uninstalled.
BTW, there's a nice feature on Linux (Redhat anyway, don't
know about the others) that lets you control which rc
daemons get started through an admin tool. That makes it
much easier than SCO when you are trying to secure a
machine.
Tony Lawrence
>
> Tom Parsons wrote:
> >
> > hoog...@my-deja.com enscribed:
> > | I am running SCO OpenServer 5.0.5 Enterprise on a Dell xps300.
> > |
> > |
> > | I have a customer who wants all unneeded daemons deleted (not just
> > | disabled) if they are not used. I have three issues now:
> >
> > Three step process:
> >
> > Tell the customer it can't be done
> >
> > He fires you and eventually finds someone who tries it.
> >
> > He comes back to you to fix the mess (and the rate goes up, up, up).
>
> resources on the system. Their only cost is a slower startup, but
> with parallel startups, even this is minimal. Once a daemon is running,
> it generally sits in the sleep queue waiting for the event which it
> is designed for. It consumes no CPU, small amount of disk, and,
> on a busy system, eventually no memory, since it will get swapped out.
Who said that the issue was performance? Many of the
processes started on a typical SCO system have at least the
potential for security/DOS attacks.
>
> The cost of removing them far exceeds the benefits. And will result
> in such a non-standard, borken system that any other UNIX admin who
> comes along will think you an idiot for doing it and curse your name
> to the customer, even though it isn't your fault.
Maybe- but when I see people sitting on the Internet with
stock SCO systems, I'm more apt to think that they are the
idiots. I'd consider someone who judiciously disables these
things smart, and someone who went to the trouble of
deleting them as unusually cautious, but certainly not an
idiot.
I don't remove binaries on this machine (the one I'm posting
from), but there isn't a single uncommented line in
inetd.conf and several of the rc scripts have exit 0 at
their top. Therefore there's little or nothing running
that isn't necessary. The reasons for that have absolutely
nothing to do with performance and everything to do with
security.
If you don't need something, it shouldn't be running.
Period.
hoog...@my-deja.com
Tony Lawrence <to...@aplawrence.com> wrote:
>
> Sure. Something like:
>
> while true
> do
> ps -e -o args= >> /tmp/t1
> sort -u -o /tmp/t1 /tmp/t1
> sleep 60
> done
>
> would catch all but the shortest lived things. You'd need
> to be much more sophisticated to capture when they ran.
>
Thanks, your snippet is running even as I write this. I did cut the
sleep down a bit and I'll leave it running over the weekend while
pumping traffic thru the system.
BTW, You are correct in your other responses re: reasons for removing
code. My customer is very interested in the security aspects so your
web reference was appropriate as well.