Philosophy of xinetd

Please help me understand the philosophy of xinetd.

Here's what we know about it from the man page and from poking around:

* xinetd is a super server that listens on all ports it's configured
for

* it only fires a service to handle the request if necessary, and then
unloads the service

* it's a different strategy then loading a service on bootup from
something like /etc/inittab or other loaded sequence of Bash files
(rc, rc.sysinit)

* it was designed to conserve memory


However, I have some problems understanding it's philosophy for these
reasons:

* It's sort of like Windows' new feature called svchost.exe. You see
this task in memory and don't know if it's a virus pretending to be
svchost.exe or if it's the real svchost.exe that loads a particular
service as a "super server".

* One could create a virus or exploit that causes xinetd to be the
only thing visible in memory, cloaking itself, similar to how some
Windows viruses now use svchost.exe to cloak themselves. (Or perhaps I
misunderstand, so please straighten me out.)

* Why not just load services in memory as something that listens on a
port with a small memory footprint, then calls the other libraries
(consuming more memory) on the fly? Isn't that how most of the
services work from /etc/inittab, anyway?

* It makes you have to look in more than one command-line place for
what's being loaded into memory.


Here's what I propose for a future version Linux distro that is more
clean:

* Elimintation of xinetd. Instead, each service loads pretty much the
same way -- either a small or large footprint executable that loads in
memory as a socket service, then calls other libraries into memory
dynamically to service requests. If the service needs high
availability, then perhaps a large footprint is necessary. If it needs
minimal availability, then perhaps a small footprint is necessary.

* One Bash script on bootup -- /etc/inittab -- instead of having
/etc/inittab call multiple other files like rc, rc.sysinit, etc. It
simplifies things.

* All services can clearly be seen here by a single entry in
/etc/inittab that shows a for loop that cycles through /etc/init.d
directory. Want to add your new service? Fine -- just stick it as a
Bash script in /etc/init.d and there it will load on boot.

* Create subdirectories under /etc/init.d for the different run levels
if you want to have a situation where your service only runs under
certain run levels, rather than all of them.

* I think perhaps the word "inittab" is a bit too geeky and perhaps
the word "booter" or "autorun" might be more suitable, but too many
people give advice like, "You need to load that in /etc/inittab" and
we've kind of gotten used to it and stuck with it, so /etc/inittab it
is.


Again, I do not suppose that I'm Linux Gifted & Talented, so please do
straighten me out here if I have misconception. And if you think I'm
right on target and have some good suggestions, I welcome your
feedback. Thanks.


Google Mike

On 25 Jul 2004 06:45:20 -0700, Google Mike wrote:
>
> * it only fires a service to handle the request if necessary, and then
> unloads the service

Service unloads it's self when it is done.


> * it was designed to conserve memory

Hmmm, has more security features.

> However, I have some problems understanding it's philosophy for these
> reasons:
>
> * It's sort of like Windows' new feature called svchost.exe. You see
> this task in memory and don't know if it's a virus pretending to be
> svchost.exe or if it's the real svchost.exe that loads a particular
> service as a "super server".

If your box has been cracked and replaced xinetd, you have bigger problems
than worying about xinetd being a virus.

> * One could create a virus or exploit that causes xinetd to be the
> only thing visible in memory, cloaking itself, similar to how some
> Windows viruses now use svchost.exe to cloak themselves. (Or perhaps
> I misunderstand, so please straighten me out.)

Process cannot cloak themselfs. You have to modify ps to not show the virus.


> * Why not just load services in memory as something that listens on a
> port with a small memory footprint, then calls the other libraries

What you are missing is that any services xinetd called, can have
restrictions placed in their config file making that service custom
fitted to your security requirements.

The service file in /etc/xinetd.d can have the extra restricitons placed on
the service. Some examples
access_times = 2:00-8:59 12:00-23:59
redirect = 128.138.202.20 23
bind = 127.0.0.1
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
server_args = -s /tftpboot
only_from = 128.138.209.0
deny_time = 60

You might try the command
locate xinetd | grep /doc
to see if there is anything of interest to cut/paste into your browser.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Google Mike <(E-Mail Removed)> suggested:
[..]

> Here's what I propose for a future version Linux distro that is more
> clean:

It remains unclear if this was a nice try of trolling?

Did it ever occure to you, to ask this simple question:

"What is Linux?

Linux is a clone of the operating system Unix, written from
scratch by Linus Torvalds with assistance from a loosely-knit
team of hackers across the Net. It aims towards POSIX and Single
UNIX Specification compliance.

It has all the features you would expect in a modern
fully-fledged Unix, including true multitasking, virtual memory,
shared libraries, demand loading, shared copy-on-write
executables, proper memory management, and TCP/IP networking."

[ from www.kernel.org ]

Now, Linux belongs to a family of OS, called unix, the great
thing about it, if you know one, it isn't really hard to work
with another. You are free to develop your own OS, but your
proposed changes would simply be against "what is Linux".

If you want to run M$, simply do it, if you want Linux, simply
learn it. There are for sure enough knowledgeable people out
here, willing to get you going if you have a problem and ask us.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBA8QTAkPEju3Se5QRAuerAJ9bRLncVyw1fc+ZamjSKH nD/83IpwCgn5Iv
8bO74k4MPwW/9SvDRxwTqw4=
=SENr
-----END PGP SIGNATURE-----

Take a course in basic *ix OS's. xinetd is setup the way it is for a
reason - learn it, before trying to change it - P.S. Are you an exec
or manager? Both are always wanting to change what they don't
understand, without understanding what it is they are changing.

--

Star Fleet Admiral Q @ your service
--------------------------------------------------------
"Google Mike" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Please help me understand the philosophy of xinetd.
>
> Here's what we know about it from the man page and from poking
around:
>
> * xinetd is a super server that listens on all ports it's configured
> for
>
> * it only fires a service to handle the request if necessary, and
then
> unloads the service
>
> * it's a different strategy then loading a service on bootup from
> something like /etc/inittab or other loaded sequence of Bash files
> (rc, rc.sysinit)
>
> * it was designed to conserve memory
>
>
> However, I have some problems understanding it's philosophy for
these
> reasons:
>
> * It's sort of like Windows' new feature called svchost.exe. You see
> this task in memory and don't know if it's a virus pretending to be
> svchost.exe or if it's the real svchost.exe that loads a particular
> service as a "super server".
>
> * One could create a virus or exploit that causes xinetd to be the
> only thing visible in memory, cloaking itself, similar to how some
> Windows viruses now use svchost.exe to cloak themselves. (Or perhaps
I
> misunderstand, so please straighten me out.)
>
> * Why not just load services in memory as something that listens on
a
> port with a small memory footprint, then calls the other libraries
> (consuming more memory) on the fly? Isn't that how most of the
> services work from /etc/inittab, anyway?
>
> * It makes you have to look in more than one command-line place for
> what's being loaded into memory.
>
>
> Here's what I propose for a future version Linux distro that is more
> clean:
>
> * Elimintation of xinetd. Instead, each service loads pretty much
the
> same way -- either a small or large footprint executable that loads
in
> memory as a socket service, then calls other libraries into memory
> dynamically to service requests. If the service needs high
> availability, then perhaps a large footprint is necessary. If it
needs
> minimal availability, then perhaps a small footprint is necessary.
>
> * One Bash script on bootup -- /etc/inittab -- instead of having
> /etc/inittab call multiple other files like rc, rc.sysinit, etc. It
> simplifies things.
>
> * All services can clearly be seen here by a single entry in
> /etc/inittab that shows a for loop that cycles through /etc/init.d
> directory. Want to add your new service? Fine -- just stick it as a
> Bash script in /etc/init.d and there it will load on boot.
>
> * Create subdirectories under /etc/init.d for the different run
levels
> if you want to have a situation where your service only runs under
> certain run levels, rather than all of them.
>
> * I think perhaps the word "inittab" is a bit too geeky and perhaps
> the word "booter" or "autorun" might be more suitable, but too many
> people give advice like, "You need to load that in /etc/inittab" and
> we've kind of gotten used to it and stuck with it, so /etc/inittab
it
> is.
>
>
> Again, I do not suppose that I'm Linux Gifted & Talented, so please
do
> straighten me out here if I have misconception. And if you think I'm
> right on target and have some good suggestions, I welcome your
> feedback. Thanks.

In article <kpsct1-(E-Mail Removed)>, Michael Heiming wrote:
>In comp.os.linux.networking Google Mike <(E-Mail Removed)> suggested:
>[..]
>
>> Here's what I propose for a future version Linux distro that is more
>> clean:
>
>It remains unclear if this was a nice try of trolling?

Nah, I suspect it's a lack of understanding. He was posting over in
the bogus newsgroup "comp.os.linux.redhat" about some problem of
starting/stopping network services. Being a bogus group (see the
posting to news.announce.newgroups and news.groups,news.lists.misc
titled "List of Big Eight Newsgroups" on the 15th of each month), he
not getting adaquate answers for his problem. I think he _is_
trying, but is just going about it wrong. If I recall correctly,
(and I'm to lazy to look at groups.google.com), he's mucking with tfpt.

I'll admit I crack up on his "one Bash script" idea. Even DOS used
config.sys _and_ autoexec.bat, and that was before microsoft created
windoze 1.0. win95 had that registry idea, and we all know what
happens to that when a mosquito farts within 50KM of the computer.

I don't know about you, but I am responsible for fifty plus servers,
each one somewhat different. I can't imagine trying his idea of a single
boot script that might work for all. I don't have that kind of time.

Old guy

In article <(E-Mail Removed)>, Moe Trin wrote:
>trying, but is just going about it wrong. If I recall correctly,
>(and I'm to lazy to look at groups.google.com), he's mucking with tfpt.
Arrrrrrrgggggggghhhhhhhhhh!!!!!!

Damn fingers not following orders!

(and I'm to lazy to look at groups.google.com), he's mucking with tftp.

Sorry about that.

Old guy

~
~
~
~

(E-Mail Removed) (Google Mike) writes:

]Please help me understand the philosophy of xinetd.

]Here's what we know about it from the man page and from poking around:

]* xinetd is a super server that listens on all ports it's configured
]for

]* it only fires a service to handle the request if necessary, and then
]unloads the service

]* it's a different strategy then loading a service on bootup from
]something like /etc/inittab or other loaded sequence of Bash files
](rc, rc.sysinit)

]* it was designed to conserve memory


]However, I have some problems understanding it's philosophy for these
]reasons:

]* It's sort of like Windows' new feature called svchost.exe. You see
]this task in memory and don't know if it's a virus pretending to be
]svchost.exe or if it's the real svchost.exe that loads a particular
]service as a "super server".

You do not know if init is a virus, if it comes to that. If your system
has been root comprimised, you have much greater worries than xinetd being
comprimised.


]* One could create a virus or exploit that causes xinetd to be the
]only thing visible in memory, cloaking itself, similar to how some
]Windows viruses now use svchost.exe to cloak themselves. (Or perhaps I
]misunderstand, so please straighten me out.)

Yes, but it runs as root, and cvan only be removed by root.Ie, the attacker
would have to be root.


]* Why not just load services in memory as something that listens on a
]port with a small memory footprint, then calls the other libraries
](consuming more memory) on the fly? Isn't that how most of the
And any of those could also be spoofed.
]services work from /etc/inittab, anyway?

]* It makes you have to look in more than one command-line place for
]what's being loaded into memory.

Only xinetd is loaded into memory. \none of the other things are.


]Here's what I propose for a future version Linux distro that is more
]clean:

]* Elimintation of xinetd. Instead, each service loads pretty much the
]same way -- either a small or large footprint executable that loads in
]memory as a socket service, then calls other libraries into memory
]dynamically to service requests. If the service needs high
]availability, then perhaps a large footprint is necessary. If it needs
]minimal availability, then perhaps a small footprint is necessary.

]* One Bash script on bootup -- /etc/inittab -- instead of having
]/etc/inittab call multiple other files like rc, rc.sysinit, etc. It
]simplifies things.

]* All services can clearly be seen here by a single entry in
]/etc/inittab that shows a for loop that cycles through /etc/init.d
]directory. Want to add your new service? Fine -- just stick it as a
]Bash script in /etc/init.d and there it will load on boot.

]* Create subdirectories under /etc/init.d for the different run levels
]if you want to have a situation where your service only runs under
]certain run levels, rather than all of them.

]* I think perhaps the word "inittab" is a bit too geeky and perhaps
]the word "booter" or "autorun" might be more suitable, but too many
]people give advice like, "You need to load that in /etc/inittab" and
]we've kind of gotten used to it and stuck with it, so /etc/inittab it
]is.


]Again, I do not suppose that I'm Linux Gifted & Talented, so please do
]straighten me out here if I have misconception. And if you think I'm
]right on target and have some good suggestions, I welcome your
]feedback. Thanks.

(E-Mail Removed) (Google Mike) said:
>Please help me understand the philosophy of xinetd.
....
>* it only fires a service to handle the request if necessary, and then
>unloads the service

xinetd can also leave the process running once it is started -- and
anyway "unloading" is tasked to the underlying process.

>* it's a different strategy then loading a service on bootup from
>something like /etc/inittab or other loaded sequence of Bash files
>(rc, rc.sysinit)

Yes; both startup methods have their merits. There are things that
are needed to start at bootup (even some that don't have any network
interface), then there are things that should happen triggered by
certain network events. It'd actually be very nice to have all the
network-triggerable services start by inetd, and only have those that
are not network-related started by the inittab subsystems. This'd
make a clear separation, but unfortunately there are practical reasons
making this impossible (mostly efficiency issues).

>* it was designed to conserve memory

Perhaps also that. It also provides a single piece of software to handle
intriacies of network connections for small, simple servers. The
underlying server programs can be written without any knowledge of the
networking APIs -- even programs that weren't initially desgined for such
use can in some cases be used through xinetd as network services. Xinetd
also provides a consistent way of configuring TCP wrapper protection for
services (along with other usage limitations). As an example, a very
simple time-of-day service could be built by having inetd run 'date'
when it receives a connection request for some pre-defined TCP port.

>However, I have some problems understanding it's philosophy for these
>reasons:
>
>* Why not just load services in memory as something that listens on a
>port with a small memory footprint, then calls the other libraries
>(consuming more memory) on the fly? Isn't that how most of the
>services work from /etc/inittab, anyway?

Mmm.. so, instead of one multi-purpose xinetd you're proposing multiple
near-copies of the same functionality, each with its own configuration
style, each with its own feature set, and each with its own bugs?

>* It makes you have to look in more than one command-line place for
>what's being loaded into memory.

If that's a real problem, frontends can be written (and to some extent
do exist) that allow you to view/change the set of active services.
If you have a RedHat system, have a look at commands chkconfig and
service (both text-mode, very basic tools).

>* One Bash script on bootup -- /etc/inittab -- instead of having
>/etc/inittab call multiple other files like rc, rc.sysinit, etc. It
>simplifies things.

In some universes, yes. In others, it might not. Modular construction
is typically much easier to change programmatically (and in case of
malfunction of the program that modifies the startup, the damage is
usually much smaller than in the case of a program that attempts
modification of a single huge script). This same is also partial reason
of xinetd having a single-service-per-file configuration model, as
opposed to the previous inetd model that only had one inetd.conf file
that controlled all the services available through inetd.

Note also that inittab controls also things happening at stages other
than system bootup (powerfail, powerokwait, ctrlaltdel).

>* All services can clearly be seen here by a single entry in
>/etc/inittab that shows a for loop that cycles through /etc/init.d
>directory. Want to add your new service? Fine -- just stick it as a
>Bash script in /etc/init.d and there it will load on boot.

You're confusing mechanisms with interfaces. Provide a solid, software-
controllable mechanism, and on top of that good interface programs.
Still, keep the mechanism such that the interface programs are not
necessary (so, in case of problems, the mechanism can also be controlled
manually). This is a hard balance to achieve, but xinetd and the modular
startup system are getting very close.

But wait, with the above you're diverging from your "one script to start
them all" -model. And with this, you're very close to the current
situation -- rc is the script that loops through the others, and takes
runlevel designations as parameters.

rc.sysinit also has it's own specific task: it checks the system after
powerup, and performs certain hardware initialisation tasks to prepare
the system so that the startup scripts can be written with the expection
of system being in a sane state: all permanently attached disk devices
available; raid systems initialised, certain temporary files cleaned
up, filesystems checked for consistency, ... . Sysinit doesn't start
services (ok, depends on definition of service, but consider it more
checking/starting the userland part of system infrastructure).

>* I think perhaps the word "inittab" is a bit too geeky and perhaps
>the word "booter" or "autorun" might be more suitable, but too many
>people give advice like, "You need to load that in /etc/inittab" and
>we've kind of gotten used to it and stuck with it, so /etc/inittab it
>is.

What's in a word? Autorun would be especially bad choice for its
semantics in Windows world -- it's something to run automatically
when a media is inserted -- and inittab isn't at all concerned with
what happens when a new media is inserted. Booter? Well, in a way,
at the time when init gets to run, the OS is already booted and is
running.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Thank you for your eloquent response, direct and to the point.

I appreciate the interesting dialogue on this discussion. All are
right when they say that if someone has compromised xinetd, they'd
have to be root, and if they were root, I'd have far more problems
than xinetd being compromised. I was trying to think of it in the
concept of Windows, where certain versions of IE have been exploited
and a payload has been delivered on certain PCs that end up as a worm
being hosted by svchost.exe, even though there are legitimate
svchost.exe's in memory for legitimate Microsoft services. I was
trying to apply the same kind of concept to Linux to see if it's a
concern I should have.

Then, from a cosmetic point of view, I was thinking that a cleaner
boot process and a consistent way to have services loaded and managed
was just aesthetically prettier to me.

Someone asked if I'm a manager and said I act like I think like a
manager. Yep, I am. IT Operations. If one can classify, wholesale, how
a manager thinks differently than others, and get it right 100% of the
time, heck, I'd buy that book.

Someone, I think, asked if I'm new to Linux. I've been on RH8 and RH9
since one month after RH8 was released. I guess that makes me 2 years
old in Linux years. I used to be a Microsoft fan, and was employed by
Microsoft twice, before I turned against the organization violently
and went Linux, sink-or-swim, two years ago. I'm now pro-Linux and
pro-PHP. However, I am a fan of simplicity, so I like to encourage it
anywhere I see opportunities. There will be those who have different
points of view, and that's okay. Linux comes from Unix, and Unix was
an amalgamation of personal viewpoints.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2004-07-26, Google Mike <(E-Mail Removed)> wrote:
>
> Then, from a cosmetic point of view, I was thinking that a cleaner
> boot process and a consistent way to have services loaded and managed
> was just aesthetically prettier to me.

Not all linux distros use the SysV init style. Slackware, for example,
uses one script, /etc/rc.d/rc.M, to be launched in runlevels 2345, so
there are no /etc/rc?.d/ directories by default, and everything is more
or less run in every runlevel. (xdm, in runlevel 4, has its own script
that is configured in inittab as well.) This is commonly called
BSD-style, though it's a bit of a combination of styles by now.

The drawback is that a typical Slackware machine really has three
runlevels: 1, (235), and 4. But how often does anyone use runlevel 2 in
RedHat, for example? So it's a slight drawback, but not a huge one.

> However, I am a fan of simplicity, so I like to encourage it
> anywhere I see opportunities.

Sometimes you can oversimplify--having an init without an inittab would
be fairly difficult, indeed!

As far as the Subject: goes, you don't have to run xinetd at all. Many
daemons can be configured as standalone, and there are only a small
handful which require xinetd or inetd. So it's your choice to simplify
in that respect, if you wish.

- --keith

- --
kkeller-(E-Mail Removed)
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBWjAhVcNCxZ5ID8RAuoIAJ9jOVjONt8eZePziIvozh P6dC1TIACfaq+O
9/YRUvG4xoJ3Dt8VGUilcD0=
=G7c2
-----END PGP SIGNATURE-----