* [RFC PATCH] audit-testsuite: tests for subject and object correctness
[not found] <e4bf30e2-a92f-99b7-30d0-3e3473e30399.ref@schaufler-ca.com>
@ 2020-11-02 21:54 ` Casey Schaufler
2020-11-02 22:08 ` Richard Guy Briggs
0 siblings, 1 reply; 9+ messages in thread
From: Casey Schaufler @ 2020-11-02 21:54 UTC (permalink / raw)
To: linux-audit@redhat.com, Paul Moore, Richard Guy Briggs
Verify that there are subj= and obj= fields in a record
if and only if they are expected. A system without a security
module that provides these fields should not include them.
A system with multiple security modules providing these fields
(e.g. SELinux and AppArmor) should always provide "?" for the
data and also include a AUDIT_MAC_TASK_CONTEXTS or
AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
/sys/kernel/security/lsm to determine which format is expected.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
tests/Makefile | 1 +
tests/multiple_contexts/Makefile | 12 +++
tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+)
create mode 100644 tests/multiple_contexts/Makefile
create mode 100755 tests/multiple_contexts/test
diff --git a/tests/Makefile b/tests/Makefile
index a7f242a..f20f6b1 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -18,6 +18,7 @@ TESTS := \
file_create \
file_delete \
file_rename \
+ multiple_contexts \
filter_exclude \
filter_saddr_fam \
filter_sessionid \
diff --git a/tests/multiple_contexts/Makefile b/tests/multiple_contexts/Makefile
new file mode 100644
index 0000000..c2a8e87
--- /dev/null
+++ b/tests/multiple_contexts/Makefile
@@ -0,0 +1,12 @@
+#
+# Copyright (C) Intel Corporation, 2020
+#
+
+TARGETS=$(patsubst %.c,%,$(wildcard *.c))
+
+LDLIBS += -lpthread
+
+all: $(TARGETS)
+clean:
+ rm -f $(TARGETS)
+
diff --git a/tests/multiple_contexts/test b/tests/multiple_contexts/test
new file mode 100755
index 0000000..c9afed5
--- /dev/null
+++ b/tests/multiple_contexts/test
@@ -0,0 +1,166 @@
+#!/usr/bin/perl
+#
+# Copyright (C) Intel Corporation, 2020
+#
+
+use strict;
+
+use Test;
+BEGIN { plan tests => 3 }
+
+use File::Temp qw/ tempdir tempfile /;
+
+###
+# functions
+
+sub key_gen {
+ my @chars = ( "A" .. "Z", "a" .. "z" );
+ my $key = "testsuite-" . time . "-";
+ $key .= $chars[ rand @chars ] for 1 .. 8;
+ return $key;
+}
+
+###
+# setup
+
+# reset audit
+system("auditctl -D >& /dev/null");
+
+my $line;
+my $lsm_out;
+my $lsm_count = 0;
+my $bpf_enabled = 0;
+
+open($lsm_out, "cat /sys/kernel/security/lsm |");
+while ( $line = <$lsm_out> ) {
+ if ( $line =~ /selinux/ ) {
+ $lsm_count = $lsm_count + 1;
+ }
+ if ( $line =~ /smack/ ) {
+ $lsm_count = $lsm_count + 1;
+ }
+ if ( $line =~ /apparmor/ ) {
+ $lsm_count = $lsm_count + 1;
+ }
+ if ( $line =~ /bpf/ ) {
+ $bpf_enabled = 1;
+ }
+}
+close($lsm_out);
+
+if ( $lsm_count and $bpf_enabled ) {
+ $lsm_count = $lsm_count + 1;
+}
+# create temp directory
+my $dir = tempdir( TEMPLATE => '/tmp/audit-testsuite-XXXX', CLEANUP => 1 );
+
+# create stdout/stderr sinks
+( my $fh_out, my $stdout ) = tempfile(
+ TEMPLATE => '/tmp/audit-testsuite-out-XXXX',
+ UNLINK => 1
+);
+( my $fh_err, my $stderr ) = tempfile(
+ TEMPLATE => '/tmp/audit-testsuite-err-XXXX',
+ UNLINK => 1
+);
+
+###
+# tests
+
+# create a test file
+( my $fh, my $filename ) =
+ tempfile( TEMPLATE => $dir . "/file-XXXX", UNLINK => 1 );
+
+# set the directory watch
+my $key = key_gen();
+system("auditctl -w $dir -k $key");
+
+# delete file
+unlink($filename);
+
+# make sure the records had a chance to bubble through to the logs
+system("auditctl -m syncmarker-$key");
+for ( my $i = 0 ; $i < 10 ; $i++ ) {
+ if ( system("ausearch -m USER | grep -q syncmarker-$key") eq 0 ) {
+ last;
+ }
+ sleep(0.2);
+}
+
+# test if we generate any audit records from the watch
+my $result = system("ausearch -i -k $key > $stdout 2> $stderr");
+ok( $result, 0 );
+
+# test if we generate a MAC_TASK_CONTEXTS record if and
+# only if it is required.
+#
+# test if we generate a MAC_OBJ_CONTEXTS record if and
+# only if it is required.
+
+my $found_auxsubj = 0;
+my $found_subjattr = 0;
+my $found_regsubj = 0;
+
+my $found_auxobj = 0;
+my $found_objattr = 0;
+my $found_regobj = 0;
+
+while ( $line = <$fh_out> ) {
+
+ if ( $line =~ / subj=\? / ) {
+ $found_auxsubj = 1;
+ } elsif ( $line =~ / subj=/ ) {
+ $found_regsubj = 1;
+ }
+ if ( $line =~ / subj_selinux=/ ) {
+ $found_subjattr = 1;
+ }
+ if ( $line =~ / subj_apparmor=/ ) {
+ $found_subjattr = 1;
+ }
+ if ( $line =~ / subj_smack=/ ) {
+ $found_subjattr = 1;
+ }
+
+ if ( $line =~ / obj=\? / ) {
+ $found_auxobj = 1;
+ } elsif ( $line =~ / obj=/ ) {
+ $found_regobj = 1;
+ }
+ if ( $line =~ / obj_selinux=/ ) {
+ $found_objattr = 1;
+ }
+ if ( $line =~ / obj_apparmor=/ ) {
+ $found_objattr = 1;
+ }
+ if ( $line =~ / obj_smack=/ ) {
+ $found_objattr = 1;
+ }
+}
+
+# three cases:
+# no subj= field or MAC_TASK_CONTEXTS when no supplying LSM
+# subj=$value field, no MAC_TASK_CONTEXTS for exactly one supplying LSM
+# subj=? field and a MAC_TASK_CONTEXTS for more than one supplying LSM
+#
+if ($lsm_count == 0) {
+ ok($found_regsubj == 0 and $found_auxsubj == 0);
+} elsif ($lsm_count == 1) {
+ ok($found_regsubj and $found_auxsubj == 0);
+} else {
+ ok($found_subjattr and $found_auxsubj);
+}
+
+if ($lsm_count == 0) {
+ ok($found_regobj == 0 and $found_auxobj == 0);
+} elsif ($lsm_count == 1) {
+ ok($found_regobj and $found_auxobj == 0);
+} else {
+ ok($found_objattr and $found_auxobj);
+}
+
+###
+# cleanup
+
+system("auditctl -D >& /dev/null");
+
--
2.24.1
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-02 21:54 ` [RFC PATCH] audit-testsuite: tests for subject and object correctness Casey Schaufler
@ 2020-11-02 22:08 ` Richard Guy Briggs
2020-11-02 22:51 ` Casey Schaufler
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guy Briggs @ 2020-11-02 22:08 UTC (permalink / raw)
To: Casey Schaufler; +Cc: linux-audit@redhat.com
On 2020-11-02 13:54, Casey Schaufler wrote:
> Verify that there are subj= and obj= fields in a record
> if and only if they are expected. A system without a security
> module that provides these fields should not include them.
> A system with multiple security modules providing these fields
> (e.g. SELinux and AppArmor) should always provide "?" for the
> data and also include a AUDIT_MAC_TASK_CONTEXTS or
> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
> /sys/kernel/security/lsm to determine which format is expected.
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> tests/Makefile | 1 +
> tests/multiple_contexts/Makefile | 12 +++
> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
> 3 files changed, 179 insertions(+)
> create mode 100644 tests/multiple_contexts/Makefile
> create mode 100755 tests/multiple_contexts/test
>
> diff --git a/tests/Makefile b/tests/Makefile
> index a7f242a..f20f6b1 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -18,6 +18,7 @@ TESTS := \
> file_create \
> file_delete \
> file_rename \
> + multiple_contexts \
"context" is a bit ambiguous. Could this be named something to indicate
a security context rather than any other sort, such as audit or user
context?
> filter_exclude \
> filter_saddr_fam \
> filter_sessionid \
> diff --git a/tests/multiple_contexts/Makefile b/tests/multiple_contexts/Makefile
> new file mode 100644
> index 0000000..c2a8e87
> --- /dev/null
> +++ b/tests/multiple_contexts/Makefile
> @@ -0,0 +1,12 @@
> +#
> +# Copyright (C) Intel Corporation, 2020
> +#
> +
> +TARGETS=$(patsubst %.c,%,$(wildcard *.c))
> +
> +LDLIBS += -lpthread
> +
> +all: $(TARGETS)
> +clean:
> + rm -f $(TARGETS)
> +
> diff --git a/tests/multiple_contexts/test b/tests/multiple_contexts/test
> new file mode 100755
> index 0000000..c9afed5
> --- /dev/null
> +++ b/tests/multiple_contexts/test
> @@ -0,0 +1,166 @@
> +#!/usr/bin/perl
> +#
> +# Copyright (C) Intel Corporation, 2020
> +#
> +
> +use strict;
> +
> +use Test;
> +BEGIN { plan tests => 3 }
> +
> +use File::Temp qw/ tempdir tempfile /;
> +
> +###
> +# functions
> +
> +sub key_gen {
> + my @chars = ( "A" .. "Z", "a" .. "z" );
> + my $key = "testsuite-" . time . "-";
> + $key .= $chars[ rand @chars ] for 1 .. 8;
> + return $key;
> +}
> +
> +###
> +# setup
> +
> +# reset audit
> +system("auditctl -D >& /dev/null");
> +
> +my $line;
> +my $lsm_out;
> +my $lsm_count = 0;
> +my $bpf_enabled = 0;
> +
> +open($lsm_out, "cat /sys/kernel/security/lsm |");
> +while ( $line = <$lsm_out> ) {
> + if ( $line =~ /selinux/ ) {
> + $lsm_count = $lsm_count + 1;
> + }
> + if ( $line =~ /smack/ ) {
> + $lsm_count = $lsm_count + 1;
> + }
> + if ( $line =~ /apparmor/ ) {
> + $lsm_count = $lsm_count + 1;
> + }
> + if ( $line =~ /bpf/ ) {
> + $bpf_enabled = 1;
> + }
> +}
> +close($lsm_out);
> +
> +if ( $lsm_count and $bpf_enabled ) {
> + $lsm_count = $lsm_count + 1;
> +}
> +# create temp directory
> +my $dir = tempdir( TEMPLATE => '/tmp/audit-testsuite-XXXX', CLEANUP => 1 );
> +
> +# create stdout/stderr sinks
> +( my $fh_out, my $stdout ) = tempfile(
> + TEMPLATE => '/tmp/audit-testsuite-out-XXXX',
> + UNLINK => 1
> +);
> +( my $fh_err, my $stderr ) = tempfile(
> + TEMPLATE => '/tmp/audit-testsuite-err-XXXX',
> + UNLINK => 1
> +);
> +
> +###
> +# tests
> +
> +# create a test file
> +( my $fh, my $filename ) =
> + tempfile( TEMPLATE => $dir . "/file-XXXX", UNLINK => 1 );
> +
> +# set the directory watch
> +my $key = key_gen();
> +system("auditctl -w $dir -k $key");
> +
> +# delete file
> +unlink($filename);
> +
> +# make sure the records had a chance to bubble through to the logs
> +system("auditctl -m syncmarker-$key");
> +for ( my $i = 0 ; $i < 10 ; $i++ ) {
> + if ( system("ausearch -m USER | grep -q syncmarker-$key") eq 0 ) {
> + last;
> + }
> + sleep(0.2);
> +}
> +
> +# test if we generate any audit records from the watch
> +my $result = system("ausearch -i -k $key > $stdout 2> $stderr");
> +ok( $result, 0 );
> +
> +# test if we generate a MAC_TASK_CONTEXTS record if and
> +# only if it is required.
> +#
> +# test if we generate a MAC_OBJ_CONTEXTS record if and
> +# only if it is required.
> +
> +my $found_auxsubj = 0;
> +my $found_subjattr = 0;
> +my $found_regsubj = 0;
> +
> +my $found_auxobj = 0;
> +my $found_objattr = 0;
> +my $found_regobj = 0;
> +
> +while ( $line = <$fh_out> ) {
> +
> + if ( $line =~ / subj=\? / ) {
> + $found_auxsubj = 1;
> + } elsif ( $line =~ / subj=/ ) {
> + $found_regsubj = 1;
> + }
> + if ( $line =~ / subj_selinux=/ ) {
> + $found_subjattr = 1;
> + }
> + if ( $line =~ / subj_apparmor=/ ) {
> + $found_subjattr = 1;
> + }
> + if ( $line =~ / subj_smack=/ ) {
> + $found_subjattr = 1;
> + }
> +
> + if ( $line =~ / obj=\? / ) {
> + $found_auxobj = 1;
> + } elsif ( $line =~ / obj=/ ) {
> + $found_regobj = 1;
> + }
> + if ( $line =~ / obj_selinux=/ ) {
> + $found_objattr = 1;
> + }
> + if ( $line =~ / obj_apparmor=/ ) {
> + $found_objattr = 1;
> + }
> + if ( $line =~ / obj_smack=/ ) {
> + $found_objattr = 1;
> + }
> +}
> +
> +# three cases:
> +# no subj= field or MAC_TASK_CONTEXTS when no supplying LSM
> +# subj=$value field, no MAC_TASK_CONTEXTS for exactly one supplying LSM
> +# subj=? field and a MAC_TASK_CONTEXTS for more than one supplying LSM
> +#
> +if ($lsm_count == 0) {
> + ok($found_regsubj == 0 and $found_auxsubj == 0);
> +} elsif ($lsm_count == 1) {
> + ok($found_regsubj and $found_auxsubj == 0);
> +} else {
> + ok($found_subjattr and $found_auxsubj);
> +}
> +
> +if ($lsm_count == 0) {
> + ok($found_regobj == 0 and $found_auxobj == 0);
> +} elsif ($lsm_count == 1) {
> + ok($found_regobj and $found_auxobj == 0);
> +} else {
> + ok($found_objattr and $found_auxobj);
> +}
> +
> +###
> +# cleanup
> +
> +system("auditctl -D >& /dev/null");
> +
> --
> 2.24.1
>
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-02 22:08 ` Richard Guy Briggs
@ 2020-11-02 22:51 ` Casey Schaufler
2020-11-03 1:19 ` Richard Guy Briggs
0 siblings, 1 reply; 9+ messages in thread
From: Casey Schaufler @ 2020-11-02 22:51 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit@redhat.com
On 11/2/2020 2:08 PM, Richard Guy Briggs wrote:
> On 2020-11-02 13:54, Casey Schaufler wrote:
>> Verify that there are subj= and obj= fields in a record
>> if and only if they are expected. A system without a security
>> module that provides these fields should not include them.
>> A system with multiple security modules providing these fields
>> (e.g. SELinux and AppArmor) should always provide "?" for the
>> data and also include a AUDIT_MAC_TASK_CONTEXTS or
>> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
>> /sys/kernel/security/lsm to determine which format is expected.
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>> ---
>> tests/Makefile | 1 +
>> tests/multiple_contexts/Makefile | 12 +++
>> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
>> 3 files changed, 179 insertions(+)
>> create mode 100644 tests/multiple_contexts/Makefile
>> create mode 100755 tests/multiple_contexts/test
>>
>> diff --git a/tests/Makefile b/tests/Makefile
>> index a7f242a..f20f6b1 100644
>> --- a/tests/Makefile
>> +++ b/tests/Makefile
>> @@ -18,6 +18,7 @@ TESTS := \
>> file_create \
>> file_delete \
>> file_rename \
>> + multiple_contexts \
> "context" is a bit ambiguous. Could this be named something to indicate
> a security context rather than any other sort, such as audit or user
> context?
Would "subj_obj_fields" be better?
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-02 22:51 ` Casey Schaufler
@ 2020-11-03 1:19 ` Richard Guy Briggs
2020-11-03 3:31 ` Paul Moore
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guy Briggs @ 2020-11-03 1:19 UTC (permalink / raw)
To: Casey Schaufler; +Cc: linux-audit@redhat.com
On 2020-11-02 14:51, Casey Schaufler wrote:
> On 11/2/2020 2:08 PM, Richard Guy Briggs wrote:
> > On 2020-11-02 13:54, Casey Schaufler wrote:
> >> Verify that there are subj= and obj= fields in a record
> >> if and only if they are expected. A system without a security
> >> module that provides these fields should not include them.
> >> A system with multiple security modules providing these fields
> >> (e.g. SELinux and AppArmor) should always provide "?" for the
> >> data and also include a AUDIT_MAC_TASK_CONTEXTS or
> >> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
> >> /sys/kernel/security/lsm to determine which format is expected.
> >>
> >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> >> ---
> >> tests/Makefile | 1 +
> >> tests/multiple_contexts/Makefile | 12 +++
> >> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
> >> 3 files changed, 179 insertions(+)
> >> create mode 100644 tests/multiple_contexts/Makefile
> >> create mode 100755 tests/multiple_contexts/test
> >>
> >> diff --git a/tests/Makefile b/tests/Makefile
> >> index a7f242a..f20f6b1 100644
> >> --- a/tests/Makefile
> >> +++ b/tests/Makefile
> >> @@ -18,6 +18,7 @@ TESTS := \
> >> file_create \
> >> file_delete \
> >> file_rename \
> >> + multiple_contexts \
> > "context" is a bit ambiguous. Could this be named something to indicate
> > a security context rather than any other sort, such as audit or user
> > context?
>
> Would "subj_obj_fields" be better?
That is much more obvious to me. Maybe even sec_context_multi, but I
like your suggestion better?
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-03 1:19 ` Richard Guy Briggs
@ 2020-11-03 3:31 ` Paul Moore
2020-11-03 12:00 ` Richard Guy Briggs
2020-11-07 0:51 ` Casey Schaufler
0 siblings, 2 replies; 9+ messages in thread
From: Paul Moore @ 2020-11-03 3:31 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit@redhat.com
On Mon, Nov 2, 2020 at 8:19 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2020-11-02 14:51, Casey Schaufler wrote:
> > On 11/2/2020 2:08 PM, Richard Guy Briggs wrote:
> > > On 2020-11-02 13:54, Casey Schaufler wrote:
> > >> Verify that there are subj= and obj= fields in a record
> > >> if and only if they are expected. A system without a security
> > >> module that provides these fields should not include them.
> > >> A system with multiple security modules providing these fields
> > >> (e.g. SELinux and AppArmor) should always provide "?" for the
> > >> data and also include a AUDIT_MAC_TASK_CONTEXTS or
> > >> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
> > >> /sys/kernel/security/lsm to determine which format is expected.
> > >>
> > >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> > >> ---
> > >> tests/Makefile | 1 +
> > >> tests/multiple_contexts/Makefile | 12 +++
> > >> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
> > >> 3 files changed, 179 insertions(+)
> > >> create mode 100644 tests/multiple_contexts/Makefile
> > >> create mode 100755 tests/multiple_contexts/test
> > >>
> > >> diff --git a/tests/Makefile b/tests/Makefile
> > >> index a7f242a..f20f6b1 100644
> > >> --- a/tests/Makefile
> > >> +++ b/tests/Makefile
> > >> @@ -18,6 +18,7 @@ TESTS := \
> > >> file_create \
> > >> file_delete \
> > >> file_rename \
> > >> + multiple_contexts \
> > > "context" is a bit ambiguous. Could this be named something to indicate
> > > a security context rather than any other sort, such as audit or user
> > > context?
> >
> > Would "subj_obj_fields" be better?
>
> That is much more obvious to me. Maybe even sec_context_multi, but I
> like your suggestion better?
How about just "multiple_lsms"? It's relatively concise and better
reflects what it is actually being tested IMHO.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-03 3:31 ` Paul Moore
@ 2020-11-03 12:00 ` Richard Guy Briggs
2020-11-07 0:51 ` Casey Schaufler
1 sibling, 0 replies; 9+ messages in thread
From: Richard Guy Briggs @ 2020-11-03 12:00 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit@redhat.com
On 2020-11-02 22:31, Paul Moore wrote:
> On Mon, Nov 2, 2020 at 8:19 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2020-11-02 14:51, Casey Schaufler wrote:
> > > On 11/2/2020 2:08 PM, Richard Guy Briggs wrote:
> > > > On 2020-11-02 13:54, Casey Schaufler wrote:
> > > >> Verify that there are subj= and obj= fields in a record
> > > >> if and only if they are expected. A system without a security
> > > >> module that provides these fields should not include them.
> > > >> A system with multiple security modules providing these fields
> > > >> (e.g. SELinux and AppArmor) should always provide "?" for the
> > > >> data and also include a AUDIT_MAC_TASK_CONTEXTS or
> > > >> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
> > > >> /sys/kernel/security/lsm to determine which format is expected.
> > > >>
> > > >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> > > >> ---
> > > >> tests/Makefile | 1 +
> > > >> tests/multiple_contexts/Makefile | 12 +++
> > > >> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
> > > >> 3 files changed, 179 insertions(+)
> > > >> create mode 100644 tests/multiple_contexts/Makefile
> > > >> create mode 100755 tests/multiple_contexts/test
> > > >>
> > > >> diff --git a/tests/Makefile b/tests/Makefile
> > > >> index a7f242a..f20f6b1 100644
> > > >> --- a/tests/Makefile
> > > >> +++ b/tests/Makefile
> > > >> @@ -18,6 +18,7 @@ TESTS := \
> > > >> file_create \
> > > >> file_delete \
> > > >> file_rename \
> > > >> + multiple_contexts \
> > > > "context" is a bit ambiguous. Could this be named something to indicate
> > > > a security context rather than any other sort, such as audit or user
> > > > context?
> > >
> > > Would "subj_obj_fields" be better?
> >
> > That is much more obvious to me. Maybe even sec_context_multi, but I
> > like your suggestion better?
>
> How about just "multiple_lsms"? It's relatively concise and better
> reflects what it is actually being tested IMHO.
Yes, that's better. Works for me.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-03 3:31 ` Paul Moore
2020-11-03 12:00 ` Richard Guy Briggs
@ 2020-11-07 0:51 ` Casey Schaufler
2020-11-08 13:38 ` Paul Moore
2020-11-09 13:07 ` Richard Guy Briggs
1 sibling, 2 replies; 9+ messages in thread
From: Casey Schaufler @ 2020-11-07 0:51 UTC (permalink / raw)
To: Paul Moore, Richard Guy Briggs; +Cc: linux-audit@redhat.com
On 11/2/2020 7:31 PM, Paul Moore wrote:
> On Mon, Nov 2, 2020 at 8:19 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>> On 2020-11-02 14:51, Casey Schaufler wrote:
>>> On 11/2/2020 2:08 PM, Richard Guy Briggs wrote:
>>>> On 2020-11-02 13:54, Casey Schaufler wrote:
>>>>> Verify that there are subj= and obj= fields in a record
>>>>> if and only if they are expected. A system without a security
>>>>> module that provides these fields should not include them.
>>>>> A system with multiple security modules providing these fields
>>>>> (e.g. SELinux and AppArmor) should always provide "?" for the
>>>>> data and also include a AUDIT_MAC_TASK_CONTEXTS or
>>>>> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
>>>>> /sys/kernel/security/lsm to determine which format is expected.
>>>>>
>>>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>>>>> ---
>>>>> tests/Makefile | 1 +
>>>>> tests/multiple_contexts/Makefile | 12 +++
>>>>> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
>>>>> 3 files changed, 179 insertions(+)
>>>>> create mode 100644 tests/multiple_contexts/Makefile
>>>>> create mode 100755 tests/multiple_contexts/test
>>>>>
>>>>> diff --git a/tests/Makefile b/tests/Makefile
>>>>> index a7f242a..f20f6b1 100644
>>>>> --- a/tests/Makefile
>>>>> +++ b/tests/Makefile
>>>>> @@ -18,6 +18,7 @@ TESTS := \
>>>>> file_create \
>>>>> file_delete \
>>>>> file_rename \
>>>>> + multiple_contexts \
>>>> "context" is a bit ambiguous. Could this be named something to indicate
>>>> a security context rather than any other sort, such as audit or user
>>>> context?
>>> Would "subj_obj_fields" be better?
>> That is much more obvious to me. Maybe even sec_context_multi, but I
>> like your suggestion better?
> How about just "multiple_lsms"? It's relatively concise and better
> reflects what it is actually being tested IMHO.
I'm perfectly happy to call it whatever you'd prefer.
Anything substantive about the test itself?
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-07 0:51 ` Casey Schaufler
@ 2020-11-08 13:38 ` Paul Moore
2020-11-09 13:07 ` Richard Guy Briggs
1 sibling, 0 replies; 9+ messages in thread
From: Paul Moore @ 2020-11-08 13:38 UTC (permalink / raw)
To: Casey Schaufler; +Cc: Richard Guy Briggs, linux-audit@redhat.com
On Fri, Nov 6, 2020 at 7:52 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> I'm perfectly happy to call it whatever you'd prefer.
> Anything substantive about the test itself?
Nothing jumped out at me. It's also worth mentioning that the
acceptance bar for the audit-testsuite is much lower than the kernel
for all the usual reasons.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness
2020-11-07 0:51 ` Casey Schaufler
2020-11-08 13:38 ` Paul Moore
@ 2020-11-09 13:07 ` Richard Guy Briggs
1 sibling, 0 replies; 9+ messages in thread
From: Richard Guy Briggs @ 2020-11-09 13:07 UTC (permalink / raw)
To: Casey Schaufler; +Cc: linux-audit@redhat.com
On 2020-11-06 16:51, Casey Schaufler wrote:
> On 11/2/2020 7:31 PM, Paul Moore wrote:
> > On Mon, Nov 2, 2020 at 8:19 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >> On 2020-11-02 14:51, Casey Schaufler wrote:
> >>> On 11/2/2020 2:08 PM, Richard Guy Briggs wrote:
> >>>> On 2020-11-02 13:54, Casey Schaufler wrote:
> >>>>> Verify that there are subj= and obj= fields in a record
> >>>>> if and only if they are expected. A system without a security
> >>>>> module that provides these fields should not include them.
> >>>>> A system with multiple security modules providing these fields
> >>>>> (e.g. SELinux and AppArmor) should always provide "?" for the
> >>>>> data and also include a AUDIT_MAC_TASK_CONTEXTS or
> >>>>> AUDIT_MAC_OBJ_CONTEXTS record. The test uses the LSM list from
> >>>>> /sys/kernel/security/lsm to determine which format is expected.
> >>>>>
> >>>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> >>>>> ---
> >>>>> tests/Makefile | 1 +
> >>>>> tests/multiple_contexts/Makefile | 12 +++
> >>>>> tests/multiple_contexts/test | 166 +++++++++++++++++++++++++++++++
> >>>>> 3 files changed, 179 insertions(+)
> >>>>> create mode 100644 tests/multiple_contexts/Makefile
> >>>>> create mode 100755 tests/multiple_contexts/test
> >>>>>
> >>>>> diff --git a/tests/Makefile b/tests/Makefile
> >>>>> index a7f242a..f20f6b1 100644
> >>>>> --- a/tests/Makefile
> >>>>> +++ b/tests/Makefile
> >>>>> @@ -18,6 +18,7 @@ TESTS := \
> >>>>> file_create \
> >>>>> file_delete \
> >>>>> file_rename \
> >>>>> + multiple_contexts \
> >>>> "context" is a bit ambiguous. Could this be named something to indicate
> >>>> a security context rather than any other sort, such as audit or user
> >>>> context?
> >>> Would "subj_obj_fields" be better?
> >> That is much more obvious to me. Maybe even sec_context_multi, but I
> >> like your suggestion better?
> > How about just "multiple_lsms"? It's relatively concise and better
> > reflects what it is actually being tested IMHO.
>
> I'm perfectly happy to call it whatever you'd prefer.
> Anything substantive about the test itself?
The test looked reasonable to me...
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-11-09 13:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <e4bf30e2-a92f-99b7-30d0-3e3473e30399.ref@schaufler-ca.com>
2020-11-02 21:54 ` [RFC PATCH] audit-testsuite: tests for subject and object correctness Casey Schaufler
2020-11-02 22:08 ` Richard Guy Briggs
2020-11-02 22:51 ` Casey Schaufler
2020-11-03 1:19 ` Richard Guy Briggs
2020-11-03 3:31 ` Paul Moore
2020-11-03 12:00 ` Richard Guy Briggs
2020-11-07 0:51 ` Casey Schaufler
2020-11-08 13:38 ` Paul Moore
2020-11-09 13:07 ` Richard Guy Briggs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox