RE: 2.4.16 release, ipsec, roles and ECHILD errors

RE: 2.4.16 release, ipsec, roles and ECHILD errors

[Westerman, Mark]

The 1.94 version  has bugs that make non-usable
From: freeswan web page
"While freeswan-1.94 has shipped, there are serious known bugs 
in it that make it unsuitable for use. You have two choices, 
use the latest snapshot (snap2001dec25b seems ok) where the 
show stopper bugs seem fixed or use an older 'stable' release 
like 1.91 or maybe 1.92 from this "

Try a different version and see if you have the same problem


Mark

-----Original Message-----
From: Paul Krumviede [mailto:pwk@acm.org]
Sent: Thursday, January 17, 2002 2:58 PM
To: selinux
Subject: 2.4.16 release, ipsec, roles and ECHILD errors


ever since the december 2001 release, i've been running into
problems getting frees/wan 1.94 working with the 2.4.16 kernel
when selinux is configured in the kernel. after much experimentation
i noticed something that seems quite strange.

background: attempts to get automatically keyed IPsec
connections to go into the "routed" or "up" states would
yield failures with pclose() with errno set to ECHILD. this
happens when pluto, the user-space key management
daemon, tries to run some of the associated scripts.

by happenstance, things started working a few days ago,
and then stopped working. what seemed to make the
difference was the role i used to login on the console.
if i login with the user_r role, run "newrole -r sysadm_r"
and su, then start (using run_init) the ipsec components
and attempt to bring an IPsec connection into a useful
state (e.g., "ipsec auto --route conn-name"), then things
fail as above.

but if i login with the sysadm_r role, su, and then start
up the ipsec components the same way, things work.
things work if i login as root, in either the user_r or
sysadm_r role.

i'm running in permissive mode, so that shouldn't
be a problem. if i compile the same kernel without
selinux, then there doesn't seem to be any problem
getting the IPsec connections up and running.

i took a quick look at some of the ssh code, which
also uses pclose(), but it seems to never check the
error status, while pluto does.

-paul


--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: 2.4.16 release, ipsec, roles and ECHILD errors

[Paul Krumviede]

--On Friday, 18 January, 2002 07:39 -0600 "Westerman, Mark" 
<Mark.Westerman@csoconline.com> wrote:

> The 1.94 version  has bugs that make non-usable

that is a bit of an overstatement. i've patched the 1.94
version to fix the most egregious bug (the one that
could leave a connection in %hold). and it does work
with kernels that don't have selinux compiled in and
earlier versions of selinux: i can see the IKE exchanges
take place and instantiate the desired tunnel and eroute.
traffic between machines does get routed through the
tunnel (as determined with a sniffer).

> From: freeswan web page
> "While freeswan-1.94 has shipped, there are serious known bugs
> in it that make it unsuitable for use. You have two choices,
> use the latest snapshot (snap2001dec25b seems ok) where the
> show stopper bugs seem fixed or use an older 'stable' release
> like 1.91 or maybe 1.92 from this "
>
> Try a different version and see if you have the same problem

i already tried it with 1.91: same symptoms.

and the failure mode i'm seeing when i login with the
user_r role, use newrole to change to the sysadm_r role,
su to root, and start the ipsec processes is a failure mode
independent of recent frees/wan versions: they all attempt
to invoke the _updown script using popen() and use pclose()
to get the status. the serious bug with 1.94 is in klips, the
kernel stuff, the pclose failure is with pluto.

and the fact that it (pclose) doesn't fail if i login with the
sysadm_r role, then su to root and proceed, implies a
problem somewhere other than in the frees/wan stuff.

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

2.4.16 release, ipsec, roles and ECHILD errors

[Paul Krumviede]

ever since the december 2001 release, i've been running into
problems getting frees/wan 1.94 working with the 2.4.16 kernel
when selinux is configured in the kernel. after much experimentation
i noticed something that seems quite strange.

background: attempts to get automatically keyed IPsec
connections to go into the "routed" or "up" states would
yield failures with pclose() with errno set to ECHILD. this
happens when pluto, the user-space key management
daemon, tries to run some of the associated scripts.

by happenstance, things started working a few days ago,
and then stopped working. what seemed to make the
difference was the role i used to login on the console.
if i login with the user_r role, run "newrole -r sysadm_r"
and su, then start (using run_init) the ipsec components
and attempt to bring an IPsec connection into a useful
state (e.g., "ipsec auto --route conn-name"), then things
fail as above.

but if i login with the sysadm_r role, su, and then start
up the ipsec components the same way, things work.
things work if i login as root, in either the user_r or
sysadm_r role.

i'm running in permissive mode, so that shouldn't
be a problem. if i compile the same kernel without
selinux, then there doesn't seem to be any problem
getting the IPsec connections up and running.

i took a quick look at some of the ssh code, which
also uses pclose(), but it seems to never check the
error status, while pluto does.

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.