* [PATCH] tests/sctp: remove assumptions in the SCTP tests
@ 2022-07-18 22:29 Paul Moore
2022-07-19 11:58 ` Ondrej Mosnacek
0 siblings, 1 reply; 11+ messages in thread
From: Paul Moore @ 2022-07-18 22:29 UTC (permalink / raw)
To: selinux
Rework the SCTP tests slightly to remove two assumptions which are
not always guaranteed to be true (below). This should have not any
affect on the current test suite or released kernels, but it will
help ensure that the test suite continues to work with upcoming
kernel releases.
* Do not rely on IP options attached to a socket. Depending on the
kernel configuration, the on-the-wire packet labels may be
generated on a per-packet basis as opposed to a per-socket basis.
* Ensure the kernel's SCTP association state is properly reset by
restarting the SCTP test server between tests which require it.
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
tests/sctp/sctp_client.c | 22 +-
tests/sctp/sctp_common.c | 42 +++++
tests/sctp/sctp_common.h | 2
tests/sctp/sctp_peeloff_client.c | 21 +-
tests/sctp/sctp_peeloff_server.c | 20 +-
tests/sctp/sctp_server.c | 28 +--
tests/sctp/test | 352 ++++++++++++++++++++++++++++----------
7 files changed, 332 insertions(+), 155 deletions(-)
diff --git a/tests/sctp/sctp_client.c b/tests/sctp/sctp_client.c
index 2f527ed..2b2f4b6 100644
--- a/tests/sctp/sctp_client.c
+++ b/tests/sctp/sctp_client.c
@@ -22,22 +22,20 @@ static void usage(char *progname)
int main(int argc, char **argv)
{
int opt, sock, result, save_errno;
- socklen_t opt_len;
struct addrinfo hints, *serverinfo;
char byte = 0x41, label[1024], *expected = NULL;
bool verbose = false, connectx = false, no_connects = false;
- bool ipv4 = false, expect_ipopt = false;
+ bool ipv4 = false;
+ bool expected_flg = false;
char *context;
struct timeval tm;
- while ((opt = getopt(argc, argv, "e:vxmni")) != -1) {
+ while ((opt = getopt(argc, argv, "e:vxmn")) != -1) {
switch (opt) {
case 'e':
+ expected_flg = true;
expected = optarg;
break;
- case 'i':
- expect_ipopt = true;
- break;
case 'v':
verbose = true;
break;
@@ -165,8 +163,6 @@ int main(int argc, char **argv)
print_context(sock, "Client STREAM read");
print_ip_option(sock, ipv4, "Client STREAM read");
}
- if (expect_ipopt)
- expected = get_ip_option(sock, ipv4, &opt_len);
} else { /* hints.ai_socktype == SOCK_SEQPACKET */
@@ -193,14 +189,12 @@ int main(int argc, char **argv)
close(sock);
exit(13);
}
- if (expect_ipopt)
- expected = get_ip_option(sock, ipv4, &opt_len);
}
label[result] = 0;
close(sock);
- if (!expected && !expect_ipopt) {
+ if (!expected) {
result = getcon(&expected);
if (result < 0) {
perror("Client getcon");
@@ -208,7 +202,11 @@ int main(int argc, char **argv)
}
}
- if (strcmp(expected, label)) {
+ if (!expected_flg && cmp_context_mls(expected, label)) {
+ fprintf(stderr, "Client expected %s, got %s\n",
+ expected, label);
+ exit(15);
+ } else if (expected_flg && cmp_context_type_mls(expected, label)) {
fprintf(stderr, "Client expected %s, got %s\n",
expected, label);
exit(15);
diff --git a/tests/sctp/sctp_common.c b/tests/sctp/sctp_common.c
index 8b65870..02bbf5d 100644
--- a/tests/sctp/sctp_common.c
+++ b/tests/sctp/sctp_common.c
@@ -3,6 +3,48 @@
#define member_size(type, member) sizeof(((type *)0)->member)
#define sizeof_up_to(type, member) (offsetof(type, member) + member_size(type, member))
+static int __cmp_context(int skip_fields, const char *a, const char *b)
+{
+ int i;
+ const char *aptr = a;
+ const char *bptr = b;
+
+ /* we only support skipping at most the user:role:type */
+ if (skip_fields > 3)
+ goto malformed;
+
+ /* skip past the specified number of fields */
+ for (i=0; i < skip_fields; i++) {
+ aptr = strchr(aptr, ':');
+ if (!aptr)
+ goto malformed;
+ if (*(++aptr) == '\0')
+ goto malformed;
+ bptr = strchr(bptr, ':');
+ if (!bptr)
+ goto malformed;
+ if (*(++bptr) == '\0')
+ goto malformed;
+ }
+
+ return strcmp(aptr, bptr);
+
+malformed:
+ return strcmp(a, b);
+}
+
+int cmp_context_mls(const char *a, const char *b)
+{
+ /* skip user:role:type */
+ return __cmp_context(3, a, b);
+}
+
+int cmp_context_type_mls(const char *a, const char *b)
+{
+ /* skip user:role */
+ return __cmp_context(2, a, b);
+}
+
void print_context(int fd, char *text)
{
char *context;
diff --git a/tests/sctp/sctp_common.h b/tests/sctp/sctp_common.h
index cb69f70..3a2545a 100644
--- a/tests/sctp/sctp_common.h
+++ b/tests/sctp/sctp_common.h
@@ -27,6 +27,8 @@ enum event_ret {
EVENT_NO_AUTH
};
+int cmp_context_mls(const char *a, const char *b);
+int cmp_context_type_mls(const char *a, const char *b);
void print_context(int fd, char *text);
void print_addr_info(struct sockaddr *sin, char *text);
char *get_ip_option(int fd, bool ipv4, socklen_t *opt_len);
diff --git a/tests/sctp/sctp_peeloff_client.c b/tests/sctp/sctp_peeloff_client.c
index bc719a5..8597b81 100644
--- a/tests/sctp/sctp_peeloff_client.c
+++ b/tests/sctp/sctp_peeloff_client.c
@@ -22,23 +22,22 @@ int main(int argc, char **argv)
int opt, sock, result, save_errno, peeloff_sk = 0, flags;
int on = 1, off = 0;
sctp_assoc_t assoc_id = 0;
- socklen_t sinlen, opt_len;
+ socklen_t sinlen;
struct sockaddr_storage sin;
struct addrinfo hints, *serverinfo;
char byte = 0x41, label[1024], *expected = NULL;
bool verbose = false, connectx = false, no_connects = false;
- bool ipv4 = false, expect_ipopt = false;
+ bool ipv4 = false;
+ bool expected_flg = false;
char *context;
struct timeval tm;
- while ((opt = getopt(argc, argv, "e:vxmni")) != -1) {
+ while ((opt = getopt(argc, argv, "e:vxmn")) != -1) {
switch (opt) {
case 'e':
+ expected_flg = true;
expected = optarg;
break;
- case 'i':
- expect_ipopt = true;
- break;
case 'v':
verbose = true;
break;
@@ -227,14 +226,12 @@ int main(int argc, char **argv)
close(sock);
exit(13);
}
- if (expect_ipopt)
- expected = get_ip_option(peeloff_sk, ipv4, &opt_len);
label[result] = 0;
close(peeloff_sk);
close(sock);
- if (!expected && !expect_ipopt) {
+ if (!expected) {
result = getcon(&expected);
if (result < 0) {
perror("Client getcon");
@@ -242,7 +239,11 @@ int main(int argc, char **argv)
}
}
- if (strcmp(expected, label)) {
+ if (!expected_flg && cmp_context_mls(expected, label)) {
+ fprintf(stderr, "Client expected %s, got %s\n",
+ expected, label);
+ exit(15);
+ } else if (expected_flg && cmp_context_type_mls(expected, label)) {
fprintf(stderr, "Client expected %s, got %s\n",
expected, label);
exit(15);
diff --git a/tests/sctp/sctp_peeloff_server.c b/tests/sctp/sctp_peeloff_server.c
index bd797f2..3e48df7 100644
--- a/tests/sctp/sctp_peeloff_server.c
+++ b/tests/sctp/sctp_peeloff_server.c
@@ -3,11 +3,10 @@
static void usage(char *progname)
{
fprintf(stderr,
- "usage: %s [-4] [-f file] [-i] [-n] [-v] port\n"
+ "usage: %s [-4] [-f file] [-n] [-v] port\n"
"\nWhere:\n\t"
"-4 Listen on IPv4 addresses only.\n\t"
"-f Write a line to the file when listening starts.\n\t"
- "-i Send IP Options as msg (default is peer label).\n\t"
"-n No peer context will be available therefore send\n\t"
" \"nopeer\" message to client, otherwise the peer context\n\t"
" will be retrieved and sent to client.\n\t"
@@ -20,14 +19,14 @@ int main(int argc, char **argv)
{
int opt, sock, result, peeloff_sk = 0, flags, on = 1, off = 0;
sctp_assoc_t assoc_id = 0;
- socklen_t sinlen, opt_len;
+ socklen_t sinlen;
struct sockaddr_storage sin;
struct addrinfo hints, *res;
char *peerlabel, *context, *flag_file = NULL, msglabel[256];
- bool nopeer = false, verbose = false, ipv4 = false, snd_opt = false;
+ bool nopeer = false, verbose = false, ipv4 = false;
unsigned short port;
- while ((opt = getopt(argc, argv, "4f:inv")) != -1) {
+ while ((opt = getopt(argc, argv, "4f:nv")) != -1) {
switch (opt) {
case '4':
ipv4 = true;
@@ -35,9 +34,6 @@ int main(int argc, char **argv)
case 'f':
flag_file = optarg;
break;
- case 'i':
- snd_opt = true;
- break;
case 'n':
nopeer = true;
break;
@@ -201,11 +197,6 @@ int main(int argc, char **argv)
if (nopeer) {
peerlabel = strdup("nopeer");
- } else if (snd_opt) {
- peerlabel = get_ip_option(sock, ipv4, &opt_len);
-
- if (!peerlabel)
- peerlabel = strdup("no_ip_options");
} else {
result = getpeercon(peeloff_sk, &peerlabel);
if (result < 0) {
@@ -216,8 +207,7 @@ int main(int argc, char **argv)
}
}
- printf("Server PEELOFF %s: %s\n",
- snd_opt ? "sock_opt" : "peer label", peerlabel);
+ printf("Server PEELOFF peer label: %s\n", peerlabel);
result = sctp_sendmsg(peeloff_sk, peerlabel,
strlen(peerlabel),
diff --git a/tests/sctp/sctp_server.c b/tests/sctp/sctp_server.c
index c53f46f..a7832eb 100644
--- a/tests/sctp/sctp_server.c
+++ b/tests/sctp/sctp_server.c
@@ -3,7 +3,7 @@
static void usage(char *progname)
{
fprintf(stderr,
- "usage: %s [-4] [-b ipv4_addr] [-f file] [-h addr] [-i] [-n] [-v] stream|seq port\n"
+ "usage: %s [-4] [-b ipv4_addr] [-f file] [-h addr] [-n] [-v] stream|seq port\n"
"\nWhere:\n\t"
"-4 Listen on IPv4 addresses only (used for CIPSO tests).\n\t"
"-b Call sctp_bindx(3) with the supplied IPv4 address.\n\t"
@@ -11,7 +11,6 @@ static void usage(char *progname)
"-h IPv4 or IPv6 listen address. If IPv6 link-local address,\n\t"
" then requires the %%<if_name> to obtain scopeid. e.g.\n\t"
" fe80::7629:afff:fe0f:8e5d%%wlp6s0\n\t"
- "-i Send IP Options as msg (default is peer label).\n\t"
"-n No peer label or IP option will be available therefore\n\t"
" send \"nopeer\" message to client.\n\t"
"-v Print context and ip options information.\n\t"
@@ -24,19 +23,19 @@ static void usage(char *progname)
int main(int argc, char **argv)
{
int opt, sock, newsock, result, if_index = 0, on = 1, off = 0;
- socklen_t sinlen, opt_len;
+ socklen_t sinlen;
struct sockaddr_storage sin;
struct addrinfo hints, *res;
struct sctp_sndrcvinfo sinfo;
struct pollfd poll_fd;
char getsockopt_peerlabel[1024];
char byte, *peerlabel, msglabel[1024], if_name[30];
- bool nopeer = false, verbose = false, ipv4 = false, snd_opt = false;
+ bool nopeer = false, verbose = false, ipv4 = false;
char *context, *host_addr = NULL, *bindx_addr = NULL, *flag_file = NULL;
struct sockaddr_in ipv4_addr;
unsigned short port;
- while ((opt = getopt(argc, argv, "4b:f:h:inv")) != -1) {
+ while ((opt = getopt(argc, argv, "4b:f:h:nv")) != -1) {
switch (opt) {
case '4':
ipv4 = true;
@@ -50,9 +49,6 @@ int main(int argc, char **argv)
case 'h':
host_addr = optarg;
break;
- case 'i':
- snd_opt = true;
- break;
case 'n':
nopeer = true;
break;
@@ -212,11 +208,6 @@ int main(int argc, char **argv)
if (nopeer) {
peerlabel = strdup("nopeer");
- } else if (snd_opt) {
- peerlabel = get_ip_option(newsock, ipv4,
- &opt_len);
- if (!peerlabel)
- peerlabel = strdup("no_ip_options");
} else {
result = getpeercon(newsock, &peerlabel);
if (result < 0) {
@@ -241,8 +232,7 @@ int main(int argc, char **argv)
printf("Server STREAM SO_PEERSEC peer label: %s\n",
getsockopt_peerlabel);
}
- printf("Server STREAM %s: %s\n",
- snd_opt ? "sock_opt" : "peer label", peerlabel);
+ printf("Server STREAM peer label: %s\n", peerlabel);
result = read(newsock, &byte, 1);
if (result < 0) {
@@ -307,11 +297,6 @@ int main(int argc, char **argv)
if (nopeer) {
peerlabel = strdup("nopeer");
- } else if (snd_opt) {
- peerlabel = get_ip_option(sock, ipv4, &opt_len);
-
- if (!peerlabel)
- peerlabel = strdup("no_ip_options");
} else {
result = getpeercon(sock, &peerlabel);
if (result < 0) {
@@ -320,8 +305,7 @@ int main(int argc, char **argv)
exit(1);
}
}
- printf("Server SEQPACKET %s: %s\n",
- snd_opt ? "sock_opt" : "peer label", peerlabel);
+ printf("Server SEQPACKET peer label: %s\n", peerlabel);
if (sin.ss_family == AF_INET6 && host_addr)
((struct sockaddr_in6 *)&sin)->sin6_scope_id = if_index;
diff --git a/tests/sctp/test b/tests/sctp/test
index a0db527..51c812f 100755
--- a/tests/sctp/test
+++ b/tests/sctp/test
@@ -409,34 +409,34 @@ system "/bin/sh $basedir/fb-deny-label-flush";
#
############################## CIPSO/IPv4 TAG 1 ###############################
#
-print "# Testing CIPSO/IPv4 - TAG 1 using socket ip_option data\n";
+print "# Testing CIPSO/IPv4 - TAG 1\n";
system "/bin/sh $basedir/cipso-load-t1";
# Start the stream server for IPv4 only.
$pid = server_start(
"-t test_sctp_server_t -l s0:c182.c192",
"sctp_server",
- "$v -4 -i stream 1035"
+ "$v -4 stream 1035"
);
# Verify that authorized client can communicate with the server STREAM->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_client $v -x -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_client $v -x stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server STREAM->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level STREAM->STREAM.
$result = system
-"runcon -t test_sctp_client_t -l s0:c182,c187,c190 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c182,c187,c190 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level SEQ->STREAM
$result = system
-"runcon -t test_sctp_client_t -l s0:c189,c192 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c189,c192 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client cannot communicate with the server using invalid level STREAM->STREAM.
@@ -449,17 +449,17 @@ if ($test_clpeeloff) {
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_peeloff_client $v -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_peeloff_client $v 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_peeloff_client $v -x -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_peeloff_client $v -x 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_peeloff_client $v -n -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c182.c192 $basedir/sctp_peeloff_client $v -n 127.0.0.1 1035";
ok( $result eq 0 );
}
@@ -470,77 +470,117 @@ server_end($pid);
$pid = server_start(
"-t test_sctp_server_t -l s0:c20.c300",
"sctp_server",
- "$v -4 -i seq 1035"
+ "$v -4 seq 1035"
);
# Verify that authorized client can communicate with the server. SEQ->SEQ
$result = system
-"runcon -t test_sctp_client_t -l s0:c27.c28 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c27,c28 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c27,c28 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c300",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
# Verify that authorized client can communicate with the server using SEQ->SEQ with diff valid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c24,c26,c27.c29 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c24,c26.c29 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c300",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
# Verify that client cannot communicate with the server using SEQ->SEQ with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c19.c100 -- $basedir/sctp_client $v -i seq 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c19.c100 -- $basedir/sctp_client $v seq 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 6 );
-# TAG 1 allows categories 0 to 239 to be sent, if greater then ENOSPC (No space left on device)
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c300",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
+# TAG 1 allows categories 0 to 239 to be sent
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c300 -- $basedir/sctp_client $v -i seq 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c20.c300 -- $basedir/sctp_client $v seq 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 7 );
if ($test_clpeeloff) {
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c300",
+ "sctp_server",
+ "$v -4 seq 1035"
+ );
+
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -x -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -x 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -n -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -n 127.0.0.1 1035";
ok( $result eq 0 );
}
# Kill server.
server_end($pid);
-print "# Testing CIPSO/IPv4 - TAG 1 PEELOFF using socket ip_option data\n";
+print "# Testing CIPSO/IPv4 - TAG 1 PEELOFF\n";
# Test sctp_peeloff(3) server using 1 to Many SOCK_SEQPACKET
$pid = server_start(
"-t test_sctp_server_t -l s0:c0.c10",
"sctp_peeloff_server",
- "$v -4 -i 1035"
+ "$v -4 1035"
);
# Verify that authorized client can communicate with the server using SEQ->SEQ->Peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ->peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x stream 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c0.c10",
+ "sctp_peeloff_server",
+ "$v -4 1035"
+);
+
# Verify that client cannot communicate with the server using STREAM->SEQ->peeloff with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x -i stream 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x stream 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 6 );
# Kill the seq server.
@@ -551,32 +591,32 @@ system "/bin/sh $basedir/cipso-flush";
#
############################## CIPSO/IPv4 TAG 2 ###############################
#
-print "# Testing CIPSO/IPv4 - TAG 2 using socket ip_option data\n";
+print "# Testing CIPSO/IPv4 - TAG 2\n";
system "/bin/sh $basedir/cipso-load-t2";
# Start the stream server for IPv4 only.
$pid = server_start(
"-t test_sctp_server_t -l s0:c782,c714,c769,c788,c803,c842,c864",
- "sctp_server", "$v -4 -i stream 1035" );
+ "sctp_server", "$v -4 stream 1035" );
# Verify that authorized client can communicate with the server STREAM->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v -x -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v -x stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server STREAM->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level STREAM->STREAM.
$result = system
-"runcon -t test_sctp_client_t -l s0:c769,c788,c803,c842,c864 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c769,c788,c803,c842,c864 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level SEQ->STREAM
$result = system
-"runcon -t test_sctp_client_t -l s0:c769,c788,c803 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c769,c788,c803 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client cannot communicate with the server using invalid level STREAM->STREAM.
@@ -588,17 +628,17 @@ if ($test_clpeeloff) {
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -x -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -x 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -n -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -n 127.0.0.1 1035";
ok( $result eq 0 );
}
@@ -609,77 +649,117 @@ server_end($pid);
$pid = server_start(
"-t test_sctp_server_t -l s0:c20.c335",
"sctp_server",
- "$v -4 -i seq 1035"
+ "$v -4 seq 1035"
);
# Verify that authorized client can communicate with the server. SEQ->SEQ
$result = system
-"runcon -t test_sctp_client_t -l s0:c328.c333 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c328.c333 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c34 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c328.c333 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c335",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
# Verify that authorized client can communicate with the server using SEQ->SEQ with diff valid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30,c31,c335 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30,c31,c335 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c335",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
# Verify that client cannot communicate with the server using SEQ->SEQ with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c19.c30 -- $basedir/sctp_client $v -i seq 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c19.c30 -- $basedir/sctp_client $v seq 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 6 );
-# TAG 2 allows a maximum of 15 categories in exchange, if greater then ENOSPC (No space left on device)
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c335",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
+# TAG 2 allows a maximum of 15 categories in exchange
$result = system
-"runcon -t test_sctp_client_t -l s0:c200.c216 -- $basedir/sctp_client $v -i seq 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c200.c216 -- $basedir/sctp_client $v seq 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 7 );
if ($test_clpeeloff) {
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c335",
+ "sctp_server",
+ "$v -4 seq 1035"
+ );
+
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -x -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -x 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -n -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30 $basedir/sctp_peeloff_client $v -n 127.0.0.1 1035";
ok( $result eq 0 );
}
# Kill server.
server_end($pid);
-print "# Testing CIPSO/IPv4 - TAG 2 PEELOFF using socket ip_option data\n";
+print "# Testing CIPSO/IPv4 - TAG 2 PEELOFF\n";
# Test sctp_peeloff(3) server using 1 to Many SOCK_SEQPACKET
$pid = server_start(
"-t test_sctp_server_t -l s0:c0.c10",
"sctp_peeloff_server",
- "$v -4 -i 1035"
+ "$v -4 1035"
);
# Verify that authorized client can communicate with the server using SEQ->SEQ->Peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ->peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x stream 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c0.c10",
+ "sctp_peeloff_server",
+ "$v -4 1035"
+);
+
# Verify that client cannot communicate with the server using STREAM->SEQ->peeloff with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x -i stream 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x stream 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 6 );
# Kill the seq server.
@@ -690,32 +770,32 @@ system "/bin/sh $basedir/cipso-flush";
#
############################## CIPSO/IPv4 TAG 5 ###############################
#
-print "# Testing CIPSO/IPv4 - TAG 5 using socket ip_option data\n";
+print "# Testing CIPSO/IPv4 - TAG 5\n";
system "/bin/sh $basedir/cipso-load-t5";
# Start the stream server for IPv4 only.
$pid = server_start(
"-t test_sctp_server_t -l s0:c782,c714,c769,c788,c803,c842,c864",
- "sctp_server", "$v -4 -i stream 1035" );
+ "sctp_server", "$v -4 stream 1035" );
# Verify that authorized client can communicate with the server STREAM->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v -x -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v -x stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server STREAM->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level STREAM->STREAM.
$result = system
-"runcon -t test_sctp_client_t -l s0:c769,c788,c803,c842,c864 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c769,c788,c803,c842,c864 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level SEQ->STREAM
$result = system
-"runcon -t test_sctp_client_t -l s0:c769,c788,c803 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c769,c788,c803 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client cannot communicate with the server using invalid level STREAM->STREAM.
@@ -727,17 +807,17 @@ if ($test_clpeeloff) {
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -x -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -x 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -n -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c782,c714,c769,c788,c803,c842,c864 $basedir/sctp_peeloff_client $v -n 127.0.0.1 1035";
ok( $result eq 0 );
}
@@ -748,77 +828,117 @@ server_end($pid);
$pid = server_start(
"-t test_sctp_server_t -l s0:c20.c50",
"sctp_server",
- "$v -4 -i seq 1035"
+ "$v -4 seq 1035"
);
# Verify that authorized client can communicate with the server. SEQ->SEQ
$result = system
-"runcon -t test_sctp_client_t -l s0:c28.c48 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c28.c48 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_client $v -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c28.c48 $basedir/sctp_client $v stream 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
# Verify that authorized client can communicate with the server using SEQ->SEQ with diff valid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30,c31,c35,c40.c45 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30,c31,c35,c40.c45 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
# Verify that client cannot communicate with the server using SEQ->SEQ with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c51 -- $basedir/sctp_client $v -i seq 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c20.c51 -- $basedir/sctp_client $v seq 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 6 );
-# TAG 2 allows a maximum of 7 ranges in exchange, if greater then ENOSPC (No space left on device)
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v -4 seq 1035"
+);
+
+# TAG 2 allows a maximum of 7 ranges in exchange
$result = system
-"runcon -t test_sctp_client_t -l s0:c20,c22,c24,c30.c33,c38,c42.c45,c48,c50 -- $basedir/sctp_client $v -i seq 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c20,c22,c24,c30.c33,c38,c42.c45,c48,c50 -- $basedir/sctp_client $v seq 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 7 );
if ($test_clpeeloff) {
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v -4 seq 1035"
+ );
+
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -x -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -x 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -n -i 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -n 127.0.0.1 1035";
ok( $result eq 0 );
}
# Kill server.
server_end($pid);
-print "# Testing CIPSO/IPv4 - TAG 5 PEELOFF using socket ip_option data\n";
+print "# Testing CIPSO/IPv4 - TAG 5 PEELOFF\n";
# Test sctp_peeloff(3) server using 1 to Many SOCK_SEQPACKET
$pid = server_start(
"-t test_sctp_server_t -l s0:c0.c10",
"sctp_peeloff_server",
- "$v -4 -i 1035"
+ "$v -4 1035"
);
# Verify that authorized client can communicate with the server using SEQ->SEQ->Peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -i seq 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v seq 127.0.0.1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ->peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x -i stream 127.0.0.1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x stream 127.0.0.1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+server_end($pid);
+$pid = server_start(
+ "-t test_sctp_server_t -l s0:c0.c10",
+ "sctp_peeloff_server",
+ "$v -4 1035"
+);
+
# Verify that client cannot communicate with the server using STREAM->SEQ->peeloff with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x -i stream 127.0.0.1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x stream 127.0.0.1 1035 2>&1";
ok( $result >> 8 eq 6 );
# Kill the seq server.
@@ -874,56 +994,56 @@ system "/bin/sh $basedir/cipso-fl-flush";
#
if ($test_calipso) {
- print "# Testing CALIPSO/IPv6 using socket ip_option data\n";
+ print "# Testing CALIPSO/IPv6\n";
system "/bin/sh $basedir/calipso-load";
# Start the stream server.
$pid = server_start(
"-t test_sctp_server_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023",
"sctp_server",
- "$v -i stream 1035"
+ "$v stream 1035"
);
# Verify that authorized client can communicate with the server STREAM->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_client $v -x -i stream ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_client $v -x stream ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server STREAM->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_client $v -i stream ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_client $v stream ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level STREAM->STREAM.
$result = system
-"runcon -t test_sctp_client_t -l s0:c924,c726,c128,c330,c832,c534,c936,c138,c740,c42 $basedir/sctp_client $v -i stream ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c924,c726,c128,c330,c832,c534,c936,c138,c740,c42 $basedir/sctp_client $v stream ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using different valid level SEQ->STREAM
$result = system
-"runcon -t test_sctp_client_t -l s0:c924,c726,c128,c330,c832,c534,c936,c138,c740,c42 $basedir/sctp_client $v -i seq ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c924,c726,c128,c330,c832,c534,c936,c138,c740,c42 $basedir/sctp_client $v seq ::1 1035";
ok( $result eq 0 );
# Verify that authorized client cannot communicate with the server using invalid level STREAM->STREAM.
$result = system
-"runcon -t test_sctp_client_t -l s0:c8.c12 -- $basedir/sctp_client $v -i stream ::1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c8.c12 -- $basedir/sctp_client $v stream ::1 1035 2>&1";
ok( $result >> 8 eq 6 );
if ($test_clpeeloff) {
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_peeloff_client $v -i ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_peeloff_client $v ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_peeloff_client $v -x -i ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_peeloff_client $v -x ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->STREAM with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_peeloff_client $v -n -i ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0,c12,c24,c36,c28,c610,c712,c414,c516,c318,c820,c622,c924,c726,c128,c330,c832,c534,c936,c138,c740,c42,c44,c246,c648,c950,c152,c354,c856,c158,c960,c662,c634,c686,c368,c570,c782,c714,c769,c788,c803,c842,c864,c986,c788,c290,c392,c594,c896,c698,c1023 $basedir/sctp_peeloff_client $v -n ::1 1035";
ok( $result eq 0 );
}
@@ -934,77 +1054,117 @@ if ($test_calipso) {
$pid = server_start(
"-t test_sctp_server_t -l s0:c20.c50",
"sctp_server",
- "$v -i seq 1035"
+ "$v seq 1035"
);
# Verify that authorized client can communicate with the server. SEQ->SEQ
$result = system
-"runcon -t test_sctp_client_t -l s0:c28.c48 $basedir/sctp_client $v -i seq ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c28.c48 $basedir/sctp_client $v seq ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_client $v -i stream ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c28.c48 $basedir/sctp_client $v stream ::1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v seq 1035"
+ );
+
# Verify that authorized client can communicate with the server using SEQ->SEQ with diff valid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c30,c31,c35,c40.c45 $basedir/sctp_client $v -i seq ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c30,c31,c35,c40.c45 $basedir/sctp_client $v seq ::1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v seq 1035"
+ );
+
# Verify that client cannot communicate with the server using SEQ->SEQ with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c51 $basedir/sctp_client $v -i seq ::1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c20.c51 $basedir/sctp_client $v seq ::1 1035 2>&1";
ok( $result >> 8 eq 6 );
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v seq 1035"
+ );
+
# Verify that client cannot communicate with the server using SEQ->SEQ with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c19.c50 -- $basedir/sctp_client $v -i seq ::1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c19.c50 -- $basedir/sctp_client $v seq ::1 1035 2>&1";
ok( $result >> 8 eq 6 );
if ($test_clpeeloff) {
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c20.c50",
+ "sctp_server",
+ "$v seq 1035"
+ );
+
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -i ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with client using sctp_connectx(3).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -x -i ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -x ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server peeloff->SEQ->SEQ with no client connect(2).
$result = system
-"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -n -i ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c20.c50 $basedir/sctp_peeloff_client $v -n ::1 1035";
ok( $result eq 0 );
}
# Kill server.
server_end($pid);
- print "# Testing CALIPSO/IPv6 PEELOFF using socket ip_option data\n";
+ print "# Testing CALIPSO/IPv6 PEELOFF\n";
# Test sctp_peeloff(3) server using 1 to Many SOCK_SEQPACKET
$pid = server_start(
"-t test_sctp_server_t -l s0:c0.c10",
"sctp_peeloff_server",
- "$v -i 1035"
+ "$v 1035"
);
# Verify that authorized client can communicate with the server using SEQ->SEQ->Peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -i seq ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v seq ::1 1035";
ok( $result eq 0 );
# Verify that authorized client can communicate with the server using STREAM->SEQ->peeloff with same level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x -i stream ::1 1035";
+"runcon -t test_sctp_client_t -l s0:c0.c10 $basedir/sctp_client $v -x stream ::1 1035";
ok( $result eq 0 );
+# Restart the seq server to reset the SCTP state and labels
+ server_end($pid);
+ $pid = server_start(
+ "-t test_sctp_server_t -l s0:c0.c10",
+ "sctp_peeloff_server",
+ "$v 1035"
+ );
+
# Verify that client cannot communicate with the server using STREAM->SEQ->peeloff with invalid level.
$result = system
-"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x -i stream ::1 1035 2>&1";
+"runcon -t test_sctp_client_t -l s0:c0.c11 -- $basedir/sctp_client $v -x stream ::1 1035 2>&1";
ok( $result >> 8 eq 6 );
# Kill the seq server.
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-18 22:29 [PATCH] tests/sctp: remove assumptions in the SCTP tests Paul Moore
@ 2022-07-19 11:58 ` Ondrej Mosnacek
2022-07-19 14:28 ` Paul Moore
0 siblings, 1 reply; 11+ messages in thread
From: Ondrej Mosnacek @ 2022-07-19 11:58 UTC (permalink / raw)
To: Paul Moore; +Cc: SElinux list
On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> Rework the SCTP tests slightly to remove two assumptions which are
> not always guaranteed to be true (below). This should have not any
> affect on the current test suite or released kernels, but it will
> help ensure that the test suite continues to work with upcoming
> kernel releases.
>
> * Do not rely on IP options attached to a socket. Depending on the
> kernel configuration, the on-the-wire packet labels may be
> generated on a per-packet basis as opposed to a per-socket basis.
Could you expand a bit on why this would be a problem? It's not clear
to me how switching to per-packet would break the tests. (Maybe I'm
just not thinking about it hard enough, but ideally the commit message
would explain the problem to me so I don't have to :)
>
> * Ensure the kernel's SCTP association state is properly reset by
> restarting the SCTP test server between tests which require it.
>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> ---
> tests/sctp/sctp_client.c | 22 +-
> tests/sctp/sctp_common.c | 42 +++++
> tests/sctp/sctp_common.h | 2
> tests/sctp/sctp_peeloff_client.c | 21 +-
> tests/sctp/sctp_peeloff_server.c | 20 +-
> tests/sctp/sctp_server.c | 28 +--
> tests/sctp/test | 352 ++++++++++++++++++++++++++++----------
> 7 files changed, 332 insertions(+), 155 deletions(-)
[...]
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-19 11:58 ` Ondrej Mosnacek
@ 2022-07-19 14:28 ` Paul Moore
2022-07-20 11:14 ` Ondrej Mosnacek
0 siblings, 1 reply; 11+ messages in thread
From: Paul Moore @ 2022-07-19 14:28 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: SElinux list
On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> > Rework the SCTP tests slightly to remove two assumptions which are
> > not always guaranteed to be true (below). This should have not any
> > affect on the current test suite or released kernels, but it will
> > help ensure that the test suite continues to work with upcoming
> > kernel releases.
> >
> > * Do not rely on IP options attached to a socket. Depending on the
> > kernel configuration, the on-the-wire packet labels may be
> > generated on a per-packet basis as opposed to a per-socket basis.
>
> Could you expand a bit on why this would be a problem? It's not clear
> to me how switching to per-packet would break the tests. (Maybe I'm
> just not thinking about it hard enough, but ideally the commit message
> would explain the problem to me so I don't have to :)
NetLabel can either attach on-the-wire packet labels (IP options)
directly to the packet or to the socket, in the latter case the
network stack handles writing the on-the-wire labels to the packet
when it is generated. Deciding on when to attach IP options
(on-the-wire labels) to the socket versus the packet is an
implementation detail and depends on the specific configuration of the
system and the protocols involved. It is my opinion that going into
the level of detail necessary to explain the differences would involve
a discussion about how the Linux network stacks works, the design of
the NetLabel subsystem, and how the different network protocols work.
The important takeaway is that one can not safely rely on IP options
attached to a socket as a means of determining the labeling behavior
of a socket/connection/association/etc., this is why we have APIs such
as getpeercon() and the LSM specific socket options.
--
paul-moore.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-19 14:28 ` Paul Moore
@ 2022-07-20 11:14 ` Ondrej Mosnacek
2022-07-20 22:17 ` Paul Moore
0 siblings, 1 reply; 11+ messages in thread
From: Ondrej Mosnacek @ 2022-07-20 11:14 UTC (permalink / raw)
To: Paul Moore; +Cc: SElinux list
On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> > > Rework the SCTP tests slightly to remove two assumptions which are
> > > not always guaranteed to be true (below). This should have not any
> > > affect on the current test suite or released kernels, but it will
> > > help ensure that the test suite continues to work with upcoming
> > > kernel releases.
> > >
> > > * Do not rely on IP options attached to a socket. Depending on the
> > > kernel configuration, the on-the-wire packet labels may be
> > > generated on a per-packet basis as opposed to a per-socket basis.
> >
> > Could you expand a bit on why this would be a problem? It's not clear
> > to me how switching to per-packet would break the tests. (Maybe I'm
> > just not thinking about it hard enough, but ideally the commit message
> > would explain the problem to me so I don't have to :)
>
> NetLabel can either attach on-the-wire packet labels (IP options)
> directly to the packet or to the socket, in the latter case the
> network stack handles writing the on-the-wire labels to the packet
> when it is generated. Deciding on when to attach IP options
> (on-the-wire labels) to the socket versus the packet is an
> implementation detail and depends on the specific configuration of the
> system and the protocols involved. It is my opinion that going into
> the level of detail necessary to explain the differences would involve
> a discussion about how the Linux network stacks works, the design of
> the NetLabel subsystem, and how the different network protocols work.
> The important takeaway is that one can not safely rely on IP options
> attached to a socket as a means of determining the labeling behavior
> of a socket/connection/association/etc., this is why we have APIs such
> as getpeercon() and the LSM specific socket options.
Oh wait... I looked closer at what the test is actually doing with the
-i options and I get it now. On the client side it extracts the
per-socket IP option and expects to receive that from the server as
its reported peercon. And on the server side, it also doesn't actually
send the peercon, but rather sends whatever is set on its socket's IP
options... That is indeed wrong and your patch fixes it correctly.
However, I'm pondering whether in the seq server case we shouldn't
change the approach a bit... Currently (after your patch) we are
basically testing the "unified" socket-level peercon and that forces
us to restart the server. But we could also ignore the socket-level
peercon in case of SOCK_SEQPACKET and instead extract the per-packet
peercon via IP_PASSSEC and SCM_SECURITY control messages, like we do
in tests/inet_socket/server.c in the SOCK_DGRAM case. I think this
should be the main way for users to get peercon when using
SOCK_SEQPACKET SCTP sockets with multiple peers and we should test it
with higher priority than the socket-level peercon. This means we
would have to use plain recvmsg() instead of sctp_recvmsg() in
sctp_server.c, but that shouldn't be a problem as we don't need to
extract sctp_sndrcvinfo nor msg_flags there.
If you don't want to mess with it, I can take this patch as-is (maybe
with improved commit message) and propose the above in a separate
patch.
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-20 11:14 ` Ondrej Mosnacek
@ 2022-07-20 22:17 ` Paul Moore
2022-07-21 8:14 ` Ondrej Mosnacek
0 siblings, 1 reply; 11+ messages in thread
From: Paul Moore @ 2022-07-20 22:17 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: SElinux list
On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > Rework the SCTP tests slightly to remove two assumptions which are
> > > > not always guaranteed to be true (below). This should have not any
> > > > affect on the current test suite or released kernels, but it will
> > > > help ensure that the test suite continues to work with upcoming
> > > > kernel releases.
> > > >
> > > > * Do not rely on IP options attached to a socket. Depending on the
> > > > kernel configuration, the on-the-wire packet labels may be
> > > > generated on a per-packet basis as opposed to a per-socket basis.
> > >
> > > Could you expand a bit on why this would be a problem? It's not clear
> > > to me how switching to per-packet would break the tests. (Maybe I'm
> > > just not thinking about it hard enough, but ideally the commit message
> > > would explain the problem to me so I don't have to :)
> >
> > NetLabel can either attach on-the-wire packet labels (IP options)
> > directly to the packet or to the socket, in the latter case the
> > network stack handles writing the on-the-wire labels to the packet
> > when it is generated. Deciding on when to attach IP options
> > (on-the-wire labels) to the socket versus the packet is an
> > implementation detail and depends on the specific configuration of the
> > system and the protocols involved. It is my opinion that going into
> > the level of detail necessary to explain the differences would involve
> > a discussion about how the Linux network stacks works, the design of
> > the NetLabel subsystem, and how the different network protocols work.
> > The important takeaway is that one can not safely rely on IP options
> > attached to a socket as a means of determining the labeling behavior
> > of a socket/connection/association/etc., this is why we have APIs such
> > as getpeercon() and the LSM specific socket options.
>
> Oh wait... I looked closer at what the test is actually doing with the
> -i options and I get it now.
The labeled networking stuff can be a little confusing at times, I'm
glad you were able to wrap your head around it.
> However, I'm pondering whether in the seq server case we shouldn't
> change the approach a bit... Currently (after your patch) we are
> basically testing the "unified" socket-level peercon and that forces
> us to restart the server.
/me nods
> But we could also ignore the socket-level
> peercon in case of SOCK_SEQPACKET and instead extract the per-packet
> peercon via IP_PASSSEC and SCM_SECURITY control messages, like we do
> in tests/inet_socket/server.c in the SOCK_DGRAM case.
Yes, we could do that. I do think there is some value in checking the
peer label when sending SEQPACKETs and the two labels differ, but we
can do both, the tests are not mutually exclusive :)
> I think this
> should be the main way for users to get peercon when using
> SOCK_SEQPACKET SCTP sockets with multiple peers and we should test it
> with higher priority than the socket-level peercon.
I'm not entirely sure what you are suggesting, but just to be clear,
the peer label should always be the label of the remote ("peer"). If
the remote end of the connection is running with s0:c0.c10, it doesn't
matter if the local end initiates communication at s0:c5, the peer
label from the local's perspective should be s0:c0.c10 as that is
label of the remote/server.
It gets a little confusing when you start thinking about how
setsockcreatecon() affects this, and SCTP adds its own twists with the
different associations, but the core idea should remain the same.
--
paul-moore.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-20 22:17 ` Paul Moore
@ 2022-07-21 8:14 ` Ondrej Mosnacek
2022-07-21 13:50 ` Paul Moore
0 siblings, 1 reply; 11+ messages in thread
From: Ondrej Mosnacek @ 2022-07-21 8:14 UTC (permalink / raw)
To: Paul Moore; +Cc: SElinux list
On Thu, Jul 21, 2022 at 12:17 AM Paul Moore <paul@paul-moore.com> wrote:
> On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > > Rework the SCTP tests slightly to remove two assumptions which are
> > > > > not always guaranteed to be true (below). This should have not any
> > > > > affect on the current test suite or released kernels, but it will
> > > > > help ensure that the test suite continues to work with upcoming
> > > > > kernel releases.
> > > > >
> > > > > * Do not rely on IP options attached to a socket. Depending on the
> > > > > kernel configuration, the on-the-wire packet labels may be
> > > > > generated on a per-packet basis as opposed to a per-socket basis.
> > > >
> > > > Could you expand a bit on why this would be a problem? It's not clear
> > > > to me how switching to per-packet would break the tests. (Maybe I'm
> > > > just not thinking about it hard enough, but ideally the commit message
> > > > would explain the problem to me so I don't have to :)
> > >
> > > NetLabel can either attach on-the-wire packet labels (IP options)
> > > directly to the packet or to the socket, in the latter case the
> > > network stack handles writing the on-the-wire labels to the packet
> > > when it is generated. Deciding on when to attach IP options
> > > (on-the-wire labels) to the socket versus the packet is an
> > > implementation detail and depends on the specific configuration of the
> > > system and the protocols involved. It is my opinion that going into
> > > the level of detail necessary to explain the differences would involve
> > > a discussion about how the Linux network stacks works, the design of
> > > the NetLabel subsystem, and how the different network protocols work.
> > > The important takeaway is that one can not safely rely on IP options
> > > attached to a socket as a means of determining the labeling behavior
> > > of a socket/connection/association/etc., this is why we have APIs such
> > > as getpeercon() and the LSM specific socket options.
> >
> > Oh wait... I looked closer at what the test is actually doing with the
> > -i options and I get it now.
>
> The labeled networking stuff can be a little confusing at times, I'm
> glad you were able to wrap your head around it.
>
> > However, I'm pondering whether in the seq server case we shouldn't
> > change the approach a bit... Currently (after your patch) we are
> > basically testing the "unified" socket-level peercon and that forces
> > us to restart the server.
>
> /me nods
>
> > But we could also ignore the socket-level
> > peercon in case of SOCK_SEQPACKET and instead extract the per-packet
> > peercon via IP_PASSSEC and SCM_SECURITY control messages, like we do
> > in tests/inet_socket/server.c in the SOCK_DGRAM case.
>
> Yes, we could do that. I do think there is some value in checking the
> peer label when sending SEQPACKETs and the two labels differ, but we
> can do both, the tests are not mutually exclusive :)
True, but then we need to preserve the server restarting to work
around the "pinning" of the socket-level peercon, which is a bit
awkward... Or we could separate the expected values for the two
peercons and test that the socket-level one is always the one from the
first connection, while the packet-level ones correspond to the actual
peer.
> > I think this
> > should be the main way for users to get peercon when using
> > SOCK_SEQPACKET SCTP sockets with multiple peers and we should test it
> > with higher priority than the socket-level peercon.
>
> I'm not entirely sure what you are suggesting, but just to be clear,
> the peer label should always be the label of the remote ("peer"). If
> the remote end of the connection is running with s0:c0.c10, it doesn't
> matter if the local end initiates communication at s0:c5, the peer
> label from the local's perspective should be s0:c0.c10 as that is
> label of the remote/server.
>
> It gets a little confusing when you start thinking about how
> setsockcreatecon() affects this, and SCTP adds its own twists with the
> different associations, but the core idea should remain the same.
The problem with the socket-level peercon on a SOCK_SEQPACKET socket
is that due to the multi-peer nature of it we resort to setting it
based on the first peer and then just revalidate any new differing
peer contexts through the SCTP_SOCKET__ASSOCIATION permission. To me
it feels like a sort of desperate attempt to provide at least some
peer context, even if it might not be meaningful. It can be convenient
if you know you are going have just one peer context per socket (and
the policy enforces it), but other than that it's better to ignore the
socket peercon and just look at the packet peercons (which are always
accurate) or peel off each new association into a 1-to-1 socket, where
the socket's peer context is accurate.
I'm of the opinion that it would be better to not return any peercon
at all for sockets that might end up receiving from multiple peers,
like we do with SOCK_DGRAM/UDP sockets. (Now it's probably too late to
change it, but that's what I would propose if the SCTP support was
being introduced now.)
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-21 8:14 ` Ondrej Mosnacek
@ 2022-07-21 13:50 ` Paul Moore
2022-07-25 9:51 ` Ondrej Mosnacek
0 siblings, 1 reply; 11+ messages in thread
From: Paul Moore @ 2022-07-21 13:50 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: SElinux list
On Thu, Jul 21, 2022 at 4:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Thu, Jul 21, 2022 at 12:17 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > Rework the SCTP tests slightly to remove two assumptions which are
> > > > > > not always guaranteed to be true (below). This should have not any
> > > > > > affect on the current test suite or released kernels, but it will
> > > > > > help ensure that the test suite continues to work with upcoming
> > > > > > kernel releases.
> > > > > >
> > > > > > * Do not rely on IP options attached to a socket. Depending on the
> > > > > > kernel configuration, the on-the-wire packet labels may be
> > > > > > generated on a per-packet basis as opposed to a per-socket basis.
> > > > >
> > > > > Could you expand a bit on why this would be a problem? It's not clear
> > > > > to me how switching to per-packet would break the tests. (Maybe I'm
> > > > > just not thinking about it hard enough, but ideally the commit message
> > > > > would explain the problem to me so I don't have to :)
> > > >
> > > > NetLabel can either attach on-the-wire packet labels (IP options)
> > > > directly to the packet or to the socket, in the latter case the
> > > > network stack handles writing the on-the-wire labels to the packet
> > > > when it is generated. Deciding on when to attach IP options
> > > > (on-the-wire labels) to the socket versus the packet is an
> > > > implementation detail and depends on the specific configuration of the
> > > > system and the protocols involved. It is my opinion that going into
> > > > the level of detail necessary to explain the differences would involve
> > > > a discussion about how the Linux network stacks works, the design of
> > > > the NetLabel subsystem, and how the different network protocols work.
> > > > The important takeaway is that one can not safely rely on IP options
> > > > attached to a socket as a means of determining the labeling behavior
> > > > of a socket/connection/association/etc., this is why we have APIs such
> > > > as getpeercon() and the LSM specific socket options.
> > >
> > > Oh wait... I looked closer at what the test is actually doing with the
> > > -i options and I get it now.
> >
> > The labeled networking stuff can be a little confusing at times, I'm
> > glad you were able to wrap your head around it.
> >
> > > However, I'm pondering whether in the seq server case we shouldn't
> > > change the approach a bit... Currently (after your patch) we are
> > > basically testing the "unified" socket-level peercon and that forces
> > > us to restart the server.
> >
> > /me nods
> >
> > > But we could also ignore the socket-level
> > > peercon in case of SOCK_SEQPACKET and instead extract the per-packet
> > > peercon via IP_PASSSEC and SCM_SECURITY control messages, like we do
> > > in tests/inet_socket/server.c in the SOCK_DGRAM case.
> >
> > Yes, we could do that. I do think there is some value in checking the
> > peer label when sending SEQPACKETs and the two labels differ, but we
> > can do both, the tests are not mutually exclusive :)
>
> True, but then we need to preserve the server restarting to work
> around the "pinning" of the socket-level peercon, which is a bit
> awkward... Or we could separate the expected values for the two
> peercons and test that the socket-level one is always the one from the
> first connection, while the packet-level ones correspond to the actual
> peer.
I believe the latter is closer to what I was thinking: keep the
existing tests, add additional ones to test what you want. The SCTP
test already haa a bunch of individual tests (over a hundred I
believe), a few more shouldn't be a big problem. If we need to add
functionality to the SCTP test server and client programs we can do
that too.
> > > I think this
> > > should be the main way for users to get peercon when using
> > > SOCK_SEQPACKET SCTP sockets with multiple peers and we should test it
> > > with higher priority than the socket-level peercon.
> >
> > I'm not entirely sure what you are suggesting, but just to be clear,
> > the peer label should always be the label of the remote ("peer"). If
> > the remote end of the connection is running with s0:c0.c10, it doesn't
> > matter if the local end initiates communication at s0:c5, the peer
> > label from the local's perspective should be s0:c0.c10 as that is
> > label of the remote/server.
> >
> > It gets a little confusing when you start thinking about how
> > setsockcreatecon() affects this, and SCTP adds its own twists with the
> > different associations, but the core idea should remain the same.
>
> The problem with the socket-level peercon on a SOCK_SEQPACKET socket
> is that due to the multi-peer nature of it we resort to setting it
> based on the first peer and then just revalidate any new differing
> peer contexts through the SCTP_SOCKET__ASSOCIATION permission.
This is one of the awkward parts of SCTP and mapping its behavior to
the existing socket approach. I believe we discussed some of the
difficulties around locking an association to the first
peer/connection when the patches went in and we couldn't think of a
better way at the time. If you, or anyone else, has a different
approach that you believe would work better, let's discuss it; just
keep in mind we can't affect/relabel existing things, that's a big
no-no :)
> To me
> it feels like a sort of desperate attempt to provide at least some
> peer context, even if it might not be meaningful.
I would argue that it is still meaningful. I would also mention that
the association labeling isn't just the peer label, but the
association's label itself.
> It can be convenient
> if you know you are going have just one peer context per socket (and
> the policy enforces it), but other than that it's better to ignore the
> socket peercon and just look at the packet peercons (which are always
> accurate) or peel off each new association into a 1-to-1 socket, where
> the socket's peer context is accurate.
Unfortunately we can't force a 1-to-1 socket/association as SCTP
supports both 1-to-1 and 1-to-many. I agree it would be nice, but
that decision has already been made for us.
The getpeercon() API returns the label of the remote
peer/node/socket/association based on the initial network traffic.
This should remain unchanged. If an SELinux aware SCTP application
that leverages the sequential/datagram behavior of SCTP instead of the
stream behavior, wants to know the label on an individual datagram it
should use IP_PASSSEC/SCM_SECURITY just as a SELinux aware UDP
application would.
> I'm of the opinion that it would be better to not return any peercon
> at all for sockets that might end up receiving from multiple peers,
> like we do with SOCK_DGRAM/UDP sockets. (Now it's probably too late to
> change it, but that's what I would propose if the SCTP support was
> being introduced now.)
The difference being that with SCTP an association exists whereas
there is no similar state for UDP.
--
paul-moore.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-21 13:50 ` Paul Moore
@ 2022-07-25 9:51 ` Ondrej Mosnacek
2022-07-25 20:40 ` Paul Moore
0 siblings, 1 reply; 11+ messages in thread
From: Ondrej Mosnacek @ 2022-07-25 9:51 UTC (permalink / raw)
To: Paul Moore; +Cc: SElinux list
On Thu, Jul 21, 2022 at 3:51 PM Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Jul 21, 2022 at 4:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > On Thu, Jul 21, 2022 at 12:17 AM Paul Moore <paul@paul-moore.com> wrote:
> > > On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > > Rework the SCTP tests slightly to remove two assumptions which are
> > > > > > > not always guaranteed to be true (below). This should have not any
> > > > > > > affect on the current test suite or released kernels, but it will
> > > > > > > help ensure that the test suite continues to work with upcoming
> > > > > > > kernel releases.
> > > > > > >
> > > > > > > * Do not rely on IP options attached to a socket. Depending on the
> > > > > > > kernel configuration, the on-the-wire packet labels may be
> > > > > > > generated on a per-packet basis as opposed to a per-socket basis.
> > > > > >
> > > > > > Could you expand a bit on why this would be a problem? It's not clear
> > > > > > to me how switching to per-packet would break the tests. (Maybe I'm
> > > > > > just not thinking about it hard enough, but ideally the commit message
> > > > > > would explain the problem to me so I don't have to :)
> > > > >
> > > > > NetLabel can either attach on-the-wire packet labels (IP options)
> > > > > directly to the packet or to the socket, in the latter case the
> > > > > network stack handles writing the on-the-wire labels to the packet
> > > > > when it is generated. Deciding on when to attach IP options
> > > > > (on-the-wire labels) to the socket versus the packet is an
> > > > > implementation detail and depends on the specific configuration of the
> > > > > system and the protocols involved. It is my opinion that going into
> > > > > the level of detail necessary to explain the differences would involve
> > > > > a discussion about how the Linux network stacks works, the design of
> > > > > the NetLabel subsystem, and how the different network protocols work.
> > > > > The important takeaway is that one can not safely rely on IP options
> > > > > attached to a socket as a means of determining the labeling behavior
> > > > > of a socket/connection/association/etc., this is why we have APIs such
> > > > > as getpeercon() and the LSM specific socket options.
> > > >
> > > > Oh wait... I looked closer at what the test is actually doing with the
> > > > -i options and I get it now.
> > >
> > > The labeled networking stuff can be a little confusing at times, I'm
> > > glad you were able to wrap your head around it.
> > >
> > > > However, I'm pondering whether in the seq server case we shouldn't
> > > > change the approach a bit... Currently (after your patch) we are
> > > > basically testing the "unified" socket-level peercon and that forces
> > > > us to restart the server.
> > >
> > > /me nods
> > >
> > > > But we could also ignore the socket-level
> > > > peercon in case of SOCK_SEQPACKET and instead extract the per-packet
> > > > peercon via IP_PASSSEC and SCM_SECURITY control messages, like we do
> > > > in tests/inet_socket/server.c in the SOCK_DGRAM case.
> > >
> > > Yes, we could do that. I do think there is some value in checking the
> > > peer label when sending SEQPACKETs and the two labels differ, but we
> > > can do both, the tests are not mutually exclusive :)
> >
> > True, but then we need to preserve the server restarting to work
> > around the "pinning" of the socket-level peercon, which is a bit
> > awkward... Or we could separate the expected values for the two
> > peercons and test that the socket-level one is always the one from the
> > first connection, while the packet-level ones correspond to the actual
> > peer.
>
> I believe the latter is closer to what I was thinking: keep the
> existing tests, add additional ones to test what you want. The SCTP
> test already haa a bunch of individual tests (over a hundred I
> believe), a few more shouldn't be a big problem. If we need to add
> functionality to the SCTP test server and client programs we can do
> that too.
Ok, I'm going to merge this patch with some minor edits (see [1]) if
you're okay with them and then I'll look into further improvements.
[1] https://github.com/WOnder93/selinux-testsuite/commit/0f7bb1696a15972a555d997377348b8e4ae56b38
> > > > I think this
> > > > should be the main way for users to get peercon when using
> > > > SOCK_SEQPACKET SCTP sockets with multiple peers and we should test it
> > > > with higher priority than the socket-level peercon.
> > >
> > > I'm not entirely sure what you are suggesting, but just to be clear,
> > > the peer label should always be the label of the remote ("peer"). If
> > > the remote end of the connection is running with s0:c0.c10, it doesn't
> > > matter if the local end initiates communication at s0:c5, the peer
> > > label from the local's perspective should be s0:c0.c10 as that is
> > > label of the remote/server.
> > >
> > > It gets a little confusing when you start thinking about how
> > > setsockcreatecon() affects this, and SCTP adds its own twists with the
> > > different associations, but the core idea should remain the same.
> >
> > The problem with the socket-level peercon on a SOCK_SEQPACKET socket
> > is that due to the multi-peer nature of it we resort to setting it
> > based on the first peer and then just revalidate any new differing
> > peer contexts through the SCTP_SOCKET__ASSOCIATION permission.
>
> This is one of the awkward parts of SCTP and mapping its behavior to
> the existing socket approach. I believe we discussed some of the
> difficulties around locking an association to the first
> peer/connection when the patches went in and we couldn't think of a
> better way at the time. If you, or anyone else, has a different
> approach that you believe would work better, let's discuss it; just
> keep in mind we can't affect/relabel existing things, that's a big
> no-no :)
I don't think it makes sense to change it at this point, since the
user can always simply choose to ignore the socket peercon when using
the SOCK_SEQPACKET SCTP socket. My point really was that we obviously
can't test everything and if we have to choose between testing a less
meaningful interface and testing a more meaningful interface, we
should choose the latter. But it seems that in this case it won't be
too hard/costly to test both, so that point is no longer relevant.
>
> > To me
> > it feels like a sort of desperate attempt to provide at least some
> > peer context, even if it might not be meaningful.
>
> I would argue that it is still meaningful. I would also mention that
> the association labeling isn't just the peer label, but the
> association's label itself.
I disagree, but it doesn't matter as we can't remove it at this point anyway.
> > It can be convenient
> > if you know you are going have just one peer context per socket (and
> > the policy enforces it), but other than that it's better to ignore the
> > socket peercon and just look at the packet peercons (which are always
> > accurate) or peel off each new association into a 1-to-1 socket, where
> > the socket's peer context is accurate.
>
> Unfortunately we can't force a 1-to-1 socket/association as SCTP
> supports both 1-to-1 and 1-to-many. I agree it would be nice, but
> that decision has already been made for us.
No, we can't force that, but we could have refused to provide a
socket-level peer context on (potentially) 1-to-many sockets. I'm also
saying that we (the kernel) made it hard to enforce via policy that
the peer label returned corresponds to the actual peer. On the type
level it's easy as you can just not define any
SCTP_SOCKET__ASSOCIATION rules, but on MLS level you would have to
(AFAICT) add some non-trivial constraints to prevent peers with
non-matching levels to connect to the same socket (and thus basically
pretend to have different level if the userspace relies on the
socket's peer context).
> The getpeercon() API returns the label of the remote
> peer/node/socket/association based on the initial network traffic.
> This should remain unchanged. If an SELinux aware SCTP application
> that leverages the sequential/datagram behavior of SCTP instead of the
> stream behavior, wants to know the label on an individual datagram it
> should use IP_PASSSEC/SCM_SECURITY just as a SELinux aware UDP
> application would.
>
> > I'm of the opinion that it would be better to not return any peercon
> > at all for sockets that might end up receiving from multiple peers,
> > like we do with SOCK_DGRAM/UDP sockets. (Now it's probably too late to
> > change it, but that's what I would propose if the SCTP support was
> > being introduced now.)
>
> The difference being that with SCTP an association exists whereas
> there is no similar state for UDP.
That's irrelevant as the association doesn't correspond 1-to-1 to the
socket. If we really really wanted to provide a way to get the
association's peer context without peeling it off, we should do it via
some SCTP-specific getsockopt that would take assoc ID as an argument
(same as SCTP provides access to assoc-level info/properties). But
IMHO it wouldn't be worth the effort as peeling off the assoc or using
IP_PASSSEC should be a viable alternative in most if not all cases. I
still stand behind my opinion that providing no
socket-or-association-level peercon interface for SOCK_SEQPACKET would
have been better than providing a bad one. (But anyway, this
discussion is merely academic as it can't be undone now due to
backwards compatibility.)
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-25 9:51 ` Ondrej Mosnacek
@ 2022-07-25 20:40 ` Paul Moore
2022-07-26 8:54 ` Ondrej Mosnacek
0 siblings, 1 reply; 11+ messages in thread
From: Paul Moore @ 2022-07-25 20:40 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: SElinux list
On Mon, Jul 25, 2022 at 5:52 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Thu, Jul 21, 2022 at 3:51 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Jul 21, 2022 at 4:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > On Thu, Jul 21, 2022 at 12:17 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
...
> Ok, I'm going to merge this patch with some minor edits (see [1]) if
> you're okay with them and then I'll look into further improvements.
>
> [1] https://github.com/WOnder93/selinux-testsuite/commit/0f7bb1696a15972a555d997377348b8e4ae56b38
Whatever you need to do so you'll merge it is fine with me. My goal
is a functional test suite, I don't care that much how we arrive at
that point :)
> > The difference being that with SCTP an association exists whereas
> > there is no similar state for UDP.
>
> That's irrelevant ...
It's not, but since we both agree the behavior isn't changing, let's
"agree to disagree" and move on.
--
paul-moore.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-25 20:40 ` Paul Moore
@ 2022-07-26 8:54 ` Ondrej Mosnacek
2022-07-26 19:16 ` Paul Moore
0 siblings, 1 reply; 11+ messages in thread
From: Ondrej Mosnacek @ 2022-07-26 8:54 UTC (permalink / raw)
To: Paul Moore; +Cc: SElinux list
On Mon, Jul 25, 2022 at 10:40 PM Paul Moore <paul@paul-moore.com> wrote:
> On Mon, Jul 25, 2022 at 5:52 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > On Thu, Jul 21, 2022 at 3:51 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Thu, Jul 21, 2022 at 4:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > On Thu, Jul 21, 2022 at 12:17 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > > On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > > On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > > > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
>
> ...
>
> > Ok, I'm going to merge this patch with some minor edits (see [1]) if
> > you're okay with them and then I'll look into further improvements.
> >
> > [1] https://github.com/WOnder93/selinux-testsuite/commit/0f7bb1696a15972a555d997377348b8e4ae56b38
>
> Whatever you need to do so you'll merge it is fine with me. My goal
> is a functional test suite, I don't care that much how we arrive at
> that point :)
Thanks, I applied that patch:
https://github.com/SELinuxProject/selinux-testsuite/commit/db1c3fbf5a718797365576d0b449dc7658da056c
> > > The difference being that with SCTP an association exists whereas
> > > there is no similar state for UDP.
> >
> > That's irrelevant ...
>
> It's not, but since we both agree the behavior isn't changing, let's
> "agree to disagree" and move on.
Agreed :)
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tests/sctp: remove assumptions in the SCTP tests
2022-07-26 8:54 ` Ondrej Mosnacek
@ 2022-07-26 19:16 ` Paul Moore
0 siblings, 0 replies; 11+ messages in thread
From: Paul Moore @ 2022-07-26 19:16 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: SElinux list
On Tue, Jul 26, 2022 at 4:54 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Mon, Jul 25, 2022 at 10:40 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Mon, Jul 25, 2022 at 5:52 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > On Thu, Jul 21, 2022 at 3:51 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Thu, Jul 21, 2022 at 4:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > On Thu, Jul 21, 2022 at 12:17 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > On Wed, Jul 20, 2022 at 7:14 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > > > On Tue, Jul 19, 2022 at 4:28 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > > > On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > > > > > > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@paul-moore.com> wrote:
> >
> > ...
> >
> > > Ok, I'm going to merge this patch with some minor edits (see [1]) if
> > > you're okay with them and then I'll look into further improvements.
> > >
> > > [1] https://github.com/WOnder93/selinux-testsuite/commit/0f7bb1696a15972a555d997377348b8e4ae56b38
> >
> > Whatever you need to do so you'll merge it is fine with me. My goal
> > is a functional test suite, I don't care that much how we arrive at
> > that point :)
>
> Thanks, I applied that patch:
> https://github.com/SELinuxProject/selinux-testsuite/commit/db1c3fbf5a718797365576d0b449dc7658da056c
Great, thank you.
--
paul-moore.com
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-07-26 19:17 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-18 22:29 [PATCH] tests/sctp: remove assumptions in the SCTP tests Paul Moore
2022-07-19 11:58 ` Ondrej Mosnacek
2022-07-19 14:28 ` Paul Moore
2022-07-20 11:14 ` Ondrej Mosnacek
2022-07-20 22:17 ` Paul Moore
2022-07-21 8:14 ` Ondrej Mosnacek
2022-07-21 13:50 ` Paul Moore
2022-07-25 9:51 ` Ondrej Mosnacek
2022-07-25 20:40 ` Paul Moore
2022-07-26 8:54 ` Ondrej Mosnacek
2022-07-26 19:16 ` Paul Moore
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.