[RFC PATCH] audit-testsuite: tests for subject and object correctness

[RFC PATCH] audit-testsuite: tests for subject and object correctness

[Casey Schaufler]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Richard Guy Briggs]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Casey Schaufler]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Richard Guy Briggs]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Paul Moore]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Richard Guy Briggs]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Casey Schaufler]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Paul Moore]

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

Re: [RFC PATCH] audit-testsuite: tests for subject and object correctness

[Richard Guy Briggs]

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