linux security - Aug 1998 - Problem with TCP_wrappers

Hi,

I''m running into something weird here.
I''m using RH5.1 with tcp_wrappers 7.6.

The syntax for hosts.allow and hosts.deny is:
<service list> : <access list> [ : <shell_command> ]

Everything works when I _don''t_ use the shell_command.
I used the _exact_ line as in the man-pages utilising "safe_finger"
(comes
with tcp_wrappers), tcpdchk will break on it. And the tcp_wrappers will
"ignore" the line, in my test I used a default deny and opened up ftp
to
all and put the safe_finger line in; result: I can''t ftp to localhost
or
from any other machine via TCP/IP...

Does anybody know if this is standard behaviour under RH5.1 ?
I do like to use the feature to log all the info tcp_wrappers can obtain
about the remote-side.
The tcp_wrappers also have a special compile-time-option which gives more
functionality with all the rules, but then you have to combine all the rules
into _one_ file "hosts.access" (I think!), and hosts.{allow,deny}
don;t
function. But it doesn''t look like it''s compiled that way
(-DPROCESS_OPTIONS)...

Can somebody shine a light on this ?
Thanks in advance!

Greetings,
Jan-Philip Velders

<jpv@aacc.nl
<jpv@jvelders.tn.tudelft.nl>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Nederlandse Linux GebruikersGroep : http://www.nllgg.nl |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Jan-Philip Velders wrote:
[...]
: I''m using RH5.1 with tcp_wrappers 7.6.
[...]
: The tcp_wrappers also have a special compile-time-option which gives more
: functionality with all the rules, but then you have to combine all the rules
: into _one_ file "hosts.access" (I think!), and hosts.{allow,deny}
don;t
: function. But it doesn''t look like it''s compiled that way
: (-DPROCESS_OPTIONS)...

	I think tcp_wrappers 7.6 was built using -DPROCESS_OPTIONS.
At least the "twist" keyword works for me in hosts.{allow,deny}
(see the hosts_options(5) manpage). I don''t know anything about the
hosts.access file, though.

	When we are on this topic, I am still having problems with
the "setenv" keyword in the hosts.{allow,deny}. It simply does not
work for me. I have tried to use the "setenv" keyword for
qmail''s incoming
mail:

tcp-env: ALL@.local.domain : setenv RELAYCLIENT

	The environment variable is not set for the tcp-env.
I have to change this line to the following:

tcp-env: ALL@.local.domain : twist /path/relayclient

where the /path/relayclient is the following script

#!/bin/bash
export RELAYCLIENT
/var/qmail/bin/tcp-env ... ...

	It works, but gives me a "twist" syslog message for each connection.
On RH4.2 the tcp_wrappers'' setenv worked OK. In 5.0 and 5.1 it does not
work.

-Yenya

--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>      
http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
If there are race conditions in programs fix them. The "my programs suck
fix
something else" mentality leads you to things like Java.         -- Alan
Cox

On Wed, 5 Aug 1998, Jan Kasprzak wrote:
> 	When we are on this topic, I am still having problems with
> the "setenv" keyword in the hosts.{allow,deny}. It simply does
not
> work for me. I have tried to use the "setenv" keyword for
qmail''s incoming
> mail:
>
> tcp-env: ALL@.local.domain : setenv RELAYCLIENT
We had this problem.  Turns out to be a bug which RH thought they''d
squished in an update to 5.0, but the patch seemed to have gone astray.

There''s an unofficial RPM which fixes this at:

ftp://ftp.uk.linux.org./pub/linux/alan/Security/

Matthew.

Jan Kasprzak:
> the "setenv" keyword in the hosts.{allow,deny}. It simply does
not
> work for me. I have tried to use the "setenv" keyword for
qmail''s incoming
> mail:
>
> tcp-env: ALL@.local.domain : setenv RELAYCLIENT
In the HOSTS_OPTIONS(5) manual page, I wrote:

       setenv name value
              Place  a  (name, value) pair into the process envi-
              ronment. The value is subjected to %<letter> expan-
              sions  and  may contain whitespace (but leading and
              trailing blanks are stripped off).

Translation: you need to specify a value for the RELAYCLIENT variable.

	Wietse

Hi,

I want to thank everyone who was kind enough to mail me things.

Problem was I didn''t find "-DPROCESS_OPTIONS" in the Makefile
(I installed
the updated .src.rpm... etc.).

Seems RedHat 5.1 is compiled with it, a notice in the docs, or man-pages
might help...

Anyway, solution is to use this "spawn <shell-command>".
(another option "twist" passes the connection to the
"command" instead of
running the specified daemon)

Again, thanks to everyone!

Greetings,
Jan-Philip Velders

<jpv@jvelders.tn.tudelft.nl>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Nederlandse Linux GebruikersGroep : http://www.nllgg.nl |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On Wed, 5 Aug 1998, Wietse Venema wrote:
> Jan Kasprzak:
> > the "setenv" keyword in the hosts.{allow,deny}. It simply
does not
> > work for me. I have tried to use the "setenv" keyword for
qmail''s incoming
> > mail:
> >
> > tcp-env: ALL@.local.domain : setenv RELAYCLIENT
>
> In the HOSTS_OPTIONS(5) manual page, I wrote:
>
>        setenv name value
>               Place  a  (name, value) pair into the process envi-
>               ronment. The value is subjected to %<letter> expan-
>               sions  and  may contain whitespace (but leading and
>               trailing blanks are stripped off).
Redhat-5.1 shipped a broken tcp_wrappers in which setenv does not work. We
discovered this the hard way when we upgraded 4.2->5.1.

RedHat released a rapid update when we traced our qmail problem to
tcp_wrappers. Get the tcp_wrappers update and you should be laughing.

Cheers
Chris

Wietse Venema:
> What is the problem with a non-empty RELAYCLIENT variable?
Jan Kasprzak:
> 	Qmail appends its contents to the envelope destination address,
> so it has to be empty. I hope vmailer will be better :-)
> Again, how can I "setenv" an empty variable in tcp-wrappers?
That would involve two small code changes: one to change the syntax
of the `setenv'' option; one change to use an empty string as default.

Untested patch follows; it probably works, but given the structure
of the code it is pretty straightforward to fix if need be.

	Wietse

*** ./options.c-	Thu Aug  6 16:17:52 1998
--- ./options.c	Thu Aug  6 16:19:48 1998
***************
*** 116,122 ****
      "spawn", spawn_option, NEED_ARG | EXPAND_ARG,
      "twist", twist_option, NEED_ARG | EXPAND_ARG | USE_LAST,
      "rfc931", rfc931_option, OPT_ARG,
!     "setenv", setenv_option, NEED_ARG | EXPAND_ARG,
      "nice", nice_option, OPT_ARG,
      "severity", severity_option, NEED_ARG,
      "allow", allow_option, USE_LAST,
--- 116,122 ----
      "spawn", spawn_option, NEED_ARG | EXPAND_ARG,
      "twist", twist_option, NEED_ARG | EXPAND_ARG | USE_LAST,
      "rfc931", rfc931_option, OPT_ARG,
!     "setenv", setenv_option, OPT_ARG | EXPAND_ARG,
      "nice", nice_option, OPT_ARG,
      "severity", severity_option, NEED_ARG,
      "allow", allow_option, USE_LAST,
***************
*** 429,434 ****
--- 429,436 ----
  {
      char   *var_value;

+     if (value == 0)
+ 	value = "";
      if (*(var_value = value + strcspn(value, whitespace)))
  	*var_value++ = 0;
      if (setenv(chop_string(value), chop_string(var_value), 1))