Received: by 10.213.65.68 with SMTP id h4csp1998663imn; Sun, 8 Apr 2018 16:59:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/BGM0GQXqGpL+7jrt1B71fB4XMpn580SaztsGGrcfG4TVHydurRqjgfwNoN9+YRhYQ3qY/ X-Received: by 10.99.62.71 with SMTP id l68mr23463470pga.205.1523231966898; Sun, 08 Apr 2018 16:59:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523231966; cv=none; d=google.com; s=arc-20160816; b=Vtmykpfef+Ql2CILkGoPanjUV5PY4ZnYnn4ESFhZDBC2vEBVPIr9VAygKZlCyitGT2 ztUV+AMIa1uW13KxWC3tx/OWx3ddMIu+YR08lv8W/S7ix+swOALdAacrTU+ic2vBflHn +UXBOOUIsD2So1Zlfbcl9CTIu5F/3OJ3QxYCkVILfFNB4zAgPAblQekdfuwB6X15OzRx 45rOPSh73YR/DFZB1MOgQssVM3Ex7UzHVG9GkmxZZLMQf7t1VvWxSE0Ei7mkNHCsEzt4 zHOAfYGPcQ96edueBIRITUoxfl2dPZRP8y0nxef2Utfk31KC4JBhkVjYlUp/FvORmdkf A0Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=WwpQLP6sTzjHu3k4+MxtO6V4mc+k5svOz9SRoeY6G3U=; b=k3EYrEvozQRws97s2/w10NBMmvaN/z5WdkBnMPbu1xm+FtN8MKuZqq/M2ItAXIenX7 ewc0StVetKWsKQKsENMCtCkIx4okB2wt/UhQYJYlGxgPu/nOS5/Bz+KjmJ/iH/vwbew9 mooBoKfx7MYHVhnQcisMHS8AmZMUmZavuV7S7Ok9kaDTHlXlQ6kN2qMA9cFH6+G1jBmx 5CGR9FjE1hkKxlsdmBHFYJMpv2X2tmIX6SlPAEh7SAnvzbM1hk3wRW3msu0f6aDViTNr 0xgUzCq7dl2bEwLuVxRGCuQQYJ84aPTJfXY5nJgkAQAWPp9dptB3ocfeLeJpYUMvOUHh pxvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@btinternet.com header.s=btcpcloud header.b=IJhg7dXn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=btinternet.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 91-v6si13340780plh.127.2018.04.08.16.58.50; Sun, 08 Apr 2018 16:59:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@btinternet.com header.s=btcpcloud header.b=IJhg7dXn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=btinternet.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752678AbeDHWoR (ORCPT + 99 others); Sun, 8 Apr 2018 18:44:17 -0400 Received: from rgout0703.bt.lon5.cpcloud.co.uk ([65.20.0.143]:61868 "EHLO rgout0703.bt.lon5.cpcloud.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752285AbeDHWoQ (ORCPT ); Sun, 8 Apr 2018 18:44:16 -0400 X-OWM-Source-IP: 81.132.46.200 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtgedrheefgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffuhffvffgjfhgtofgggfesthejredtredtjeenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuffhomhgrihhnpehtihhonhdrohhrghdpkhgvrhhnvghlrdhorhhgpdhgihhthhhusgdrtghomhdpmhgrrhgtrdhinhhfohdpphgruhhlqdhmohhorhgvrdgtohhmnecukfhppeekuddrudefvddrgeeirddvtddtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepkedurddufedvrdegiedrvddttddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuvehluhhsthgvrhfuihiivgeptd Received: from localhost.localdomain (81.132.46.200) by rgout07.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as richard_c_haines@btinternet.com) id 5ABD09F900D16CEA; Sun, 8 Apr 2018 23:44:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1523227456; bh=WwpQLP6sTzjHu3k4+MxtO6V4mc+k5svOz9SRoeY6G3U=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:X-Mailer:Mime-Version; b=IJhg7dXndXYJ6b+8rIhpRMZfOs6GN0rnJgytZbTrxK9W+a75CjrvqO19QJbyCVULXyh0F6dGGsReMG6Ix2tYKczI0wgUvwMZgTvJ8g5WTtzP+sBUe/m1hMJc+cFfWmE/wenQ4bKnWQK2eqQrwejg6VcSIqeWpTSLr0fobWpuH8Y= Message-ID: <1523227451.5003.1.camel@btinternet.com> Subject: Re: [GIT PULL] SELinux patches for v4.17 From: Richard Haines To: Xin Long Cc: LSM List , Linus Torvalds , selinux@tycho.nsa.gov, Linux Kernel Mailing List Date: Sun, 08 Apr 2018 23:44:11 +0100 In-Reply-To: <1523213955.3552.9.camel@btinternet.com> References: <1523120055.31267.13.camel@btinternet.com> <162a54f1470.2781.85c95baa4474aabc7814e68940a78392@paul-moore.com> <1523196560.6192.3.camel@btinternet.com> <1523213955.3552.9.camel@btinternet.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 (3.26.5-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2018-04-08 at 19:59 +0100, Richard Haines via Selinux wrote: > On Mon, 2018-04-09 at 01:43 +0800, Xin Long wrote: > > On Sun, Apr 8, 2018 at 10:09 PM, Richard Haines > > wrote: > > > On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote: > > > > On April 7, 2018 1:03:57 PM Linus Torvalds > > > da > > > > tion > > > > .org> wrote: > > > > On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines > > > > wrote: > > > > > > > > So please check my resolution, but also somebody should tell me > > > > "Linus, you're a cretin, sctp_connect() doesn't want that > > > > security_sctp_bind_connect() at all because it was already done > > > > by > > > > XYZ" > > > > > > > > sctp_connect() or __sctp_connect() do not need to call > > > > security_sctp_bind_connect(). This is because the connect(2) > > > > call > > > > will > > > > handle the checks required via security_socket_connect(): > > > > > > > > Ok, thanks, that's exactly what I wanted to get. > > > > > > > > Anyway, somebody should still verify that it all looks good in > > > > my > > > > tree, but I don't actually expect the merge to have had any > > > > issues > > > > even if the refactoring made it a bit more complex than most > > > > merges > > > > are. > > > > > > > > Thanks for the quick response Richard. > > > > > > > > Xin Long looked it over and gave it the thumbs up, I'll take a > > > > look > > > > too, but to be honest I trust his SCTP understanding much more > > > > than > > > > mine. I also do weekly tests of each rcX release at a minimum > > > > so > > > > if > > > > something odd pops up I'll make sure you get a fix. > > > > > > > > Thanks again everyone. > > > > > > I built the kernel this morning and sorry to spoil the party, but > > > I've > > > run into a problem with lksctp-tools when running the func_tests: > > > > > > make v6test > > > .. > > > .. > > > ./test_timetolive_v6 > > > test_timetolive.c 0 INFO : Creating fillmsg of size 3087 > > > test_timetolive.c 1 PASS : Send a message with timeout > > > test_timetolive.c 2 PASS : Send a message with no timeout > > > test_timetolive.c 3 PASS : Send a fragmented message with > > > timeout > > > test_timetolive.c 0 INFO : ** SLEEPING for 3 seconds ** > > > test_timetolive.c 4 BROK : Got a datamsg of unexpected > > > length:23, > > > expected length:27 > > > DUMP_CORE sctputil.c: 247 > > > /bin/sh: line 1: 30981 Segmentation fault (core dumped) ./$a > > > test_timetolive_v6 fails > > > > > > make v4 test fails the same way. I'm using lksctp-tools from [1]. > > > I > > > have not investigated the cause yet as just found this and > > > thought > > > I > > > should flag first just in case someone has the answer !!! > > > > test_timetolive(_v6) works for me, In lksctp-tools/src/func_tests, > > I > > had > > another case failed,./test_1_to_1_events, it's caused by: > > commit 30f6ebf65bc46161c5aaff1db2e6e7c76aa4a06b > > Author: Xin Long > > Date: Wed Mar 14 19:05:34 2018 +0800 > > > > sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT > > > > It's not kernel's issue, after that commit, ./test_1_to_1_events > > should > > have been improved. or avoid it by 'sysctl -w > > net.sctp.auth_enable=1' > > > > I'm not sure why test_timetolive(_v6) is not working in your env. > > It appears to depend on the run sequence of the tests. I rebooted the > system, ran test_timetolive_v6, it worked okay. > Ran "sctp-tests run" on a terminal, then ran test_timetolive_v6 at > various intervals on another terminal. Once sctp-tests started the > "=== > ndatasched ===" sequence, test_timetolive_v6 failed. 1) When SCTP is initialised /proc/sys/net/sctp/prsctp_enable = 1 2) When sctp-tests/testcase/regression/extoverflow/test.sh is executed, on exit it sets prsctp_enable = 0. This seems to be causing the issue I'm seeing. I can now simulate the problem: Running from fresh boot: checksctp cat /proc/sys/net/sctp/prsctp_enable 1 ./test_timetolive_v6 passes echo 0 > /proc/sys/net/sctp/prsctp_enable ./test_timetolive_v6 fails echo 1 > /proc/sys/net/sctp/prsctp_enable ./test_timetolive_v6 passes I've no idea why as yet !!! > > > > > > > > > On the bright side, I've run the sctp-tests from [2] with no > > > problems > > > and also the selinux-testsuite with my SCTP patch from [3] using > > > an > > > updated Fedora policy from [4] (with sctp support added), all in > > > enforcing mode. > > > > > > Also the LTP test passed: > > > cd /opt/ltp/ > > > cat runtest/syscalls |grep connect01>runtest/connect-syscall > > > ./runltp -pq -f connect-syscall > > > .... > > > > > > [1] https://github.com/sctp/lksctp-tools > > > [2] https://github.com/sctp/sctp-tests > > > [3] https://marc.info/?l=selinux&m=152156947715709&w=2 > > > [4] https://github.com/fedora-selinux/selinux-policy > > > > > > > > > > > > > > -- > > > > paul moore > > > > www.paul-moore.com > > > > > > > > > > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > security-module" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > >