Is TCP over IPsec broken in 2.6.18?

Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

Hello.

I've found strange behaviour of transport mode IPsec in 2.6.18 tree.
After key daemons exchanged keys (I use racoon) I try following command
on 2.6.18 machine: telnet 192.168.4.79 22 (telnet from 2.6.18 to 2.6.17 based one)
and get very slow response, here is related tcpdump output:

15:15:47.396925 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x21), length 84
15:15:47.397391 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x18), length 84
15:15:47.397025 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x22), length 84
15:15:47.404166 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 2541002438:2541002458(20) ack 1601271418 win 91 
15:15:48.279375 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:15:50.031487 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:15:53.535710 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:16:00.544154 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:16:14.561064 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x19), length 100
15:16:14.561218 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x23), length 84

Unencrypted packets somehow sneaked into the wire.

ping works ok:
15:15:37.919617 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1c), length 116
15:15:37.919858 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x13), length 116
15:15:38.920772 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1d), length 116
15:15:38.920823 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x14), length 116
15:15:39.920823 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1e), length 116
15:15:39.920883 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x15), length 116
15:15:40.920848 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1f), length 116
15:15:40.920893 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x16), length 116

It was introduced somewhere in 2.6.18 development cycle and as far as I
recall not at the beginning of it (I found it porting IPsec acrypto to 2.6.18,
unfortunately I do not have version which works anymore, except 2.6.17
tree which works ok with both acrypto and vanilla trees), likely after
transport/tunnel modules introduction by Herbert Xu.

telnet from 2.6.17 tree to 2.6.18 tree works ok too:

15:24:33.428978 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x1b), length 84
15:24:33.429130 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x2d), length 84
15:24:33.429236 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x1c), length 84
15:24:33.436885 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x2e), length 100
15:24:33.436962 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x1d), length 84
15:24:35.293140 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x1e), length 84
15:24:35.293259 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x2f), length 84
15:24:35.293315 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x30), length 100
15:24:35.293365 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x1f), length 84
15:24:35.293372 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x31), length 84
15:24:35.293514 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x20), length 84
15:24:35.293639 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x32), length 84

All tcpdumps were obtained on 2.6.17 machine.
On the same machine I frequently get following logs in syslog:

Sep 22 15:10:52 kano racoon: INFO: ISAKMP-SA established 192.168.4.79[500]-192.168.4.78[500] spi:9865a72e87784e17:cb2af1cfc436bd13 
Sep 22 15:10:52 kano racoon: ERROR: none message must be encrypted
Sep 22 15:10:53 kano racoon: INFO: respond new phase 2 negotiation: 192.168.4.79[500]<=>192.168.4.78[500]
Sep 22 15:10:53 kano racoon: INFO: IPsec-SA established: ESP/Transport 192.168.4.78[0]->192.168.4.79[0] spi=40993273(0x27181f9)
Sep 22 15:10:53 kano racoon: INFO: IPsec-SA established: ESP/Transport 192.168.4.79[0]->192.168.4.78[0] spi=157393760(0x961a360)
Sep 22 15:11:02 kano racoon: ERROR: none message must be encrypted
Sep 22 15:11:12 kano racoon: INFO: IPsec-SA expired: ESP/Transport 192.168.4.78[0]->192.168.4.79[0] spi=3540507(0x36061b)
Sep 22 15:11:12 kano racoon: WARNING: the expire message is received but the handler has not been established.
Sep 22 15:11:12 kano racoon: ERROR: 192.168.4.78 give up to get IPsec-SA due to time up to wait.

I do not recall if they existed when 2.6.17<->2.6.17 communication was
established.

I can use git bisect to track bug down if someone will show me simple tutorial.

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

On Fri, Sep 22, 2006 at 03:29:48PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> Hello.
> 
> I've found strange behaviour of transport mode IPsec in 2.6.18 tree.
> After key daemons exchanged keys (I use racoon) I try following command
> on 2.6.18 machine: telnet 192.168.4.79 22 (telnet from 2.6.18 to 2.6.17 based one)
> and get very slow response, here is related tcpdump output:
> 
> 15:15:47.396925 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x21), length 84
> 15:15:47.397391 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x18), length 84
> 15:15:47.397025 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x22), length 84
> 15:15:47.404166 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 2541002438:2541002458(20) ack 1601271418 win 91 
> 15:15:48.279375 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:15:50.031487 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:15:53.535710 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:16:00.544154 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:16:14.561064 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x19), length 100
> 15:16:14.561218 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x23), length 84

Here is setkey script used to setup communication:
#!/sbin/setkey -f
flush;
spdflush;

spdadd 192.168.4.79 192.168.4.78 any -P out ipsec
        esp/transport//require;

spdadd 192.168.4.78 192.168.4.79 any -P in ipsec
        esp/transport//require;

It has reverted addresses on second machine.

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

On Fri, Sep 22, 2006 at 03:29:48PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> Hello.
> 
> I've found strange behaviour of transport mode IPsec in 2.6.18 tree.
> After key daemons exchanged keys (I use racoon) I try following command
> on 2.6.18 machine: telnet 192.168.4.79 22 (telnet from 2.6.18 to 2.6.17 based one)
> and get very slow response, here is related tcpdump output:
> 
> 15:15:47.396925 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x21), length 84
> 15:15:47.397391 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x18), length 84
> 15:15:47.397025 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x22), length 84
> 15:15:47.404166 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 2541002438:2541002458(20) ack 1601271418 win 91 
> 15:15:48.279375 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:15:50.031487 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:15:53.535710 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:16:00.544154 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
> 15:16:14.561064 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x19), length 100
> 15:16:14.561218 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x23), length 84
> 
> Unencrypted packets somehow sneaked into the wire.

...

> I can use git bisect to track bug down if someone will show me simple tutorial.

Ok, I've found how to use it.
I started process but if there will be no results in about an hour I
will continue after weekend only if there will be no interesting results
from other developers.

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[Patrick McHardy]

Evgeniy Polyakov wrote:
> I started process but if there will be no results in about an hour I
> will continue after weekend only if there will be no interesting results
> from other developers.

FWIW: I've tried myself and it appears to works fine here. Policy
similar to yours, no netfilter.

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

[-- Attachment #1: Type: text/plain, Size: 7180 bytes --]

On Fri, Sep 22, 2006 at 02:23:17PM +0200, Patrick McHardy (kaber@trash.net) wrote:
> Evgeniy Polyakov wrote:
> > I started process but if there will be no results in about an hour I
> > will continue after weekend only if there will be no interesting results
> > from other developers.
> 
> FWIW: I've tried myself and it appears to works fine here. Policy
> similar to yours, no netfilter.

It exists even in 2.6.16, I was wrong about 2.6.17 status.
Here is tcpdump of the session for 2.6.16 tree:

17:44:52.868383 arp who-has 192.168.4.79 tell 192.168.4.78
17:44:52.868508 arp reply 192.168.4.79 is-at 00:0c:6e:ad:bb:8b
17:44:52.868460 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 1 I agg
17:44:52.877751 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others ? oakley-quick[E]
17:44:52.877988 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others ? inf
17:44:57.877187 arp who-has 192.168.4.78 tell 192.168.4.79
17:44:57.877256 arp reply 192.168.4.78 is-at 00:08:c7:2a:d2:63
17:45:02.876093 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 1 I agg
17:45:02.894360 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 1 R agg
17:45:02.894465 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others ? oakley-quick[E]
17:45:02.937995 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 1 I agg
17:45:02.938296 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others I inf[E]
17:45:02.938487 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others ? inf
17:45:03.948772 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others I oakley-quick[E]
17:45:03.958172 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others R oakley-quick[E]
17:45:03.958629 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others I oakley-quick[E]
17:45:04.770111 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x1), length 84
17:45:04.770225 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x1), length 84
17:45:04.770344 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x2), length 84
17:45:04.777560 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 3412388275:3412388295(20) ack 1965868757 win 91 <nop,nop,timestamp 1531076218 4294904370>
17:45:04.981642 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076269 4294904370>
17:45:05.389666 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076371 4294904370>
17:45:06.205721 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076575 4294904370>
17:45:07.837827 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076983 4294904370>

The same packet.

17:45:11.102066 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x2), length 100
17:45:11.102212 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x3), length 84
17:45:12.098146 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others ? oakley-quick[E]
17:45:12.098427 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others ? inf
17:45:22.163283 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x4), length 84
17:45:22.163472 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x3), length 84
17:45:22.163658 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x4), length 100
17:45:22.163717 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x5), length 84
17:45:22.163756 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x5), length 84
17:45:22.163894 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x6), length 84
17:45:22.163937 IP 192.168.4.79.ssh > 192.168.4.78.56527: . ack 4 win 91 <nop,nop,timestamp 1531080564 4294908719>
17:45:22.371295 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x7), length 84

Here I closed telnet session, but stack continues to retransmit the same
skb.

17:45:22.371364 IP 192.168.4.79.ssh > 192.168.4.78.56527: . ack 4 win 91 <nop,nop,timestamp 1531080616 4294908719>
17:45:22.779256 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x8), length 84
17:45:22.779288 IP 192.168.4.79.ssh > 192.168.4.78.56527: . ack 4 win 91 <nop,nop,timestamp 1531080718 4294908719>
17:45:23.595235 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x9), length 84
17:45:23.595277 IP 192.168.4.79.ssh > 192.168.4.78.56527: . ack 4 win 91 <nop,nop,timestamp 1531080922 4294908719>
17:45:25.227183 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0xa), length 84
17:45:25.227227 IP 192.168.4.79.ssh > 192.168.4.78.56527: . ack 4 win 91 <nop,nop,timestamp 1531081330 4294908719>

Eventually it starts not to send unencrypted packets, but initial tcp
connect is always the same. System does not have netfilter compiled in
(config attached). racoon's log after boot:

Sep 22 18:14:02 pcix racoon: INFO: IPsec-SA request for 192.168.4.79 queued due to no phase1 found.
Sep 22 18:14:02 pcix racoon: INFO: initiate new phase 1 negotiation: 192.168.4.78[500]<=>192.168.4.79[500]
Sep 22 18:14:02 pcix racoon: INFO: begin Aggressive mode. 
Sep 22 18:14:03 pcix racoon: ERROR: can't start the quick mode, there is no ISAKMP-SA, 9e2c9ac8e899c995:8569d21941d4656a:0000c723
Sep 22 18:14:13 pcix racoon: INFO: received Vendor ID: DPD
Sep 22 18:14:13 pcix racoon: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address.
Sep 22 18:14:13 pcix racoon: INFO: ISAKMP-SA established 192.168.4.78[500]-192.168.4.79[500] spi:ca904286f10e8d1c:b58cecc365818c0a
Sep 22 18:14:13 pcix racoon: ERROR: can't start the quick mode, there is no ISAKMP-SA, 9e2c9ac8e899c995:8569d21941d4656a:0000c723
Sep 22 18:14:14 pcix racoon: INFO: initiate new phase 2 negotiation: 192.168.4.78[0]<=>192.168.4.79[0]
Sep 22 18:14:14 pcix racoon: INFO: IPsec-SA established: ESP/Transport 192.168.4.79->192.168.4.78 spi=117847488(0x70635c0)
Sep 22 18:14:14 pcix racoon: INFO: IPsec-SA established: ESP/Transport 192.168.4.78->192.168.4.79 spi=32789182(0x1f452be)
Sep 22 18:14:22 pcix racoon: ERROR: can't start the quick mode, there is no ISAKMP-SA, 9e2c9ac8e899c995:8569d21941d4656a:0000c723

machine has e100 nic, smp, on tainting modules.

racoon config:
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm  rijndael, blowfish 448 ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}

remote anonymous
{
        exchange_mode aggressive, main;
        my_identifier address;
        passive off;
        proposal {
                encryption_algorithm rijndael;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

certificate file is empty.

psk file:
192.168.4.79 somenumbers

setkey:
#!/sbin/setkey -f
flush;
spdflush;

spdadd 192.168.4.78 192.168.4.79 any -P out ipsec
        esp/transport//require;

spdadd 192.168.4.79 192.168.4.78 any -P in ipsec
	esp/transport//require;
		

-- 
	Evgeniy Polyakov

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 22496 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16
# Fri Sep 22 18:04:17 2006
#
CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION="-vanilla"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
CONFIG_VM86=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_LBD=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_HOTPLUG_CPU is not set
CONFIG_DOUBLEFAULT=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_NET_KEY=m
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=y
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_MWAVE is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=m

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
CONFIG_NLS_CODEPAGE_866=m
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
CONFIG_NLS_KOI8_R=m
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Fri, 22 Sep 2006, Evgeniy Polyakov wrote:

> 17:45:04.770225 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x1), length 84
> 17:45:04.770344 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x2), length 84
> 17:45:04.777560 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 3412388275:3412388295(20) ack 1965868757 win 91 <nop,nop,timestamp 1531076218 4294904370>

Where are you running tcpdump?  It is normal to see both the encrypted and 
unencrypted packets if you run it on one of the machines doing ipsec, 
because of the way xfrm stacking works.

> 17:45:04.981642 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076269 4294904370>
> 17:45:05.389666 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076371 4294904370>
> 17:45:06.205721 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076575 4294904370>
> 17:45:07.837827 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076983 4294904370>

Not sure what's going on here.

> The same packet.
> 
> 17:45:11.102066 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x2), length 100
> 17:45:11.102212 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x3), length 84
> 17:45:12.098146 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others ? oakley-quick[E]
> 17:45:12.098427 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others ? inf

And why racoon packets are here at this stage.

Can you try this with either a fully manual config (setkey only) or 
openswan?


- James
-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Fri, 22 Sep 2006, James Morris wrote:

> Can you try this with either a fully manual config (setkey only) or 
> openswan?

Just confirming that everything seems to be working ok with manual config 
under 2.6.18 (haven't tried racoon yet).


-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

On Fri, Sep 22, 2006 at 11:15:35AM -0400, James Morris (jmorris@namei.org) wrote:
> On Fri, 22 Sep 2006, Evgeniy Polyakov wrote:
> 
> > 17:45:04.770225 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x1), length 84
> > 17:45:04.770344 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x2), length 84
> > 17:45:04.777560 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 3412388275:3412388295(20) ack 1965868757 win 91 <nop,nop,timestamp 1531076218 4294904370>
> 
> Where are you running tcpdump?  It is normal to see both the encrypted and 
> unencrypted packets if you run it on one of the machines doing ipsec, 
> because of the way xfrm stacking works.

It runs on receiving machine (2.6.17 kernel).
I never saw unencrypted packets before.
For example when I do ping receiving side never saw unencrypted ICMP
echo requests/reply, only ESP packets, the same applies to the case when
above fluent state is completed and ssh starts it's normal traffic -
there are only ESP packets seen by tcpdump.

> > 17:45:04.981642 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076269 4294904370>
> > 17:45:05.389666 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076371 4294904370>
> > 17:45:06.205721 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076575 4294904370>
> > 17:45:07.837827 IP 192.168.4.79.ssh > 192.168.4.78.56527: P 0:20(20) ack 1 win 91 <nop,nop,timestamp 1531076983 4294904370>
> 
> Not sure what's going on here.
> 
> > The same packet.
> > 
> > 17:45:11.102066 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x070635c0,seq=0x2), length 100
> > 17:45:11.102212 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x3), length 84
> > 17:45:12.098146 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others ? oakley-quick[E]
> > 17:45:12.098427 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others ? inf
> 
> And why racoon packets are here at this stage.
> 
> Can you try this with either a fully manual config (setkey only) or 
> openswan?

I use racoon, may be there are some problems with it's version, I will
try new one after weekend.
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Sat, 23 Sep 2006, Evgeniy Polyakov wrote:

> I never saw unencrypted packets before.

It's normal and expected, perhaps you didn't notice or had tcpdump 
filtering them.

> > > 17:45:11.102212 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x01f452be,seq=0x3), length 84
> > > 17:45:12.098146 IP 192.168.4.79.isakmp > 192.168.4.78.isakmp: isakmp: phase 2/others ? oakley-quick[E]
> > > 17:45:12.098427 IP 192.168.4.78.isakmp > 192.168.4.79.isakmp: isakmp: phase 2/others ? inf
> > 
> > And why racoon packets are here at this stage.
> > 
> > Can you try this with either a fully manual config (setkey only) or 
> > openswan?
> 
> I use racoon, may be there are some problems with it's version, I will
> try new one after weekend.

I just verified that racoon is working with current kernels.  Racoon can 
be troublesome.  

I'm using racoon from ipsec-tools-0.6.5-3.1.

You didn't specify a lifetime in your phase 1 spec ('remote anonymous') 
section.  Not sure what happens in that case, could be something to do 
with it.




- James
-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[Patrick McHardy]

James Morris wrote:
> On Sat, 23 Sep 2006, Evgeniy Polyakov wrote:
> 
> 
>>I never saw unencrypted packets before.
> 
> 
> It's normal and expected, perhaps you didn't notice or had tcpdump 
> filtering them.

He's talking about transport mode, unencrypted packet should
only be visible in tunnel mode.

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Sun, 24 Sep 2006, Patrick McHardy wrote:

> James Morris wrote:
> > On Sat, 23 Sep 2006, Evgeniy Polyakov wrote:
> > 
> > 
> >>I never saw unencrypted packets before.
> > 
> > 
> > It's normal and expected, perhaps you didn't notice or had tcpdump 
> > filtering them.
> 
> He's talking about transport mode, unencrypted packet should
> only be visible in tunnel mode.

Ok.

I've done some more testing with local tcpdumps and not seeing any issues.

Evgeniy: if you update to the latest racoon (and kernel), and still see 
it, please send complete logs of 'racoon -dddd' from each side, and also 
'setkey -x', so we can see if the policy entries are being being modified.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[Herbert Xu]

James Morris <jmorris@namei.org> wrote:
>
> Evgeniy: if you update to the latest racoon (and kernel), and still see 
> it, please send complete logs of 'racoon -dddd' from each side, and also 
> 'setkey -x', so we can see if the policy entries are being being modified.

Please also do 'ip -s x s' on both sides to check the various counters.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Is TCP over IPsec broken in 2.6.18?

[Herbert Xu]

On Mon, Sep 25, 2006 at 02:38:36PM +0400, Evgeniy Polyakov wrote:
> 
> I ran two times the same 'telnet 192.168.4.79 22' and got unencrypted
> packets and very long timeout. After some magic initial process things
> started to work as expected - only ESP encrypted packets can be found in
> tcpdump, until next connection is started, which becames to work not
> correctly and then again starts to work as expected.

Perhaps something's screwed up with the policies.  Unfortunately
the racoon logs draw a blank around the interesting interval as
shown by the tcpdump.

Please run ip x p once every second and the post what it shows
before, during and after the period when unecrypted packets show
up on the wire.

You only have to do it on the 79 machine since it's the one sending
unencrypted data.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Mon, Sep 25, 2006 at 09:27:54PM +1000, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> On Mon, Sep 25, 2006 at 02:38:36PM +0400, Evgeniy Polyakov wrote:
> > 
> > I ran two times the same 'telnet 192.168.4.79 22' and got unencrypted
> > packets and very long timeout. After some magic initial process things
> > started to work as expected - only ESP encrypted packets can be found in
> > tcpdump, until next connection is started, which becames to work not
> > correctly and then again starts to work as expected.
> 
> Perhaps something's screwed up with the policies.  Unfortunately
> the racoon logs draw a blank around the interesting interval as
> shown by the tcpdump.

I insrted blank lines specially to show where things started to work
correctly (first blank lines), second one shows where I started second 
telnet. I think you've noticed that time difference on machines
is about 30 minutes.

> Please run ip x p once every second and the post what it shows
> before, during and after the period when unecrypted packets show
> up on the wire.
> 
> You only have to do it on the 79 machine since it's the one sending
> unencrypted data.

Attached three files - before, while and after connection establishment.

-- 
	Evgeniy Polyakov

[-- Attachment #2: after --]
[-- Type: text/plain, Size: 3052 bytes --]

src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 

[-- Attachment #3: before --]
[-- Type: text/plain, Size: 4578 bytes --]

src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 

[-- Attachment #4: while --]
[-- Type: text/plain, Size: 9156 bytes --]

src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir in priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.79/32 dst 192.168.4.78/32 
	dir out priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src 192.168.4.78/32 dst 192.168.4.79/32 
	dir fwd priority 2147483648 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport
src ::/0 dst ::/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir in priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src ::/0 dst ::/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	dir out priority 0 

Re: Is TCP over IPsec broken in 2.6.18?

[jamal]

On Mon, 2006-25-09 at 16:05 +0400, Evgeniy Polyakov wrote:
> On Mon, Sep 25, 2006 at 09:27:54PM +1000, Herbert Xu (herbert@gondor.apana.org.au) wrote:

> > Please run ip x p once every second and the post what it shows
> > before, during and after the period when unecrypted packets show
> > up on the wire.
> > 
> > You only have to do it on the 79 machine since it's the one sending
> > unencrypted data.
> 
> Attached three files - before, while and after connection establishment.

I think a -s option would have been helpful 
i.e ip -s x p and also if the script printed output of date command
(to compare against when last use was - if i read correctly what Herbert
was getting at)
 
cheers,
jamal

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

I've just seen something similar and can recreate it with static keying 
via setkey.

The symptom was that ping was only working in one direction, and I 
quintuple-checked the configs and that they have the same kernels etc., 
then ran a bunch of tcpdumps on each and and a router in the middle with 
various protocols.

Some protocols work (ssh) but others (ftp) doesn't.  Also verified the 
problem via simple telnet to these ports.

In one case, the ftp server receives a SYN from the client over ipsec just 
fine but the synack goes out in cleartext (also verified the server is in 
SYN_RECV), and the client drops these.

tcpdump on intermediate router:

[ SYN packet from client, ESP encapsulated as expected ]

IP (tos 0x10, ttl  63, id 4588, offset 0, flags [DF], proto: ESP (50), 
length: 104) 10.1.2.2 > 10.1.3.2: ESP(spi=0x00055555,seq=0x4), length 84

[ SYNACK from server, in the clear, not expected ]

IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 
60) 10.1.3.2.ftp > 10.1.2.2.53123: S, cksum 0x314c (correct), 
2413701424:2413701424(0) ack 2343803769 win 11844 <mss 
3960,sackOK,timestamp 1018642 690836,nop,wscale 9>

Again note that another protocol such as SSH works as expected.


Connecting from the other side, it looks fine:

IP (tos 0x10, ttl  64, id 33701, offset 0, flags [DF], proto: ESP (50), 
length: 104) 10.1.3.2 > 10.1.2.2: ESP(spi=0x00066666,seq=0x1), length 84

IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: ESP (50), length: 
104) 10.1.2.2 > 10.1.3.2: ESP(spi=0x00055555,seq=0x1), length 84



Another odd thing I noticed was a ping client in the non-working direction 
segfaulted under strace (once).

These are both x86 machines running the kernel:
2.6.18-1.2699.fc6  (note that this has xen patches but is running bare 
metal).

I ran tcpdump for the above ftp and ssh cases to see if there was anything 
different about the packets (e.g. TOS or TCP opts) but found nothing -- it 
all looks fine, as well as using nc to make sure they're selecting source 
ports of a similar value etc.

Will try with an upstream kernel and see what happens.

-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Sat, 30 Sep 2006, James Morris wrote:

> I've just seen something similar and can recreate it with static keying 
> via setkey.

It's SELinux related.  Things work when the one system in this setup with 
SELinux enabled is changed to permissive mode.

No audit messages or AVCs, and it's not the /selinux/compat_net setting.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Sat, 30 Sep 2006, James Morris wrote:

> SELinux enabled is changed to permissive mode.


Ok, in the case where unencrypted packets are leaking, the problem is that 
xfrm_lookup() is returning a false zero on a polmatch denial like:

  avc:  denied  { polmatch } for  scontext=system_u:system_r:ftpd_t:s0 
  tcontext=system_u:object_r:unlabeled_t:s0 tclass=association


Follow the call back up from selinux_xfrm_policy_lookup(), when:

{
	rc = avc_has_perm(fl_secid, sel_sid, SECCLASS_ASSOCIATION,
                          ASSOCIATION__POLMATCH,
                          NULL);

	return rc;  <----  -EACCESS
}


Which is propagated back via 

   xfrm_policy_match()
   xfrm_policy_lookup_bytype()
   xfrm_policy_lookup()
   
to

int xfrm_lookup() 
{
	...

	if (!policy) {
		/* To accelerate a bit...  */
		if ((dst_orig->flags & DST_NOXFRM) ||
		     !xfrm_policy_count[XFRM_POLICY_OUT])
			return 0;
		
		policy = flow_cache_lookup(fl, dst_orig->ops->family,
					   dir, xfrm_policy_lookup);
	}

	if (!policy)
		return 0;   <---- returns

	...
}

and the callers then allow the packet to proceed unencrypted.

It seems that some logic needs to be reworked to ensure that the real 
error value is propagated back and returned via xfrm_lookup().

I was also seeing these AVCs when receiving ping requests:

  avc:  denied { sendto } for scontext=system_u:object_r:unlabeled_t:s0 
  tcontext=system_u :object_r:unlabeled_t:s0 tclass=association

Not sure if there are any deeper issues in this case: the callers need to 
be audited.




- James
-- 
James Morris <jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

On Sat, Sep 30, 2006 at 01:14:27AM -0400, James Morris (jmorris@namei.org) wrote:
> On Sat, 30 Sep 2006, James Morris wrote:
> 
> > I've just seen something similar and can recreate it with static keying 
> > via setkey.
> 
> It's SELinux related.  Things work when the one system in this setup with 
> SELinux enabled is changed to permissive mode.
> 
> No audit messages or AVCs, and it's not the /selinux/compat_net setting.

I need to cofirm that broken system in my setup does have selinux enabled 
with enforcing mode.
I've changed it to permissive mode and it fixed setup (I do not see any 
warnings in dmesg).
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Sat, 30 Sep 2006, Evgeniy Polyakov wrote:

> I need to cofirm that broken system in my setup does have selinux enabled 
> with enforcing mode.
> I've changed it to permissive mode and it fixed setup (I do not see any 
> warnings in dmesg).

Something better in your case would likely be to rebuild the kernel with 
CONFIG_SECURITY_NETWORK_XFRM=n until it's fixed.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

On Sat, Sep 30, 2006 at 10:36:29AM -0400, James Morris (jmorris@namei.org) wrote:
> On Sat, 30 Sep 2006, Evgeniy Polyakov wrote:
> 
> > I need to cofirm that broken system in my setup does have selinux enabled 
> > with enforcing mode.
> > I've changed it to permissive mode and it fixed setup (I do not see any 
> > warnings in dmesg).
> 
> Something better in your case would likely be to rebuild the kernel with 
> CONFIG_SECURITY_NETWORK_XFRM=n until it's fixed.

Well, it is acrypto test machine and I do not care about security there,
so I can even disable selinux completely, but it will not help to resolve
the issue, right?

So if you have some patches I'm more than happy to test them.
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[Evgeniy Polyakov]

On Sat, Sep 30, 2006 at 06:40:18PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> On Sat, Sep 30, 2006 at 10:36:29AM -0400, James Morris (jmorris@namei.org) wrote:
> > On Sat, 30 Sep 2006, Evgeniy Polyakov wrote:
> > 
> > > I need to cofirm that broken system in my setup does have selinux enabled 
> > > with enforcing mode.
> > > I've changed it to permissive mode and it fixed setup (I do not see any 
> > > warnings in dmesg).
> > 
> > Something better in your case would likely be to rebuild the kernel with 
> > CONFIG_SECURITY_NETWORK_XFRM=n until it's fixed.
> 
> Well, it is acrypto test machine and I do not care about security there,
> so I can even disable selinux completely, but it will not help to resolve
> the issue, right?
> 
> So if you have some patches I'm more than happy to test them.

And to confirm theory about CONFIG_SECURITY_NETWORK_XFRM I'm compiling
kernel without it (and then without selinux at all).

-- 
	Evgeniy Polyakov

Re: Is TCP over IPsec broken in 2.6.18?

[James Morris]

On Sat, 30 Sep 2006, Evgeniy Polyakov wrote:

> On Sat, Sep 30, 2006 at 10:36:29AM -0400, James Morris (jmorris@namei.org) wrote:
> > On Sat, 30 Sep 2006, Evgeniy Polyakov wrote:
> > 
> > > I need to cofirm that broken system in my setup does have selinux enabled 
> > > with enforcing mode.
> > > I've changed it to permissive mode and it fixed setup (I do not see any 
> > > warnings in dmesg).
> > 
> > Something better in your case would likely be to rebuild the kernel with 
> > CONFIG_SECURITY_NETWORK_XFRM=n until it's fixed.
> 
> Well, it is acrypto test machine and I do not care about security there,
> so I can even disable selinux completely, but it will not help to resolve
> the issue, right?

Yes, it is a workaround.

> 
> So if you have some patches I'm more than happy to test them.

Ok, coming soon.


-- 
James Morris
<jmorris@namei.org>

[PATCH] Fix for IPsec leakage with SELinux enabled

[James Morris]

Please review this patch carefully.  It addresses a couple of issues.

When a security module is loaded (in this case, SELinux), the 
security_xfrm_policy_lookup() hook can return an access denied permission 
(or other error).  We were not handling that correctly, and in fact 
inverting the return logic and propagating a false "ok" back up to 
xfrm_lookup(), which then allowed packets to pass as if they were not 
associated with an xfrm policy.

The way I was seeing the problem was when connecting via IPsec to a 
confined service on an SELinux box (vsftpd), which did not have the 
appropriate SELinux policy permissions to send packets via IPsec.

The first SYNACK would be blocked, because of an uncached lookup via 
flow_cache_lookup(), which would fail to resolve an xfrm policy because 
the SELinux policy is checked at that point via the resolver.

However, retransmitted SYNACKs would then find a cached flow entry when 
calling into flow_cache_lookup() with a null xfrm policy, which is 
interpreted by xfrm_lookup() as the packet not having any associated 
policy and similarly to the first case, allowing it to pass without 
transformation.

The solution presented here is to first ensure that errno values are 
correctly propagated all the way back up through the various call chains 
from security_xfrm_policy_lookup(), and handled correctly.

Then, flow_cache_lookup() is modified, so that if the policy resolver 
fails (typically a permission denied via the security module), the flow 
cache entry is killed rather than having a null policy assigned (which 
indicates that the packet can pass freely).  This also forces any future 
lookups for the same flow to consult the security module (e.g. SELinux) 
for current security policy (rather than, say, caching the error on the 
flow cache entry).

I've done quite a bit of testing and not seen any problems, although the 
patch could certainly do with further review.

Evgeniy, please let me know if this fixes your problem.


Signed-off-by: James Morris <jmorris@namei.org>


---

 include/net/flow.h     |    2 -
 net/core/flow.c        |   42 +++++++++++++++++++----------
 net/xfrm/xfrm_policy.c |   70 ++++++++++++++++++++++++++++++++++++++-----------
 3 files changed, 84 insertions(+), 30 deletions(-)


diff -purN -X dontdiff net-2.6.o/include/net/flow.h net-2.6.w/include/net/flow.h
--- net-2.6.o/include/net/flow.h	2006-09-29 11:33:58.000000000 -0400
+++ net-2.6.w/include/net/flow.h	2006-09-30 23:50:32.000000000 -0400
@@ -97,7 +97,7 @@ struct flowi {
 #define FLOW_DIR_FWD	2
 
 struct sock;
-typedef void (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
+typedef int (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
 			       void **objp, atomic_t **obj_refp);
 
 extern void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
diff -purN -X dontdiff net-2.6.o/net/core/flow.c net-2.6.w/net/core/flow.c
--- net-2.6.o/net/core/flow.c	2006-09-29 11:33:59.000000000 -0400
+++ net-2.6.w/net/core/flow.c	2006-10-01 01:07:24.000000000 -0400
@@ -85,6 +85,14 @@ static void flow_cache_new_hashrnd(unsig
 	add_timer(&flow_hash_rnd_timer);
 }
 
+static void flow_entry_kill(int cpu, struct flow_cache_entry *fle)
+{
+	if (fle->object)
+		atomic_dec(fle->object_ref);
+	kmem_cache_free(flow_cachep, fle);
+	flow_count(cpu)--;
+}
+
 static void __flow_cache_shrink(int cpu, int shrink_to)
 {
 	struct flow_cache_entry *fle, **flp;
@@ -100,10 +108,7 @@ static void __flow_cache_shrink(int cpu,
 		}
 		while ((fle = *flp) != NULL) {
 			*flp = fle->next;
-			if (fle->object)
-				atomic_dec(fle->object_ref);
-			kmem_cache_free(flow_cachep, fle);
-			flow_count(cpu)--;
+			flow_entry_kill(cpu, fle);
 		}
 	}
 }
@@ -220,24 +225,33 @@ void *flow_cache_lookup(struct flowi *ke
 
 nocache:
 	{
+		int err;
 		void *obj;
 		atomic_t *obj_ref;
 
-		resolver(key, family, dir, &obj, &obj_ref);
+		err = resolver(key, family, dir, &obj, &obj_ref);
 
 		if (fle) {
-			fle->genid = atomic_read(&flow_cache_genid);
-
-			if (fle->object)
-				atomic_dec(fle->object_ref);
-
-			fle->object = obj;
-			fle->object_ref = obj_ref;
-			if (obj)
-				atomic_inc(fle->object_ref);
+			if (err) {
+				/* Force security policy check on next lookup */
+				*head = fle->next;
+				flow_entry_kill(cpu, fle);
+			} else {
+				fle->genid = atomic_read(&flow_cache_genid);
+				
+				if (fle->object)
+					atomic_dec(fle->object_ref);
+					
+				fle->object = obj;
+				fle->object_ref = obj_ref;
+				if (obj)
+					atomic_inc(fle->object_ref);
+			}
 		}
 		local_bh_enable();
 
+		if (err)
+			obj = ERR_PTR(err);
 		return obj;
 	}
 }
diff -purN -X dontdiff net-2.6.o/net/xfrm/xfrm_policy.c net-2.6.w/net/xfrm/xfrm_policy.c
--- net-2.6.o/net/xfrm/xfrm_policy.c	2006-09-29 11:34:00.000000000 -0400
+++ net-2.6.w/net/xfrm/xfrm_policy.c	2006-10-01 01:53:21.000000000 -0400
@@ -880,30 +880,32 @@ out:
 }
 EXPORT_SYMBOL(xfrm_policy_walk);
 
-/* Find policy to apply to this flow. */
-
+/*
+ * Find policy to apply to this flow.
+ *
+ * Returns 0 if policy found, else an -errno.
+ */
 static int xfrm_policy_match(struct xfrm_policy *pol, struct flowi *fl,
 			     u8 type, u16 family, int dir)
 {
 	struct xfrm_selector *sel = &pol->selector;
-	int match;
+	int match, ret = -ESRCH;
 
 	if (pol->family != family ||
 	    pol->type != type)
-		return 0;
+		return ret;
 
 	match = xfrm_selector_match(sel, fl, family);
-	if (match) {
-		if (!security_xfrm_policy_lookup(pol, fl->secid, dir))
-			return 1;
-	}
+	if (match)
+		ret = security_xfrm_policy_lookup(pol, fl->secid, dir);
 
-	return 0;
+	return ret;
 }
 
 static struct xfrm_policy *xfrm_policy_lookup_bytype(u8 type, struct flowi *fl,
 						     u16 family, u8 dir)
 {
+	int err;
 	struct xfrm_policy *pol, *ret;
 	xfrm_address_t *daddr, *saddr;
 	struct hlist_node *entry;
@@ -919,7 +921,15 @@ static struct xfrm_policy *xfrm_policy_l
 	chain = policy_hash_direct(daddr, saddr, family, dir);
 	ret = NULL;
 	hlist_for_each_entry(pol, entry, chain, bydst) {
-		if (xfrm_policy_match(pol, fl, type, family, dir)) {
+		err = xfrm_policy_match(pol, fl, type, family, dir);
+		if (err) {
+			if (err == -ESRCH)
+				continue;
+			else {
+				ret = ERR_PTR(err);
+				goto fail;
+			}
+		} else {
 			ret = pol;
 			priority = ret->priority;
 			break;
@@ -927,36 +937,53 @@ static struct xfrm_policy *xfrm_policy_l
 	}
 	chain = &xfrm_policy_inexact[dir];
 	hlist_for_each_entry(pol, entry, chain, bydst) {
-		if (xfrm_policy_match(pol, fl, type, family, dir) &&
-		    pol->priority < priority) {
+		err = xfrm_policy_match(pol, fl, type, family, dir);
+		if (err) {
+			if (err == -ESRCH)
+				continue;
+			else {
+				ret = ERR_PTR(err);
+				goto fail;
+			}
+		} else if (pol->priority < priority) {
 			ret = pol;
 			break;
 		}
 	}
 	if (ret)
 		xfrm_pol_hold(ret);
+fail:
 	read_unlock_bh(&xfrm_policy_lock);
 
 	return ret;
 }
 
-static void xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
+static int xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
 			       void **objp, atomic_t **obj_refp)
 {
 	struct xfrm_policy *pol;
+	int err = 0;
 
 #ifdef CONFIG_XFRM_SUB_POLICY
 	pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_SUB, fl, family, dir);
-	if (pol)
+	if (IS_ERR(pol)) {
+		err = PTR_ERR(pol);
+		pol = NULL;
+	}
+	if (pol || err)
 		goto end;
 #endif
 	pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_MAIN, fl, family, dir);
-
+	if (IS_ERR(pol)) {
+		err = PTR_ERR(pol);
+		pol = NULL;
+	}
 #ifdef CONFIG_XFRM_SUB_POLICY
 end:
 #endif
 	if ((*objp = (void *) pol) != NULL)
 		*obj_refp = &pol->refcnt;
+	return err;
 }
 
 static inline int policy_to_flow_dir(int dir)
@@ -1294,6 +1321,10 @@ restart:
 
 		policy = flow_cache_lookup(fl, dst_orig->ops->family,
 					   dir, xfrm_policy_lookup);
+		if (IS_ERR(policy)) {
+			err = PTR_ERR(policy);
+			goto error;
+		}
 	}
 
 	if (!policy)
@@ -1340,6 +1371,10 @@ restart:
 							    fl, family,
 							    XFRM_POLICY_OUT);
 			if (pols[1]) {
+				if (IS_ERR(pols[1])) {
+					err = PTR_ERR(pols[1]);
+					goto error;
+				}
 				if (pols[1]->action == XFRM_POLICY_BLOCK) {
 					err = -EPERM;
 					goto error;
@@ -1578,6 +1613,9 @@ int __xfrm_policy_check(struct sock *sk,
 		pol = flow_cache_lookup(&fl, family, fl_dir,
 					xfrm_policy_lookup);
 
+	if (IS_ERR(pol))
+		return 0;
+
 	if (!pol) {
 		if (skb->sp && secpath_has_nontransport(skb->sp, 0, &xerr_idx)) {
 			xfrm_secpath_reject(xerr_idx, skb, &fl);
@@ -1596,6 +1634,8 @@ int __xfrm_policy_check(struct sock *sk,
 						    &fl, family,
 						    XFRM_POLICY_IN);
 		if (pols[1]) {
+			if (IS_ERR(pols[1]))
+				return 0;
 			pols[1]->curlft.use_time = (unsigned long)xtime.tv_sec;
 			npols ++;
 		}

RE: [PATCH] Fix for IPsec leakage with SELinux enabled

[Venkat Yekkirala]

> The way I was seeing the problem was when connecting via IPsec to a 
> confined service on an SELinux box (vsftpd), which did not have the 
> appropriate SELinux policy permissions to send packets via IPsec.
> 
> The first SYNACK would be blocked,

Given that the resolver fails to find a policy here, I am trying to
understand what exactly is blocking it (the first SYNACK) from
proceeding without IPSec.

> because of an uncached lookup via 
> flow_cache_lookup(), which would fail to resolve an xfrm 
> policy because 
> the SELinux policy is checked at that point via the resolver.
> 
> However, retransmitted SYNACKs would then find a cached flow 
> entry when 
> calling into flow_cache_lookup() with a null xfrm policy, which is 
> interpreted by xfrm_lookup() as the packet not having any associated 
> policy and similarly to the first case, allowing it to pass without 
> transformation.

RE: [PATCH] Fix for IPsec leakage with SELinux enabled

[James Morris]

On Sun, 1 Oct 2006, Venkat Yekkirala wrote:

> > The way I was seeing the problem was when connecting via IPsec to a 
> > confined service on an SELinux box (vsftpd), which did not have the 
> > appropriate SELinux policy permissions to send packets via IPsec.
> > 
> > The first SYNACK would be blocked,
> 
> Given that the resolver fails to find a policy here, I am trying to
> understand what exactly is blocking it (the first SYNACK) from
> proceeding without IPSec.

You're right.  My explanation there was for the case where I'd modified 
the code to propagate the SELinux denial back to xfrm_lookup(), and not 
for the original issue (sorry, it's been a long week).

In the original case, all packets originating from a confined domain will 
bypass ipsec.  During xfrm_lookup, flow_cache_lookup() returns NULL 
policy:

xfrm_lookup()
{
	...

	if (!policy) {
                /* To accelerate a bit...  */
                if ((dst_orig->flags & DST_NOXFRM) ||
                    !xfrm_policy_count[XFRM_POLICY_OUT])
                        return 0;

                policy = flow_cache_lookup(fl, dst_orig->ops->family,
                                           dir, xfrm_policy_lookup);
        }

        if (!policy)
                return 0;  <- bad
	...
}

The call chain is:

flow_cache_lookup()
  xfrm_policy_lookup()
   xfrm_policy_lookup_bytype()
     xfrm_policy_match() {
       xfrm_selector_match => returns true, then
         security_xfrm_policy_lookup => returns -EACCESS
     }

then
     
xfrm_policy_match() => returns 0
xfrm_policy_lookup_bytype => returns 0
xfrm_policy_lookup() => sets obj to NULL w/ void return
flow_cache_lookup() => returns NULL
xfrm_lookup => returns 0

and the packet proceeds without error and with no transform applied (i.e. 
leaked as cleartext).

The first component of the fix is to propagate errors back up to callers 
via the flow cache resolver, and handle them correctly, as this is where 
we can experience security module denials.

The second component is to then ensure that, on failure, we kill the new 
flow cache entry created during lookup, so that it is not subsequently 
looked up with a null policy (i.e. allowing future packets to leak) and to 
force the security hook to be called again in case the policy has changed.  

Hope that clarifies.
    

- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] Fix for IPsec leakage with SELinux enabled

[Evgeniy Polyakov]

On Sun, Oct 01, 2006 at 02:27:13AM -0400, James Morris (jmorris@namei.org) wrote:
> Please review this patch carefully.  It addresses a couple of issues.
> 
> When a security module is loaded (in this case, SELinux), the 
> security_xfrm_policy_lookup() hook can return an access denied permission 
> (or other error).  We were not handling that correctly, and in fact 
> inverting the return logic and propagating a false "ok" back up to 
> xfrm_lookup(), which then allowed packets to pass as if they were not 
> associated with an xfrm policy.
> 
> The way I was seeing the problem was when connecting via IPsec to a 
> confined service on an SELinux box (vsftpd), which did not have the 
> appropriate SELinux policy permissions to send packets via IPsec.
> 
> The first SYNACK would be blocked, because of an uncached lookup via 
> flow_cache_lookup(), which would fail to resolve an xfrm policy because 
> the SELinux policy is checked at that point via the resolver.
> 
> However, retransmitted SYNACKs would then find a cached flow entry when 
> calling into flow_cache_lookup() with a null xfrm policy, which is 
> interpreted by xfrm_lookup() as the packet not having any associated 
> policy and similarly to the first case, allowing it to pass without 
> transformation.
> 
> The solution presented here is to first ensure that errno values are 
> correctly propagated all the way back up through the various call chains 
> from security_xfrm_policy_lookup(), and handled correctly.
> 
> Then, flow_cache_lookup() is modified, so that if the policy resolver 
> fails (typically a permission denied via the security module), the flow 
> cache entry is killed rather than having a null policy assigned (which 
> indicates that the packet can pass freely).  This also forces any future 
> lookups for the same flow to consult the security module (e.g. SELinux) 
> for current security policy (rather than, say, caching the error on the 
> flow cache entry).
> 
> I've done quite a bit of testing and not seen any problems, although the 
> patch could certainly do with further review.
> 
> Evgeniy, please let me know if this fixes your problem.

With that patch applied I got kernel panic after some time.
Unfortunately I have not installed serial console, so the most
interesting bits of the stack dump are not visible.
Here is the last ones which are on the screen:
ip_rcv
ip_rcv_finish
packet_rcv_spkt
ip_rcv
netif_receive_skb
sys_accept
skge_poll

and some other uninteresting stuff like hrtimer, softirq and the like...

EIP is at xfrm_lookup+0x43d/0x470

Notice packet socket handler in the trace, may be it can help - I ran
system with tcpdump started.

-- 
	Evgeniy Polyakov

Re: [PATCH] Fix for IPsec leakage with SELinux enabled

[James Morris]

On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:

> > Evgeniy, please let me know if this fixes your problem.
> 
> With that patch applied I got kernel panic after some time.
> Unfortunately I have not installed serial console, so the most
> interesting bits of the stack dump are not visible.
> Here is the last ones which are on the screen:
> ip_rcv
> ip_rcv_finish
> packet_rcv_spkt
> ip_rcv
> netif_receive_skb
> sys_accept
> skge_poll
> 
> and some other uninteresting stuff like hrtimer, softirq and the like...
> 
> EIP is at xfrm_lookup+0x43d/0x470
> 
> Notice packet socket handler in the trace, may be it can help - I ran
> system with tcpdump started.

What kind of traffic was running over the system?  What is the IPsec and 
SELinux configuration?

Can you run gdb on vmlinux, find the start of xfrm_lookup then list what's 
at the EIP offset?

(gdb) p xfrm_lookup
$1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 
0xc02cc7e2 <xfrm_lookup>
(gdb) l *(0xc02cc7e2 + 0x043d)


-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] Fix for IPsec leakage with SELinux enabled

[Evgeniy Polyakov]

On Mon, Oct 02, 2006 at 09:31:36AM -0400, James Morris (jmorris@namei.org) wrote:
> What kind of traffic was running over the system?  What is the IPsec and 
> SELinux configuration?

I had login through ssh, started racoon and setup keys.
SElinu is configured by default in FC5 system with enforcing mode.

I switched off to different window and after some time, not immediately,
remote system stopped to answer.

There were no heavy traffic definitely.
It looks like some timeout expired and someone tried to do xfrm_lookup.

> Can you run gdb on vmlinux, find the start of xfrm_lookup then list what's 
> at the EIP offset?
> 
> (gdb) p xfrm_lookup
> $1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 
> 0xc02cc7e2 <xfrm_lookup>
> (gdb) l *(0xc02cc7e2 + 0x043d)

(gdb) p xfrm_lookup
$1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 0xc0301326 <xfrm_lookup>
(gdb) l *(0xc0301326+0x043d)
0xc0301763 is in xfrm_lookup (include/asm/atomic.h:126).
121      */ 
122     static __inline__ int atomic_dec_and_test(atomic_t *v)
123     {
124             unsigned char c;
125
126             __asm__ __volatile__(
127                     LOCK_PREFIX "decl %0; sete %1"
128                     :"+m" (v->counter), "=qm" (c)
129                     : : "memory");
130             return c != 0;

Probably reference counter is inside freed object...

> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: [PATCH] Fix for IPsec leakage with SELinux enabled

[James Morris]

On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:

> Probably reference counter is inside freed object...

I think I know what it is (xfrm_lookup needs to just return on flow cache 
lookup failure, not goto error and free the dst).  Patch forthcoming.




- James
-- 
James Morris
<jmorris@namei.org>

[PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[James Morris]

Updated version of the patch, which return directly after a flow cache 
lookup error in xfrm_lookup rather than returing via the cleanup path 
(which was causing a spurious dst_release).

This works for me, although I never saw the oops with the old patch.

Evgeniy, let me know if this fixes the oops you're seeing.


Signed-off-by: James Morris <jmorris@namei.org>

---

diff -purN -X dontdiff net-2.6.o/include/net/flow.h net-2.6.w/include/net/flow.h
--- net-2.6.o/include/net/flow.h	2006-09-29 11:33:58.000000000 -0400
+++ net-2.6.w/include/net/flow.h	2006-09-30 23:50:32.000000000 -0400
@@ -97,7 +97,7 @@ struct flowi {
 #define FLOW_DIR_FWD	2
 
 struct sock;
-typedef void (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
+typedef int (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
 			       void **objp, atomic_t **obj_refp);
 
 extern void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
diff -purN -X dontdiff net-2.6.o/net/core/flow.c net-2.6.w/net/core/flow.c
--- net-2.6.o/net/core/flow.c	2006-09-29 11:33:59.000000000 -0400
+++ net-2.6.w/net/core/flow.c	2006-10-01 01:07:24.000000000 -0400
@@ -85,6 +85,14 @@ static void flow_cache_new_hashrnd(unsig
 	add_timer(&flow_hash_rnd_timer);
 }
 
+static void flow_entry_kill(int cpu, struct flow_cache_entry *fle)
+{
+	if (fle->object)
+		atomic_dec(fle->object_ref);
+	kmem_cache_free(flow_cachep, fle);
+	flow_count(cpu)--;
+}
+
 static void __flow_cache_shrink(int cpu, int shrink_to)
 {
 	struct flow_cache_entry *fle, **flp;
@@ -100,10 +108,7 @@ static void __flow_cache_shrink(int cpu,
 		}
 		while ((fle = *flp) != NULL) {
 			*flp = fle->next;
-			if (fle->object)
-				atomic_dec(fle->object_ref);
-			kmem_cache_free(flow_cachep, fle);
-			flow_count(cpu)--;
+			flow_entry_kill(cpu, fle);
 		}
 	}
 }
@@ -220,24 +225,33 @@ void *flow_cache_lookup(struct flowi *ke
 
 nocache:
 	{
+		int err;
 		void *obj;
 		atomic_t *obj_ref;
 
-		resolver(key, family, dir, &obj, &obj_ref);
+		err = resolver(key, family, dir, &obj, &obj_ref);
 
 		if (fle) {
-			fle->genid = atomic_read(&flow_cache_genid);
-
-			if (fle->object)
-				atomic_dec(fle->object_ref);
-
-			fle->object = obj;
-			fle->object_ref = obj_ref;
-			if (obj)
-				atomic_inc(fle->object_ref);
+			if (err) {
+				/* Force security policy check on next lookup */
+				*head = fle->next;
+				flow_entry_kill(cpu, fle);
+			} else {
+				fle->genid = atomic_read(&flow_cache_genid);
+				
+				if (fle->object)
+					atomic_dec(fle->object_ref);
+					
+				fle->object = obj;
+				fle->object_ref = obj_ref;
+				if (obj)
+					atomic_inc(fle->object_ref);
+			}
 		}
 		local_bh_enable();
 
+		if (err)
+			obj = ERR_PTR(err);
 		return obj;
 	}
 }
diff -purN -X dontdiff net-2.6.o/net/xfrm/xfrm_policy.c net-2.6.w/net/xfrm/xfrm_policy.c
--- net-2.6.o/net/xfrm/xfrm_policy.c	2006-09-29 11:34:00.000000000 -0400
+++ net-2.6.w/net/xfrm/xfrm_policy.c	2006-10-02 10:02:18.000000000 -0400
@@ -880,30 +880,32 @@ out:
 }
 EXPORT_SYMBOL(xfrm_policy_walk);
 
-/* Find policy to apply to this flow. */
-
+/*
+ * Find policy to apply to this flow.
+ *
+ * Returns 0 if policy found, else an -errno.
+ */
 static int xfrm_policy_match(struct xfrm_policy *pol, struct flowi *fl,
 			     u8 type, u16 family, int dir)
 {
 	struct xfrm_selector *sel = &pol->selector;
-	int match;
+	int match, ret = -ESRCH;
 
 	if (pol->family != family ||
 	    pol->type != type)
-		return 0;
+		return ret;
 
 	match = xfrm_selector_match(sel, fl, family);
-	if (match) {
-		if (!security_xfrm_policy_lookup(pol, fl->secid, dir))
-			return 1;
-	}
+	if (match)
+		ret = security_xfrm_policy_lookup(pol, fl->secid, dir);
 
-	return 0;
+	return ret;
 }
 
 static struct xfrm_policy *xfrm_policy_lookup_bytype(u8 type, struct flowi *fl,
 						     u16 family, u8 dir)
 {
+	int err;
 	struct xfrm_policy *pol, *ret;
 	xfrm_address_t *daddr, *saddr;
 	struct hlist_node *entry;
@@ -919,7 +921,15 @@ static struct xfrm_policy *xfrm_policy_l
 	chain = policy_hash_direct(daddr, saddr, family, dir);
 	ret = NULL;
 	hlist_for_each_entry(pol, entry, chain, bydst) {
-		if (xfrm_policy_match(pol, fl, type, family, dir)) {
+		err = xfrm_policy_match(pol, fl, type, family, dir);
+		if (err) {
+			if (err == -ESRCH)
+				continue;
+			else {
+				ret = ERR_PTR(err);
+				goto fail;
+			}
+		} else {
 			ret = pol;
 			priority = ret->priority;
 			break;
@@ -927,36 +937,53 @@ static struct xfrm_policy *xfrm_policy_l
 	}
 	chain = &xfrm_policy_inexact[dir];
 	hlist_for_each_entry(pol, entry, chain, bydst) {
-		if (xfrm_policy_match(pol, fl, type, family, dir) &&
-		    pol->priority < priority) {
+		err = xfrm_policy_match(pol, fl, type, family, dir);
+		if (err) {
+			if (err == -ESRCH)
+				continue;
+			else {
+				ret = ERR_PTR(err);
+				goto fail;
+			}
+		} else if (pol->priority < priority) {
 			ret = pol;
 			break;
 		}
 	}
 	if (ret)
 		xfrm_pol_hold(ret);
+fail:
 	read_unlock_bh(&xfrm_policy_lock);
 
 	return ret;
 }
 
-static void xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
+static int xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
 			       void **objp, atomic_t **obj_refp)
 {
 	struct xfrm_policy *pol;
+	int err = 0;
 
 #ifdef CONFIG_XFRM_SUB_POLICY
 	pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_SUB, fl, family, dir);
-	if (pol)
+	if (IS_ERR(pol)) {
+		err = PTR_ERR(pol);
+		pol = NULL;
+	}
+	if (pol || err)
 		goto end;
 #endif
 	pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_MAIN, fl, family, dir);
-
+	if (IS_ERR(pol)) {
+		err = PTR_ERR(pol);
+		pol = NULL;
+	}
 #ifdef CONFIG_XFRM_SUB_POLICY
 end:
 #endif
 	if ((*objp = (void *) pol) != NULL)
 		*obj_refp = &pol->refcnt;
+	return err;
 }
 
 static inline int policy_to_flow_dir(int dir)
@@ -1294,6 +1321,8 @@ restart:
 
 		policy = flow_cache_lookup(fl, dst_orig->ops->family,
 					   dir, xfrm_policy_lookup);
+		if (IS_ERR(policy))
+			return PTR_ERR(policy);
 	}
 
 	if (!policy)
@@ -1340,6 +1369,10 @@ restart:
 							    fl, family,
 							    XFRM_POLICY_OUT);
 			if (pols[1]) {
+				if (IS_ERR(pols[1])) {
+					err = PTR_ERR(pols[1]);
+					goto error;
+				}
 				if (pols[1]->action == XFRM_POLICY_BLOCK) {
 					err = -EPERM;
 					goto error;
@@ -1578,6 +1611,9 @@ int __xfrm_policy_check(struct sock *sk,
 		pol = flow_cache_lookup(&fl, family, fl_dir,
 					xfrm_policy_lookup);
 
+	if (IS_ERR(pol))
+		return 0;
+
 	if (!pol) {
 		if (skb->sp && secpath_has_nontransport(skb->sp, 0, &xerr_idx)) {
 			xfrm_secpath_reject(xerr_idx, skb, &fl);
@@ -1596,6 +1632,8 @@ int __xfrm_policy_check(struct sock *sk,
 						    &fl, family,
 						    XFRM_POLICY_IN);
 		if (pols[1]) {
+			if (IS_ERR(pols[1]))
+				return 0;
 			pols[1]->curlft.use_time = (unsigned long)xtime.tv_sec;
 			npols ++;
 		}

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[Evgeniy Polyakov]

On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris (jmorris@namei.org) wrote:
> Updated version of the patch, which return directly after a flow cache 
> lookup error in xfrm_lookup rather than returing via the cleanup path 
> (which was causing a spurious dst_release).
> 
> This works for me, although I never saw the oops with the old patch.
> 
> Evgeniy, let me know if this fixes the oops you're seeing.

With enabled selinux in enforcing mode I can not even get messages to
racoon, i.e. tcpdump sees first message of the daemon, but racoon log
(with a lot of -d) is not changed.
With permissive mode everything works fine.

It is possible that it is 2.6.18 only problem though, I will try
previous kernels.

-- 
	Evgeniy Polyakov

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[James Morris]

On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:

> On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris (jmorris@namei.org) wrote:
> > Updated version of the patch, which return directly after a flow cache 
> > lookup error in xfrm_lookup rather than returing via the cleanup path 
> > (which was causing a spurious dst_release).
> > 
> > This works for me, although I never saw the oops with the old patch.
> > 
> > Evgeniy, let me know if this fixes the oops you're seeing.
> 
> With enabled selinux in enforcing mode I can not even get messages to
> racoon, i.e. tcpdump sees first message of the daemon, but racoon log
> (with a lot of -d) is not changed.
> With permissive mode everything works fine.

I think this could be your security policy denying access (which is a 
strong suspicion, becuase you hit the problem easily and it requires a 
policy denial).

Can you look in /var/log/audit/audit.log ? (especially grep for 
'association' )

What version of SELinux policy are you using?

i.e. $ rpm -q selinux-policy-targeted

If it's not very recent, like 2.3.16-9 or better, you may need to run a 
yum update.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[Evgeniy Polyakov]

On Mon, Oct 02, 2006 at 12:13:45PM -0400, James Morris (jmorris@namei.org) wrote:
> On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> 
> > On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris (jmorris@namei.org) wrote:
> > > Updated version of the patch, which return directly after a flow cache 
> > > lookup error in xfrm_lookup rather than returing via the cleanup path 
> > > (which was causing a spurious dst_release).
> > > 
> > > This works for me, although I never saw the oops with the old patch.
> > > 
> > > Evgeniy, let me know if this fixes the oops you're seeing.
> > 
> > With enabled selinux in enforcing mode I can not even get messages to
> > racoon, i.e. tcpdump sees first message of the daemon, but racoon log
> > (with a lot of -d) is not changed.
> > With permissive mode everything works fine.
> 
> I think this could be your security policy denying access (which is a 
> strong suspicion, becuase you hit the problem easily and it requires a 
> policy denial).
> 
> Can you look in /var/log/audit/audit.log ? (especially grep for 
> 'association' )

Indeed.

type=AVC msg=audit(1159804556.391:21): avc:  denied  { polmatch } for
pid=2213 comm="racoon" scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association

But then it is quite strange why FC5 2.6.17-1.2187_FC5smp works,
are there some bindings to the kernel version?
(my knowledge about selinux changes related to xfrm are somewhere
between zero and void).

> What version of SELinux policy are you using?
> 
> i.e. $ rpm -q selinux-policy-targeted

selinux-policy-targeted-2.3.7-2.fc5

> If it's not very recent, like 2.3.16-9 or better, you may need to run a 
> yum update.

I run it every day in cron and there are no updates at

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/i386/

behind my version.

> 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[James Morris]

On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:

> > Can you look in /var/log/audit/audit.log ? (especially grep for 
> > 'association' )
> 
> Indeed.
> 
> type=AVC msg=audit(1159804556.391:21): avc:  denied  { polmatch } for
> pid=2213 comm="racoon" scontext=root:system_r:unconfined_t:s0-s0:c0.c255
> tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association

Ok, that's it.

> But then it is quite strange why FC5 2.6.17-1.2187_FC5smp works,
> are there some bindings to the kernel version?
> (my knowledge about selinux changes related to xfrm are somewhere
> between zero and void).

The SELinux policy is loosely bound to the kernel version.  Generally, if 
you run development kernels, you need development SELinux policy.

> > What version of SELinux policy are you using?
> > 
> > i.e. $ rpm -q selinux-policy-targeted
> 
> selinux-policy-targeted-2.3.7-2.fc5

Yep, that's ancient.

> I run it every day in cron and there are no updates at
> 
> http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/i386/
> 
> behind my version.

You can get recent policy packages via the devel repo, which I'd suggest 
if you're using development (or DIY) kernels.



-- 
James Morris
<jmorris@namei.org>

RE: [PATCH] Fix for IPsec leakage with SELinux enabled

[Venkat Yekkirala]

> On Sun, 1 Oct 2006, Venkat Yekkirala wrote:
> 
> > > The way I was seeing the problem was when connecting via 
> IPsec to a 
> > > confined service on an SELinux box (vsftpd), which did 
> not have the 
> > > appropriate SELinux policy permissions to send packets via IPsec.
> > > 
> > > The first SYNACK would be blocked,
> > 
> > Given that the resolver fails to find a policy here, I am trying to
> > understand what exactly is blocking it (the first SYNACK) from
> > proceeding without IPSec.
> 
> You're right.  My explanation there was for the case where 
> I'd modified 
> the code to propagate the SELinux denial back to 
> xfrm_lookup(), and not 
> for the original issue (sorry, it's been a long week).
> 
> In the original case, all packets originating from a confined 
> domain will 
> bypass ipsec.  During xfrm_lookup, flow_cache_lookup() returns NULL 
> policy:
> 
> xfrm_lookup()
> {
> 	...
> 
> 	if (!policy) {
>                 /* To accelerate a bit...  */
>                 if ((dst_orig->flags & DST_NOXFRM) ||
>                     !xfrm_policy_count[XFRM_POLICY_OUT])
>                         return 0;
> 
>                 policy = flow_cache_lookup(fl, dst_orig->ops->family,
>                                            dir, xfrm_policy_lookup);
>         }
> 
>         if (!policy)
>                 return 0;  <- bad
> 	...
> }
> 
> The call chain is:
> 
> flow_cache_lookup()
>   xfrm_policy_lookup()
>    xfrm_policy_lookup_bytype()
>      xfrm_policy_match() {
>        xfrm_selector_match => returns true, then
>          security_xfrm_policy_lookup => returns -EACCESS
>      }
> 
> then
>      
> xfrm_policy_match() => returns 0
> xfrm_policy_lookup_bytype => returns 0
> xfrm_policy_lookup() => sets obj to NULL w/ void return
> flow_cache_lookup() => returns NULL
> xfrm_lookup => returns 0
> 
> and the packet proceeds without error and with no transform 
> applied (i.e. 
> leaked as cleartext).

This is indeed the "designed" and expected (for me) behavior. But I am
beginning to see where this is perhaps NOT in line with the user
expectation when the users have an IPSec policy rule that does NOT use
labels.

IOW, if they have their policy like (NO LABELS):

spdadd 192.168.4.79 192.168.4.78 any -P out ipsec
        esp/transport//require;

spdadd 192.168.4.78 192.168.4.79 any -P in ipsec
        esp/transport//require;

currently, EACH flow needing to use this rule MUST
have SELinux policy "polmatch"ing the flow context (ftpd_t)
to unlabeled_t (the implied in the absence of an explicit
context on the IPSec policy rule) or the traffic would flow
in clear text ("leaks" in user perception).

What I propose we do is to do the polmatch check ONLY when
there's an explicit label associated with the spd rule. Does
this sound reasonable and correct in the larger SELinux context?

In cases where there's an explicit label on an spd rule like:

spdadd 192.168.4.79 192.168.4.78 any -ctx 1 1
"system_u:object_r:labeled_ipsec_t:s2-s4"
	-P out ipsec
        esp/transport//require;

spdadd 192.168.4.78 192.168.4.79 any -ctx 1 1
"system_u:object_r:labeled_ipsec_t:s2-s4"
	-P in ipsec
        esp/transport//require;

then the current behavior (prior to this proposed patch) would be the
desired behavior, i.e., a polmatch denial in the SELinux module just
means that the flow isn't expected to undergo IPSec xfrms. IOW, there's
no need to propagate -EACCES all the way back up. We could still propagate
errors other than -EACCES if we like.

> 
> The first component of the fix is to propagate errors back up 
> to callers 
> via the flow cache resolver, and handle them correctly, as 
> this is where 
> we can experience security module denials.

This will cause problems with the case where we may have multiple
"labeled" spd rules, each of which should be attempted to be polmatched
against before letting the flow out in clear text, as would be expected
by the user as well.

> 
> The second component is to then ensure that, on failure,

-EACCES in this case is perceived as a failure since the
designed behavior doesn't seem to be in line with the user
expectation. Otherwise, with the above proposed change to
the design, there won't be a polmatch check in this case and
hence no failure.

It's probably still a good idea to propagate non-EACCES failures
back up the chain though.

> we 
> kill the new 
> flow cache entry created during lookup, so that it is not 
> subsequently 
> looked up with a null policy (i.e. allowing future packets to 
> leak) and to 
> force the security hook to be called again in case the policy 
> has changed.  
> 
> Hope that clarifies.
>     
> 
> - James
> -- 
> James Morris
> <jmorris@namei.org>
> 

RE: [PATCH] Fix for IPsec leakage with SELinux enabled

[James Morris]

On Mon, 2 Oct 2006, Venkat Yekkirala wrote:

> This is indeed the "designed" and expected (for me) behavior.

This is a security hole.  SELinux denies all access by default, so the 
default behavior of this code is to allow all traffic to bypass IPsec.

You should not need to add a rule to 'allow' increased security.

> But I am
> beginning to see where this is perhaps NOT in line with the user
> expectation when the users have an IPSec policy rule that does NOT use
> labels.
> currently, EACH flow needing to use this rule MUST
> have SELinux policy "polmatch"ing the flow context (ftpd_t)
> to unlabeled_t (the implied in the absence of an explicit
> context on the IPSec policy rule) or the traffic would flow
> in clear text ("leaks" in user perception).

Plaintext leak is not a user perception, it's an absolute.

> What I propose we do is to do the polmatch check ONLY when
> there's an explicit label associated with the spd rule. Does
> this sound reasonable and correct in the larger SELinux context?

I think so.

> In cases where there's an explicit label on an spd rule like:
> 
> spdadd 192.168.4.79 192.168.4.78 any -ctx 1 1
> "system_u:object_r:labeled_ipsec_t:s2-s4"
> 	-P out ipsec
>         esp/transport//require;
> 
> spdadd 192.168.4.78 192.168.4.79 any -ctx 1 1
> "system_u:object_r:labeled_ipsec_t:s2-s4"
> 	-P in ipsec
>         esp/transport//require;
> 
> then the current behavior (prior to this proposed patch) would be the
> desired behavior, i.e., a polmatch denial in the SELinux module just
> means that the flow isn't expected to undergo IPSec xfrms. IOW, there's
> no need to propagate -EACCES all the way back up. We could still propagate
> errors other than -EACCES if we like.

This needs to be handled within SELinux as far as possible, and errors 
will generally need to be propagated back to the callers, as we don't know 
what other LSMs might do, and errors unrelated to access control can be 
returned.


- James
-- 
James Morris
<jmorris@namei.org>

RE: [PATCH] Fix for IPsec leakage with SELinux enabled

[Venkat Yekkirala]

> > This is indeed the "designed" and expected (for me) behavior.
> 
> This is a security hole.  SELinux denies all access by 
> default, so the 
> default behavior of this code is to allow all traffic to bypass IPsec.
> 
> You should not need to add a rule to 'allow' increased security.

You are right. Currently working on a patch (should be out
tonight/tomorrow).

<snip>

> This needs to be handled within SELinux as far as possible, 
> and errors 
> will generally need to be propagated back to the callers, as 

Agreed here as well. I have yet to review your patch in depth,
but it definitely makes sense to do what you say here. Thanks.

> we don't know 
> what other LSMs might do, and errors unrelated to access 
> control can be 
> returned.
> 
> 
> - James
> -- 
> James Morris
> <jmorris@namei.org>
> 

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[David Miller]

From: James Morris <jmorris@namei.org>
Date: Mon, 2 Oct 2006 10:27:13 -0400 (EDT)

> Updated version of the patch, which return directly after a flow cache 
> lookup error in xfrm_lookup rather than returing via the cleanup path 
> (which was causing a spurious dst_release).
> 
> This works for me, although I never saw the oops with the old patch.
> 
> Evgeniy, let me know if this fixes the oops you're seeing.
> 
> Signed-off-by: James Morris <jmorris@namei.org>

As I review this patch I realize there is a question of
semantics and prioritization here.

For example, socket policies are handled such that if the security
layer gives an error we behave as if the socket policy did not match.

Whereas we handle sub vs. primary global policies differently.  If we
hit a sub-policy match, and we get a security layer error, we signal a
full lookup failure instead of trying to see if there is a primary
policy that the security layer likes.

I'm not saying either is wrong, I'm just pointing it out to make sure
this is intentional.

The socket policy behavior deserves some scrutiny.  I say this because
if a matching socket policy is avoided due to security layer error,
this could potentially make key manager problems very hard to
diagnose.

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[James Morris]

On Tue, 3 Oct 2006, David Miller wrote:

> I'm not saying either is wrong, I'm just pointing it out to make sure
> this is intentional.
> 
> The socket policy behavior deserves some scrutiny.  I say this because
> if a matching socket policy is avoided due to security layer error,
> this could potentially make key manager problems very hard to
> diagnose.

Yep, the code needs to be reworked in general (Venkat is doing this).



- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[Evgeniy Polyakov]

On Mon, Oct 02, 2006 at 12:41:57PM -0400, James Morris (jmorris@namei.org) wrote:
> You can get recent policy packages via the devel repo, which I'd suggest 
> if you're using development (or DIY) kernels.

[root@kano ~]# uname -a
Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686 i686 i386 GNU/Linux
[root@kano ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-2.3.17-2

I get only this messages in audit.log when remote racoon tries to
connect to system with selinux enabled in enforcing mode:

type=AVC msg=audit(1159938297.845:625): avc:  denied  { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
type=AVC msg=audit(1159938297.845:626): avc:  denied  { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938307.837:627): avc:  denied  { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938317.838:628): avc:  denied  { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938327.839:629): avc:  denied  { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association

It is with your patch applied.
Should I try Venkat's or it is unrelated problem?

> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[James Morris]

On Wed, 4 Oct 2006, Evgeniy Polyakov wrote:

> Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686 i686 i386 GNU/Linux
> [root@kano ~]# rpm -q selinux-policy-targeted
> selinux-policy-targeted-2.3.17-2
> 
> I get only this messages in audit.log when remote racoon tries to
> connect to system with selinux enabled in enforcing mode:
> 

I think the policy has just not been written for racoon, and it's being 
denied by deault (cd'd Dan Walsh).

> type=AVC msg=audit(1159938297.845:625): avc:  denied  { polmatch } for
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
> type=AVC msg=audit(1159938297.845:626): avc:  denied  { polmatch } for
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
> type=AVC msg=audit(1159938307.837:627): avc:  denied  { polmatch } for
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
> type=AVC msg=audit(1159938317.838:628): avc:  denied  { polmatch } for
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
> type=AVC msg=audit(1159938327.839:629): avc:  denied  { polmatch } for
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
> 
> It is with your patch applied.
> Should I try Venkat's or it is unrelated problem?
> 
> > -- 
> > James Morris
> > <jmorris@namei.org>
> 
> 

-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[Herbert Xu]

On Tue, Oct 03, 2006 at 04:18:07PM -0700, David Miller wrote:
> 
> As I review this patch I realize there is a question of
> semantics and prioritization here.

Indeed.  Unfortunately I was doing other things at the time
sub-policies were introduced so I didn't pay attention to it.

After a quick look, it seems that the intention is to perform
some sort of recursive lookup (restricted to 2 levels only).

If that is the intention, perhaps we should try to come up
with a better mechansim because hard-coding a single level
of recursion for mobility is probably not the best solution
as this is just a special case of the general nested tunnel
problem.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[James Morris]

On Tue, 3 Oct 2006, David Miller wrote:

> The socket policy behavior deserves some scrutiny.  I say this because
> if a matching socket policy is avoided due to security layer error,
> this could potentially make key manager problems very hard to
> diagnose.

In this case, AVC denial messages would be logged to the audit log, so 
there'd be an indication of what's going wrong.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02

[David Miller]

From: James Morris <jmorris@namei.org>
Date: Thu, 5 Oct 2006 16:58:31 -0400 (EDT)

> On Tue, 3 Oct 2006, David Miller wrote:
> 
> > The socket policy behavior deserves some scrutiny.  I say this because
> > if a matching socket policy is avoided due to security layer error,
> > this could potentially make key manager problems very hard to
> > diagnose.
> 
> In this case, AVC denial messages would be logged to the audit log, so 
> there'd be an indication of what's going wrong.

Ok.