[PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.

Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mickaël Salaün <mic@digikod.net>
Tested-by: Jeff Xu <jeffxu@google.com>
Signed-off-by: Jeff Xu <jeffxu@google.com>
Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
---
 .../testing/selftests/landlock/ptrace_test.c  | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c
index c28ef98ff3ac..ef2d36f56764 100644
--- a/tools/testing/selftests/landlock/ptrace_test.c
+++ b/tools/testing/selftests/landlock/ptrace_test.c
@@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy)
 {
 }
 
+int open_sysfs(const char *path, int flags, int *fd)
+{
+	*fd = open(path, flags);
+
+	if (fd < 0)
+		return -1;
+
+	return 0;
+}
+
+int read_sysfs_int_fd(int fd, int *val)
+{
+	char buf[2];
+
+	if (read(fd, buf, sizeof(buf)) < 0)
+		return -1;
+
+	buf[sizeof(buf) - 1] = '\0';
+	*val = atoi(buf);
+	return 0;
+}
+
+int read_sysfs_int(const char *path, int *val)
+{
+	int fd;
+
+	if (open_sysfs(path, O_RDONLY, &fd) != 0)
+		return -1;
+
+	if (read_sysfs_int_fd(fd, val) != 0) {
+		close(fd);
+		return -1;
+	}
+
+	close(fd);
+	return 0;
+}
+
 /* Test PTRACE_TRACEME and PTRACE_ATTACH for parent and child. */
 TEST_F(hierarchy, trace)
 {
@@ -235,6 +273,17 @@ TEST_F(hierarchy, trace)
 	char buf_parent;
 	long ret;
 
+	int ptrace_val;
+
+	ASSERT_EQ(0, read_sysfs_int("/proc/sys/kernel/yama/ptrace_scope",
+				    &ptrace_val));
+	if (ptrace_val != 0) {
+		/*
+		 * Yama's scoped ptrace is presumed disabled.  If enabled, skip.
+		 */
+		SKIP(return, "yama is enabled, skip current test");
+	}
+
 	/*
 	 * Removes all effective and permitted capabilities to not interfere
 	 * with cap_ptrace_access_check() in case of PTRACE_MODE_FSCREDS.
-- 
2.37.0.rc0.161.g10f37bed90-goog

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Mickaël Salaün]

Hi Jeff,

Thanks for this patch. Here are some comments:

On 29/06/2022 00:29, Jeff Xu wrote:
> ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
> 
> Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
> Cc: Guenter Roeck <groeck@chromium.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mickaël Salaün <mic@digikod.net>
> Tested-by: Jeff Xu <jeffxu@google.com>
> Signed-off-by: Jeff Xu <jeffxu@google.com>
> Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
> ---
>   .../testing/selftests/landlock/ptrace_test.c  | 49 +++++++++++++++++++
>   1 file changed, 49 insertions(+)
> 
> diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c
> index c28ef98ff3ac..ef2d36f56764 100644
> --- a/tools/testing/selftests/landlock/ptrace_test.c
> +++ b/tools/testing/selftests/landlock/ptrace_test.c
> @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy)
>   {
>   }
>   

Please move these new helpers after test_ptrace_read() and make them static.

> +int open_sysfs(const char *path, int flags, int *fd)
> +{
> +	*fd = open(path, flags);
> +
> +	if (fd < 0)
> +		return -1;
> +
> +	return 0;
> +}

open_sysfs() can be replaced with a call to open(). This makes the code 
simpler.

> +
> +int read_sysfs_int_fd(int fd, int *val)
> +{
> +	char buf[2];
> +
> +	if (read(fd, buf, sizeof(buf)) < 0)

I guess `read(fd, buf, 1)` should be enough and it enables keeping the 
final '\0'. A comment should state that this helper only read the first 
digit (which is enough for Yama).

> +		return -1;
> +
> +	buf[sizeof(buf) - 1] = '\0';

Use `char buf[2] = {};` instead.

> +	*val = atoi(buf);
> +	return 0;
> +}

Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int().

> +
> +int read_sysfs_int(const char *path, int *val)
> +{
> +	int fd;
> +
> +	if (open_sysfs(path, O_RDONLY, &fd) != 0)
> +		return -1;
> +
> +	if (read_sysfs_int_fd(fd, val) != 0) {
> +		close(fd);
> +		return -1;
> +	}
> +
> +	close(fd);
> +	return 0;
> +}
> +
>   /* Test PTRACE_TRACEME and PTRACE_ATTACH for parent and child. */
>   TEST_F(hierarchy, trace)
>   {
> @@ -235,6 +273,17 @@ TEST_F(hierarchy, trace)
>   	char buf_parent;
>   	long ret;
>   
> +	int ptrace_val;
> +
> +	ASSERT_EQ(0, read_sysfs_int("/proc/sys/kernel/yama/ptrace_scope",
> +				    &ptrace_val));

This is a good test but it fail if Yama is not built in the kernel.

For now, I think you can create two helpers named something like 
is_yama_restricting() and is_yama_denying() (for admin-only attach).

> +	if (ptrace_val != 0) {

Some tests should work even if ptrace_val == 1. SKIP() should only be 
called when the test would fail. Can you please check all tests with all 
Yama values?

> +		/*
> +		 * Yama's scoped ptrace is presumed disabled.  If enabled, skip.
> +		 */
> +		SKIP(return, "yama is enabled, skip current test");
> +	}
> +
>   	/*
>   	 * Removes all effective and permitted capabilities to not interfere
>   	 * with cap_ptrace_access_check() in case of PTRACE_MODE_FSCREDS.

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Mickaël Salaün]

On 29/06/2022 00:29, Jeff Xu wrote:
> ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
> 
> Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
> Cc: Guenter Roeck <groeck@chromium.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mickaël Salaün <mic@digikod.net>
> Tested-by: Jeff Xu <jeffxu@google.com>

I guess we assume that Signed-off-by implies Tested-by, so you can 
remove this Tested-by.

> Signed-off-by: Jeff Xu <jeffxu@google.com>
> Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f

Please remove this Change-Id too.

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

Hi Mickaël

Thank you for your review, please see my response below.

> Hi Jeff,
>
> Thanks for this patch. Here are some comments:
>
> On 29/06/2022 00:29, Jeff Xu wrote:
> > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
> >
> > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
> > Cc: Guenter Roeck <groeck@chromium.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Mickaël Salaün <mic@digikod.net>
> > Tested-by: Jeff Xu <jeffxu@google.com>
> > Signed-off-by: Jeff Xu <jeffxu@google.com>
> > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
> > ---
> >   .../testing/selftests/landlock/ptrace_test.c  | 49 +++++++++++++++++++
> >   1 file changed, 49 insertions(+)
> >
> > diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c
> > index c28ef98ff3ac..ef2d36f56764 100644
> > --- a/tools/testing/selftests/landlock/ptrace_test.c
> > +++ b/tools/testing/selftests/landlock/ptrace_test.c
> > @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy)
> >   {
> >   }
> >
>
> Please move these new helpers after test_ptrace_read() and make them static.
>
> > +int open_sysfs(const char *path, int flags, int *fd)
> > +{
> > +     *fd = open(path, flags);
> > +
> > +     if (fd < 0)
> > +             return -1;
> > +
> > +     return 0;
> > +}
>
> open_sysfs() can be replaced with a call to open(). This makes the code
> simpler.
>
> > +
> > +int read_sysfs_int_fd(int fd, int *val)
> > +{
> > +     char buf[2];
> > +
> > +     if (read(fd, buf, sizeof(buf)) < 0)
>
> I guess `read(fd, buf, 1)` should be enough and it enables keeping the
> final '\0'. A comment should state that this helper only read the first
> digit (which is enough for Yama).
>
> > +             return -1;
> > +
> > +     buf[sizeof(buf) - 1] = '\0';
>
> Use `char buf[2] = {};` instead.
>
> > +     *val = atoi(buf);
> > +     return 0;
> > +}
>

Thanks, I will revise the code, my original thought is to extend it as
a common utility function to parse an int, let me finish it in the
next iteration of patch.

> Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int().
> This is a good test but it fail if Yama is not built in the kernel.
>
I don't have a kernel built without yama, so my original thought is to
fail it and whoever has the need can fix it. What is your thought on this ?

> For now, I think you can create two helpers named something like
> is_yama_restricting() and is_yama_denying() (for admin-only attach).
>
Can you please clarify on the difference/implementation on those 2 ?

> > +     if (ptrace_val != 0) {
>
> Some tests should work even if ptrace_val == 1. SKIP() should only be
> called when the test would fail. Can you please check all tests with all
> Yama values?
Sure, below are yama cases with testing result:
=====================================
case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
    process running under the same uid, as long as it is dumpable (i.e.
    did not transition uids, start privileged, or have called
    prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
    unchanged.

Test: All passing
======================================
Case 1 - restricted ptrace: a process must have a predefined relationship
    with the inferior it wants to call PTRACE_ATTACH on. By default,
    this relationship is that of only its descendants when the above
    classic criteria is also met. To change the relationship, an
    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
    an allowed debugger PID to call PTRACE_ATTACH on the inferior.
    Using PTRACE_TRACEME is unchanged.

Test:
// Base_test: 7/7 pass.
// Fs_test 46/48 pass
//.   not ok 47 layout2_overlay.no_restriction
//.   not ok 48 layout2_overlay.same_content_different_file
//  Ptrace_test 4/8 pass
// #          FAIL  hierarchy.allow_without_domain.trace
// #          FAIL  hierarchy.deny_with_parent_domain.trace
// #          FAIL  hierarchy.allow_sibling_domain.trace
// #          FAIL  hierarchy.deny_with_nested_and_parent_domain.trace
====================================================
Case 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
    with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
Case 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
    PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
Test: *case2 and case3 have the same results:
// Base_test: 7/7 pass.
// Fs_test 46/48 pass
//.   not ok 47 layout2_overlay.no_restriction
//.   not ok 48 layout2_overlay.same_content_different_file
//  Ptrace 2/8 pass
//.  ok 4 hierarchy.deny_with_sibling_domain.trace
//.  ok 8 hierarchy.deny_with_forked_domain.trace
// the other 6 tests failed with timeout.
===============================================

Do you know why fs_test (47,48) is failing when yama value = 1,2,3 ?

FOR SKIP,  it might be messy to add SKIP after checking variant names
in TEST_F(), (too many if/else , which make it less readable),
ideally this should be when or before FIXTURE_VARIANT_ADD() is called.
or somehow refactor the code to remove the variant check in TEST_F()

Is there a better way  ?

Thanks
Best Regards,
Jeff



On Thu, Jun 30, 2022 at 8:31 AM Mickaël Salaün <mic@digikod.net> wrote:
>
>
> On 29/06/2022 00:29, Jeff Xu wrote:
> > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
> >
> > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
> > Cc: Guenter Roeck <groeck@chromium.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Mickaël Salaün <mic@digikod.net>
> > Tested-by: Jeff Xu <jeffxu@google.com>
>
> I guess we assume that Signed-off-by implies Tested-by, so you can
> remove this Tested-by.
>
> > Signed-off-by: Jeff Xu <jeffxu@google.com>
> > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
>
> Please remove this Change-Id too.

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

A correction (resend with plain text)

> =====================================
> case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
>     process running under the same uid, as long as it is dumpable (i.e.
>     did not transition uids, start privileged, or have called
>     prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
>     unchanged.

// Base_test: 7/7 pass.
// Fs_test 46/48 pass
//.   not ok 47 layout2_overlay.no_restriction
//.   not ok 48 layout2_overlay.same_content_different_file
//  Ptrace 8/8 pass

Note: 47,48 of fs_test are failing for all YAMA config values (0-3)


On Tue, Jul 5, 2022 at 2:49 PM Jeff Xu <jeffxu@google.com> wrote:
>
> Hi Mickaël
>
> Thank you for your review, please see my response below.
>
> > Hi Jeff,
> >
> > Thanks for this patch. Here are some comments:
> >
> > On 29/06/2022 00:29, Jeff Xu wrote:
> > > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
> > >
> > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
> > > Cc: Guenter Roeck <groeck@chromium.org>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Cc: Mickaël Salaün <mic@digikod.net>
> > > Tested-by: Jeff Xu <jeffxu@google.com>
> > > Signed-off-by: Jeff Xu <jeffxu@google.com>
> > > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
> > > ---
> > >   .../testing/selftests/landlock/ptrace_test.c  | 49 +++++++++++++++++++
> > >   1 file changed, 49 insertions(+)
> > >
> > > diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c
> > > index c28ef98ff3ac..ef2d36f56764 100644
> > > --- a/tools/testing/selftests/landlock/ptrace_test.c
> > > +++ b/tools/testing/selftests/landlock/ptrace_test.c
> > > @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy)
> > >   {
> > >   }
> > >
> >
> > Please move these new helpers after test_ptrace_read() and make them static.
> >
> > > +int open_sysfs(const char *path, int flags, int *fd)
> > > +{
> > > +     *fd = open(path, flags);
> > > +
> > > +     if (fd < 0)
> > > +             return -1;
> > > +
> > > +     return 0;
> > > +}
> >
> > open_sysfs() can be replaced with a call to open(). This makes the code
> > simpler.
> >
> > > +
> > > +int read_sysfs_int_fd(int fd, int *val)
> > > +{
> > > +     char buf[2];
> > > +
> > > +     if (read(fd, buf, sizeof(buf)) < 0)
> >
> > I guess `read(fd, buf, 1)` should be enough and it enables keeping the
> > final '\0'. A comment should state that this helper only read the first
> > digit (which is enough for Yama).
> >
> > > +             return -1;
> > > +
> > > +     buf[sizeof(buf) - 1] = '\0';
> >
> > Use `char buf[2] = {};` instead.
> >
> > > +     *val = atoi(buf);
> > > +     return 0;
> > > +}
> >
>
> Thanks, I will revise the code, my original thought is to extend it as
> a common utility function to parse an int, let me finish it in the
> next iteration of patch.
>
> > Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int().
> > This is a good test but it fail if Yama is not built in the kernel.
> >
> I don't have a kernel built without yama, so my original thought is to
> fail it and whoever has the need can fix it. What is your thought on this ?
>
> > For now, I think you can create two helpers named something like
> > is_yama_restricting() and is_yama_denying() (for admin-only attach).
> >
> Can you please clarify on the difference/implementation on those 2 ?
>
> > > +     if (ptrace_val != 0) {
> >
> > Some tests should work even if ptrace_val == 1. SKIP() should only be
> > called when the test would fail. Can you please check all tests with all
> > Yama values?
> Sure, below are yama cases with testing result:
> =====================================
> case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
>     process running under the same uid, as long as it is dumpable (i.e.
>     did not transition uids, start privileged, or have called
>     prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
>     unchanged.
>
> Test: All passing
> ======================================
> Case 1 - restricted ptrace: a process must have a predefined relationship
>     with the inferior it wants to call PTRACE_ATTACH on. By default,
>     this relationship is that of only its descendants when the above
>     classic criteria is also met. To change the relationship, an
>     inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
>     an allowed debugger PID to call PTRACE_ATTACH on the inferior.
>     Using PTRACE_TRACEME is unchanged.
>
> Test:
> // Base_test: 7/7 pass.
> // Fs_test 46/48 pass
> //.   not ok 47 layout2_overlay.no_restriction
> //.   not ok 48 layout2_overlay.same_content_different_file
> //  Ptrace_test 4/8 pass
> // #          FAIL  hierarchy.allow_without_domain.trace
> // #          FAIL  hierarchy.deny_with_parent_domain.trace
> // #          FAIL  hierarchy.allow_sibling_domain.trace
> // #          FAIL  hierarchy.deny_with_nested_and_parent_domain.trace
> ====================================================
> Case 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
>     with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
> Case 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
>     PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
> Test: *case2 and case3 have the same results:
> // Base_test: 7/7 pass.
> // Fs_test 46/48 pass
> //.   not ok 47 layout2_overlay.no_restriction
> //.   not ok 48 layout2_overlay.same_content_different_file
> //  Ptrace 2/8 pass
> //.  ok 4 hierarchy.deny_with_sibling_domain.trace
> //.  ok 8 hierarchy.deny_with_forked_domain.trace
> // the other 6 tests failed with timeout.
> ===============================================
>
> Do you know why fs_test (47,48) is failing when yama value = 1,2,3 ?
>
> FOR SKIP,  it might be messy to add SKIP after checking variant names
> in TEST_F(), (too many if/else , which make it less readable),
> ideally this should be when or before FIXTURE_VARIANT_ADD() is called.
> or somehow refactor the code to remove the variant check in TEST_F()
>
> Is there a better way  ?
>
> Thanks
> Best Regards,
> Jeff
>
>
>
> On Thu, Jun 30, 2022 at 8:31 AM Mickaël Salaün <mic@digikod.net> wrote:
> >
> >
> > On 29/06/2022 00:29, Jeff Xu wrote:
> > > ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
> > >
> > > Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
> > > Cc: Guenter Roeck <groeck@chromium.org>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Cc: Mickaël Salaün <mic@digikod.net>
> > > Tested-by: Jeff Xu <jeffxu@google.com>
> >
> > I guess we assume that Signed-off-by implies Tested-by, so you can
> > remove this Tested-by.
> >
> > > Signed-off-by: Jeff Xu <jeffxu@google.com>
> > > Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
> >
> > Please remove this Change-Id too.

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Mickaël Salaün]

On 05/07/2022 23:49, Jeff Xu wrote:
> Hi Mickaël
> 
> Thank you for your review, please see my response below.
> 
>> Hi Jeff,
>>
>> Thanks for this patch. Here are some comments:
>>
>> On 29/06/2022 00:29, Jeff Xu wrote:
>>> ptrace_test assumes YAMA is disabled, skip it if YAMA is enabled.
>>>
>>> Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
>>> Cc: Guenter Roeck <groeck@chromium.org>
>>> Cc: Kees Cook <keescook@chromium.org>
>>> Cc: Mickaël Salaün <mic@digikod.net>
>>> Tested-by: Jeff Xu <jeffxu@google.com>
>>> Signed-off-by: Jeff Xu <jeffxu@google.com>
>>> Change-Id: I623742ca9f20ec706a38c92f6c0bab755f73578f
>>> ---
>>>    .../testing/selftests/landlock/ptrace_test.c  | 49 +++++++++++++++++++
>>>    1 file changed, 49 insertions(+)
>>>
>>> diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c
>>> index c28ef98ff3ac..ef2d36f56764 100644
>>> --- a/tools/testing/selftests/landlock/ptrace_test.c
>>> +++ b/tools/testing/selftests/landlock/ptrace_test.c
>>> @@ -226,6 +226,44 @@ FIXTURE_TEARDOWN(hierarchy)
>>>    {
>>>    }
>>>
>>
>> Please move these new helpers after test_ptrace_read() and make them static.
>>
>>> +int open_sysfs(const char *path, int flags, int *fd)
>>> +{
>>> +     *fd = open(path, flags);
>>> +
>>> +     if (fd < 0)
>>> +             return -1;
>>> +
>>> +     return 0;
>>> +}
>>
>> open_sysfs() can be replaced with a call to open(). This makes the code
>> simpler.
>>
>>> +
>>> +int read_sysfs_int_fd(int fd, int *val)
>>> +{
>>> +     char buf[2];
>>> +
>>> +     if (read(fd, buf, sizeof(buf)) < 0)
>>
>> I guess `read(fd, buf, 1)` should be enough and it enables keeping the
>> final '\0'. A comment should state that this helper only read the first
>> digit (which is enough for Yama).
>>
>>> +             return -1;
>>> +
>>> +     buf[sizeof(buf) - 1] = '\0';
>>
>> Use `char buf[2] = {};` instead.
>>
>>> +     *val = atoi(buf);
>>> +     return 0;
>>> +}
>>
> 
> Thanks, I will revise the code, my original thought is to extend it as
> a common utility function to parse an int, let me finish it in the
> next iteration of patch.
> 
>> Same for read_sysfs_int_fd(), you can inline the code in read_sysfs_int().
>> This is a good test but it fail if Yama is not built in the kernel.
>>
> I don't have a kernel built without yama, so my original thought is to
> fail it and whoever has the need can fix it. What is your thought on this ?

The current status is that all tests should pass with a minimal kernel 
configuration (cf. the test config file). Yama is an exception for these 
tests, not the norm, so you also need to test against a kernel without Yama.


> 
>> For now, I think you can create two helpers named something like
>> is_yama_restricting() and is_yama_denying() (for admin-only attach).
>>
> Can you please clarify on the difference/implementation on those 2 ?

They should check for the different values of ptrace_scope: 
https://docs.kernel.org/admin-guide/LSM/Yama.html
- is_yama_restricting() should return true if ptrace_scope == 1
- is_yama_denying() should return true if ptrace_scope >= 2

Restricted ptrace only forbids a child process to ptrace its parents. 
There is no specific restriction for a parent to ptrace its children.

Ptracing is always denied if ptrace_scope >= 2 (without specific 
capabilties, which is the case for these tests).

> 
>>> +     if (ptrace_val != 0) {
>>
>> Some tests should work even if ptrace_val == 1. SKIP() should only be
>> called when the test would fail. Can you please check all tests with all
>> Yama values?
> Sure, below are yama cases with testing result:
> =====================================
> case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
>      process running under the same uid, as long as it is dumpable (i.e.
>      did not transition uids, start privileged, or have called
>      prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
>      unchanged.
> 
> Test: All passing
> ======================================
> Case 1 - restricted ptrace: a process must have a predefined relationship
>      with the inferior it wants to call PTRACE_ATTACH on. By default,
>      this relationship is that of only its descendants when the above
>      classic criteria is also met. To change the relationship, an
>      inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
>      an allowed debugger PID to call PTRACE_ATTACH on the inferior.
>      Using PTRACE_TRACEME is unchanged.
> 
> Test:
> // Base_test: 7/7 pass.
> // Fs_test 46/48 pass
> //.   not ok 47 layout2_overlay.no_restriction
> //.   not ok 48 layout2_overlay.same_content_different_file
> //  Ptrace_test 4/8 pass
> // #          FAIL  hierarchy.allow_without_domain.trace
> // #          FAIL  hierarchy.deny_with_parent_domain.trace
> // #          FAIL  hierarchy.allow_sibling_domain.trace
> // #          FAIL  hierarchy.deny_with_nested_and_parent_domain.trace
> ====================================================
> Case 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
>      with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
> Case 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
>      PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
> Test: *case2 and case3 have the same results:
> // Base_test: 7/7 pass.
> // Fs_test 46/48 pass
> //.   not ok 47 layout2_overlay.no_restriction
> //.   not ok 48 layout2_overlay.same_content_different_file
> //  Ptrace 2/8 pass
> //.  ok 4 hierarchy.deny_with_sibling_domain.trace
> //.  ok 8 hierarchy.deny_with_forked_domain.trace
> // the other 6 tests failed with timeout.
> ===============================================
> 
> Do you know why fs_test (47,48) is failing when yama value = 1,2,3 ?

These are all the overlayfs tests but I don't know why they are failing 
with Yama. Could you please pinpoint the exact(s) failing ASSERT? 
(Whatever my following comments, this would be valuable to know the issue.)


> 
> FOR SKIP,  it might be messy to add SKIP after checking variant names
> in TEST_F(), (too many if/else , which make it less readable),
> ideally this should be when or before FIXTURE_VARIANT_ADD() is called.
> or somehow refactor the code to remove the variant check in TEST_F()
> 
> Is there a better way  ?

OK, let's follow another approach.

The first alternative would be to disable Yama for all the Landlock 
ptrace tests. You'll first need to save the current Yama settings and 
restore it after each test, even if they failed. I think this 
alternative makes sense because Landlock tests should not be about Yama.

The second alternative would be to test with and without Yama, with 
different Yama settings. That would also require to disable Yama for 1/3 
or 1/4 of tests. The downside of this alternative is that it requires 3 
or 4 times variants, and it actually test Yama, which is not the goal of 
the Landlock tests.

Anyway, you also need to update the comment about Yama in the current tests.

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Mickaël Salaün]

On 07/07/2022 01:35, Jeff Xu wrote:
> a correction:
> 
>     =====================================
>     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
>     any other
>          process running under the same uid, as long as it is dumpable (i.e.
>          did not transition uids, start privileged, or have called
>          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
>          unchanged.
> 
>     Test: All passing
> 
> // Base_test: 7/7 pass.
> // Fs_test 46/48 pass
> //.   not ok 47 layout2_overlay.no_restriction
> //.   not ok 48 layout2_overlay.same_content_different_file
> //  Ptrace 8/8 pass

Hmm, well, it is not related to Yama then. Could it be linked to other 
Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

> > a correction:
> >
> >     =====================================
> >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> >     any other
> >          process running under the same uid, as long as it is dumpable (i.e.
> >          did not transition uids, start privileged, or have called
> >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> >          unchanged.
> >
> >     Test: All passing
> >
> > // Base_test: 7/7 pass.
> > // Fs_test 46/48 pass
> > //.   not ok 47 layout2_overlay.no_restriction
> > //.   not ok 48 layout2_overlay.same_content_different_file
> > //  Ptrace 8/8 pass


> Hmm, well, it is not related to Yama then. Could it be linked to other
> Chromium OS non-upstream patches?


fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
enabled in chromeOS.
If there is a reliable way of detecting OVERLAYFS (checking mount
overlayfs is successful ? ), this is a good candidate to add SKIP.

Overall, all the failure of landlock selftest seen in chromeOS are
expected, we just need to modify the test.

Thanks
Best Regards
Jeff



On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
>
>
> On 07/07/2022 01:35, Jeff Xu wrote:
> > a correction:
> >
> >     =====================================
> >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> >     any other
> >          process running under the same uid, as long as it is dumpable (i.e.
> >          did not transition uids, start privileged, or have called
> >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> >          unchanged.
> >
> >     Test: All passing
> >
> > // Base_test: 7/7 pass.
> > // Fs_test 46/48 pass
> > //.   not ok 47 layout2_overlay.no_restriction
> > //.   not ok 48 layout2_overlay.same_content_different_file
> > //  Ptrace 8/8 pass
>
> Hmm, well, it is not related to Yama then. Could it be linked to other
> Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Guenter Roeck]

On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
>
> > > a correction:
> > >
> > >     =====================================
> > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > >     any other
> > >          process running under the same uid, as long as it is dumpable (i.e.
> > >          did not transition uids, start privileged, or have called
> > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > >          unchanged.
> > >
> > >     Test: All passing
> > >
> > > // Base_test: 7/7 pass.
> > > // Fs_test 46/48 pass
> > > //.   not ok 47 layout2_overlay.no_restriction
> > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > //  Ptrace 8/8 pass
>
>
> > Hmm, well, it is not related to Yama then. Could it be linked to other
> > Chromium OS non-upstream patches?
>
>
> fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> enabled in chromeOS.
> If there is a reliable way of detecting OVERLAYFS (checking mount
> overlayfs is successful ? ), this is a good candidate to add SKIP.
>

IS_ENABLED(CONFIG_OVERLAY_FS) ?

> Overall, all the failure of landlock selftest seen in chromeOS are
> expected, we just need to modify the test.
>
> Thanks
> Best Regards
> Jeff
>
>
>
> On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> >
> >
> > On 07/07/2022 01:35, Jeff Xu wrote:
> > > a correction:
> > >
> > >     =====================================
> > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > >     any other
> > >          process running under the same uid, as long as it is dumpable (i.e.
> > >          did not transition uids, start privileged, or have called
> > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > >          unchanged.
> > >
> > >     Test: All passing
> > >
> > > // Base_test: 7/7 pass.
> > > // Fs_test 46/48 pass
> > > //.   not ok 47 layout2_overlay.no_restriction
> > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > //  Ptrace 8/8 pass
> >
> > Hmm, well, it is not related to Yama then. Could it be linked to other
> > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

> > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > Chromium OS non-upstream patches?
> >
> >
> > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > enabled in chromeOS.
> > If there is a reliable way of detecting OVERLAYFS (checking mount
> > overlayfs is successful ? ), this is a good candidate to add SKIP.
> >

> IS_ENABLED(CONFIG_OVERLAY_FS) ?

Could be. Landlock selftest currently is a user space program though,
IS_ENABLED will depend on the kernel header during compile time.


On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
>
> On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> >
> > > > a correction:
> > > >
> > > >     =====================================
> > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > >     any other
> > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > >          did not transition uids, start privileged, or have called
> > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > >          unchanged.
> > > >
> > > >     Test: All passing
> > > >
> > > > // Base_test: 7/7 pass.
> > > > // Fs_test 46/48 pass
> > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > //  Ptrace 8/8 pass
> >
> >
> > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > Chromium OS non-upstream patches?
> >
> >
> > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > enabled in chromeOS.
> > If there is a reliable way of detecting OVERLAYFS (checking mount
> > overlayfs is successful ? ), this is a good candidate to add SKIP.
> >
>
> IS_ENABLED(CONFIG_OVERLAY_FS) ?
>
> > Overall, all the failure of landlock selftest seen in chromeOS are
> > expected, we just need to modify the test.
> >
> > Thanks
> > Best Regards
> > Jeff
> >
> >
> >
> > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > >
> > >
> > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > a correction:
> > > >
> > > >     =====================================
> > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > >     any other
> > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > >          did not transition uids, start privileged, or have called
> > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > >          unchanged.
> > > >
> > > >     Test: All passing
> > > >
> > > > // Base_test: 7/7 pass.
> > > > // Fs_test 46/48 pass
> > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > //  Ptrace 8/8 pass
> > >
> > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Guenter Roeck]

On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
>
> > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > Chromium OS non-upstream patches?
> > >
> > >
> > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > enabled in chromeOS.
> > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > >
>
> > IS_ENABLED(CONFIG_OVERLAY_FS) ?
>
> Could be. Landlock selftest currently is a user space program though,
> IS_ENABLED will depend on the kernel header during compile time.
>

Ah, sorry, I thought it was an in-kernel test. Userspace should be
able to determine if overlayfs is supported by checking /sys/fs/ or
possibly /proc/fs/.

Guenter

>
> On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
> >
> > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> > >
> > > > > a correction:
> > > > >
> > > > >     =====================================
> > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > >     any other
> > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > >          did not transition uids, start privileged, or have called
> > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > >          unchanged.
> > > > >
> > > > >     Test: All passing
> > > > >
> > > > > // Base_test: 7/7 pass.
> > > > > // Fs_test 46/48 pass
> > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > //  Ptrace 8/8 pass
> > >
> > >
> > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > Chromium OS non-upstream patches?
> > >
> > >
> > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > enabled in chromeOS.
> > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > >
> >
> > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> >
> > > Overall, all the failure of landlock selftest seen in chromeOS are
> > > expected, we just need to modify the test.
> > >
> > > Thanks
> > > Best Regards
> > > Jeff
> > >
> > >
> > >
> > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > >
> > > >
> > > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > > a correction:
> > > > >
> > > > >     =====================================
> > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > >     any other
> > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > >          did not transition uids, start privileged, or have called
> > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > >          unchanged.
> > > > >
> > > > >     Test: All passing
> > > > >
> > > > > // Base_test: 7/7 pass.
> > > > > // Fs_test 46/48 pass
> > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > //  Ptrace 8/8 pass
> > > >
> > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

> On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> >
> > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > Chromium OS non-upstream patches?
> > > >
> > > >
> > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > enabled in chromeOS.
> > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > >
> >
> > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> >
> > Could be. Landlock selftest currently is a user space program though,
> > IS_ENABLED will depend on the kernel header during compile time.
> >


> Ah, sorry, I thought it was an in-kernel test. Userspace should be
> able to determine if overlayfs is supported by checking /sys/fs/ or
> possibly /proc/fs/.

Thanks for clarifying.

lsmod might be the one, such as:
lsmod | grep overlayfs


Thanks
Jeff



On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote:
>
> On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> >
> > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > Chromium OS non-upstream patches?
> > > >
> > > >
> > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > enabled in chromeOS.
> > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > >
> >
> > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> >
> > Could be. Landlock selftest currently is a user space program though,
> > IS_ENABLED will depend on the kernel header during compile time.
> >
>
> Ah, sorry, I thought it was an in-kernel test. Userspace should be
> able to determine if overlayfs is supported by checking /sys/fs/ or
> possibly /proc/fs/.
>
> Guenter
>
> >
> > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
> > >
> > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> > > >
> > > > > > a correction:
> > > > > >
> > > > > >     =====================================
> > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > >     any other
> > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > >          did not transition uids, start privileged, or have called
> > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > >          unchanged.
> > > > > >
> > > > > >     Test: All passing
> > > > > >
> > > > > > // Base_test: 7/7 pass.
> > > > > > // Fs_test 46/48 pass
> > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > //  Ptrace 8/8 pass
> > > >
> > > >
> > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > Chromium OS non-upstream patches?
> > > >
> > > >
> > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > enabled in chromeOS.
> > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > >
> > >
> > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > >
> > > > Overall, all the failure of landlock selftest seen in chromeOS are
> > > > expected, we just need to modify the test.
> > > >
> > > > Thanks
> > > > Best Regards
> > > > Jeff
> > > >
> > > >
> > > >
> > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > >
> > > > >
> > > > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > > > a correction:
> > > > > >
> > > > > >     =====================================
> > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > >     any other
> > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > >          did not transition uids, start privileged, or have called
> > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > >          unchanged.
> > > > > >
> > > > > >     Test: All passing
> > > > > >
> > > > > > // Base_test: 7/7 pass.
> > > > > > // Fs_test 46/48 pass
> > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > //  Ptrace 8/8 pass
> > > > >
> > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

Jeff Xu <jeffxu@google.com>

> Jul 14, 2022, 5:35 PM (20 hours ago)
> to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees
> > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > >
> > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > Chromium OS non-upstream patches?
> > > > >
> > > > >
> > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > enabled in chromeOS.
> > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > >
> > >
> > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > >
> > > Could be. Landlock selftest currently is a user space program though,
> > > IS_ENABLED will depend on the kernel header during compile time.
> > >



> > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > able to determine if overlayfs is supported by checking /sys/fs/ or
> > possibly /proc/fs/.


> Thanks for clarifying.


> lsmod might be the one, such as:
> lsmod | grep overlayfs


I built a kernel with overlayfs on chromeos, and lsmod didn't give me
what I wanted.
/sys/fs and /proc/fs also doesn't show anything about overlayfs

@Mickaël Salaün
Are you OK with SKIP the overlay test when mount("overlay",...) fails
in FIXTURE_SETUP() ? Mount failure can be used as an indication.

Jeff





On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote:
>
> > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > >
> > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > Chromium OS non-upstream patches?
> > > > >
> > > > >
> > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > enabled in chromeOS.
> > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > >
> > >
> > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > >
> > > Could be. Landlock selftest currently is a user space program though,
> > > IS_ENABLED will depend on the kernel header during compile time.
> > >
>
>
> > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > able to determine if overlayfs is supported by checking /sys/fs/ or
> > possibly /proc/fs/.
>
> Thanks for clarifying.
>
> lsmod might be the one, such as:
> lsmod | grep overlayfs
>
>
> Thanks
> Jeff
>
>
>
> On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote:
> >
> > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > >
> > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > Chromium OS non-upstream patches?
> > > > >
> > > > >
> > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > enabled in chromeOS.
> > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > >
> > >
> > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > >
> > > Could be. Landlock selftest currently is a user space program though,
> > > IS_ENABLED will depend on the kernel header during compile time.
> > >
> >
> > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > able to determine if overlayfs is supported by checking /sys/fs/ or
> > possibly /proc/fs/.
> >
> > Guenter
> >
> > >
> > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
> > > >
> > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> > > > >
> > > > > > > a correction:
> > > > > > >
> > > > > > >     =====================================
> > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > >     any other
> > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > >          did not transition uids, start privileged, or have called
> > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > >          unchanged.
> > > > > > >
> > > > > > >     Test: All passing
> > > > > > >
> > > > > > > // Base_test: 7/7 pass.
> > > > > > > // Fs_test 46/48 pass
> > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > //  Ptrace 8/8 pass
> > > > >
> > > > >
> > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > Chromium OS non-upstream patches?
> > > > >
> > > > >
> > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > enabled in chromeOS.
> > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > >
> > > >
> > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > >
> > > > > Overall, all the failure of landlock selftest seen in chromeOS are
> > > > > expected, we just need to modify the test.
> > > > >
> > > > > Thanks
> > > > > Best Regards
> > > > > Jeff
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > >
> > > > > >
> > > > > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > > > > a correction:
> > > > > > >
> > > > > > >     =====================================
> > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > >     any other
> > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > >          did not transition uids, start privileged, or have called
> > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > >          unchanged.
> > > > > > >
> > > > > > >     Test: All passing
> > > > > > >
> > > > > > > // Base_test: 7/7 pass.
> > > > > > > // Fs_test 46/48 pass
> > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > //  Ptrace 8/8 pass
> > > > > >
> > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Guenter Roeck]

On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote:
>
> Jeff Xu <jeffxu@google.com>
>
> > Jul 14, 2022, 5:35 PM (20 hours ago)
> > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees
> > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > >
> > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > Chromium OS non-upstream patches?
> > > > > >
> > > > > >
> > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > enabled in chromeOS.
> > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > >
> > > >
> > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > >
> > > > Could be. Landlock selftest currently is a user space program though,
> > > > IS_ENABLED will depend on the kernel header during compile time.
> > > >
>
>
>
> > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > possibly /proc/fs/.
>
>
> > Thanks for clarifying.
>
>
> > lsmod might be the one, such as:
> > lsmod | grep overlayfs
>
>
> I built a kernel with overlayfs on chromeos, and lsmod didn't give me
> what I wanted.
> /sys/fs and /proc/fs also doesn't show anything about overlayfs
>
> @Mickaël Salaün
> Are you OK with SKIP the overlay test when mount("overlay",...) fails
> in FIXTURE_SETUP() ? Mount failure can be used as an indication.
>

Maybe the error code returned from mount gives a hint. Also, how about
/proc/filesystems ?

Guenter

> Jeff
>
>
>
>
>
> On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote:
> >
> > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > >
> > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > Chromium OS non-upstream patches?
> > > > > >
> > > > > >
> > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > enabled in chromeOS.
> > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > >
> > > >
> > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > >
> > > > Could be. Landlock selftest currently is a user space program though,
> > > > IS_ENABLED will depend on the kernel header during compile time.
> > > >
> >
> >
> > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > possibly /proc/fs/.
> >
> > Thanks for clarifying.
> >
> > lsmod might be the one, such as:
> > lsmod | grep overlayfs
> >
> >
> > Thanks
> > Jeff
> >
> >
> >
> > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote:
> > >
> > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > >
> > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > Chromium OS non-upstream patches?
> > > > > >
> > > > > >
> > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > enabled in chromeOS.
> > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > >
> > > >
> > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > >
> > > > Could be. Landlock selftest currently is a user space program though,
> > > > IS_ENABLED will depend on the kernel header during compile time.
> > > >
> > >
> > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > possibly /proc/fs/.
> > >
> > > Guenter
> > >
> > > >
> > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
> > > > >
> > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> > > > > >
> > > > > > > > a correction:
> > > > > > > >
> > > > > > > >     =====================================
> > > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > > >     any other
> > > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > > >          did not transition uids, start privileged, or have called
> > > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > > >          unchanged.
> > > > > > > >
> > > > > > > >     Test: All passing
> > > > > > > >
> > > > > > > > // Base_test: 7/7 pass.
> > > > > > > > // Fs_test 46/48 pass
> > > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > > //  Ptrace 8/8 pass
> > > > > >
> > > > > >
> > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > Chromium OS non-upstream patches?
> > > > > >
> > > > > >
> > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > enabled in chromeOS.
> > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > >
> > > > >
> > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > >
> > > > > > Overall, all the failure of landlock selftest seen in chromeOS are
> > > > > > expected, we just need to modify the test.
> > > > > >
> > > > > > Thanks
> > > > > > Best Regards
> > > > > > Jeff
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > > > > > a correction:
> > > > > > > >
> > > > > > > >     =====================================
> > > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > > >     any other
> > > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > > >          did not transition uids, start privileged, or have called
> > > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > > >          unchanged.
> > > > > > > >
> > > > > > > >     Test: All passing
> > > > > > > >
> > > > > > > > // Base_test: 7/7 pass.
> > > > > > > > // Fs_test 46/48 pass
> > > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > > //  Ptrace 8/8 pass
> > > > > > >
> > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Jeff Xu]

> Maybe the error code returned from mount gives a hint.

It returns -1

>
> Also, how about
> /proc/filesystems ?

Yes. it has what I want:
nodev overlay

Thanks for your help! I can use this at runtime check.

Jeff


On Fri, Jul 15, 2022 at 3:42 PM Guenter Roeck <groeck@google.com> wrote:
>
> On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote:
> >
> > Jeff Xu <jeffxu@google.com>
> >
> > > Jul 14, 2022, 5:35 PM (20 hours ago)
> > > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees
> > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > > >
> > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > Chromium OS non-upstream patches?
> > > > > > >
> > > > > > >
> > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > enabled in chromeOS.
> > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > >
> > > > >
> > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > >
> > > > > Could be. Landlock selftest currently is a user space program though,
> > > > > IS_ENABLED will depend on the kernel header during compile time.
> > > > >
> >
> >
> >
> > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > > possibly /proc/fs/.
> >
> >
> > > Thanks for clarifying.
> >
> >
> > > lsmod might be the one, such as:
> > > lsmod | grep overlayfs
> >
> >
> > I built a kernel with overlayfs on chromeos, and lsmod didn't give me
> > what I wanted.
> > /sys/fs and /proc/fs also doesn't show anything about overlayfs
> >
> > @Mickaël Salaün
> > Are you OK with SKIP the overlay test when mount("overlay",...) fails
> > in FIXTURE_SETUP() ? Mount failure can be used as an indication.
> >
>
> Maybe the error code returned from mount gives a hint. Also, how about
> /proc/filesystems ?
>
> Guenter
>
> > Jeff
> >
> >
> >
> >
> >
> > On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote:
> > >
> > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > > >
> > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > Chromium OS non-upstream patches?
> > > > > > >
> > > > > > >
> > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > enabled in chromeOS.
> > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > >
> > > > >
> > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > >
> > > > > Could be. Landlock selftest currently is a user space program though,
> > > > > IS_ENABLED will depend on the kernel header during compile time.
> > > > >
> > >
> > >
> > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > > possibly /proc/fs/.
> > >
> > > Thanks for clarifying.
> > >
> > > lsmod might be the one, such as:
> > > lsmod | grep overlayfs
> > >
> > >
> > > Thanks
> > > Jeff
> > >
> > >
> > >
> > > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote:
> > > >
> > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > > >
> > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > Chromium OS non-upstream patches?
> > > > > > >
> > > > > > >
> > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > enabled in chromeOS.
> > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > >
> > > > >
> > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > >
> > > > > Could be. Landlock selftest currently is a user space program though,
> > > > > IS_ENABLED will depend on the kernel header during compile time.
> > > > >
> > > >
> > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > > possibly /proc/fs/.
> > > >
> > > > Guenter
> > > >
> > > > >
> > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
> > > > > >
> > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> > > > > > >
> > > > > > > > > a correction:
> > > > > > > > >
> > > > > > > > >     =====================================
> > > > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > > > >     any other
> > > > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > > > >          did not transition uids, start privileged, or have called
> > > > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > > > >          unchanged.
> > > > > > > > >
> > > > > > > > >     Test: All passing
> > > > > > > > >
> > > > > > > > > // Base_test: 7/7 pass.
> > > > > > > > > // Fs_test 46/48 pass
> > > > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > > > //  Ptrace 8/8 pass
> > > > > > >
> > > > > > >
> > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > Chromium OS non-upstream patches?
> > > > > > >
> > > > > > >
> > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > enabled in chromeOS.
> > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > >
> > > > > >
> > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > > >
> > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are
> > > > > > > expected, we just need to modify the test.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Best Regards
> > > > > > > Jeff
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > > > > > > a correction:
> > > > > > > > >
> > > > > > > > >     =====================================
> > > > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > > > >     any other
> > > > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > > > >          did not transition uids, start privileged, or have called
> > > > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > > > >          unchanged.
> > > > > > > > >
> > > > > > > > >     Test: All passing
> > > > > > > > >
> > > > > > > > > // Base_test: 7/7 pass.
> > > > > > > > > // Fs_test 46/48 pass
> > > > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > > > //  Ptrace 8/8 pass
> > > > > > > >
> > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Guenter Roeck]

On Fri, Jul 15, 2022 at 5:17 PM Jeff Xu <jeffxu@google.com> wrote:
>
> > Maybe the error code returned from mount gives a hint.
>
> It returns -1
>
Sorry, I meant errno, not the return value.

> >
> > Also, how about
> > /proc/filesystems ?
>
> Yes. it has what I want:
> nodev overlay
>
Excellent.

Guenter

> Thanks for your help! I can use this at runtime check.
>
> Jeff
>
>
> On Fri, Jul 15, 2022 at 3:42 PM Guenter Roeck <groeck@google.com> wrote:
> >
> > On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote:
> > >
> > > Jeff Xu <jeffxu@google.com>
> > >
> > > > Jul 14, 2022, 5:35 PM (20 hours ago)
> > > > to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees
> > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > > > >
> > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > > Chromium OS non-upstream patches?
> > > > > > > >
> > > > > > > >
> > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > > enabled in chromeOS.
> > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > > >
> > > > > >
> > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > > >
> > > > > > Could be. Landlock selftest currently is a user space program though,
> > > > > > IS_ENABLED will depend on the kernel header during compile time.
> > > > > >
> > >
> > >
> > >
> > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > > > possibly /proc/fs/.
> > >
> > >
> > > > Thanks for clarifying.
> > >
> > >
> > > > lsmod might be the one, such as:
> > > > lsmod | grep overlayfs
> > >
> > >
> > > I built a kernel with overlayfs on chromeos, and lsmod didn't give me
> > > what I wanted.
> > > /sys/fs and /proc/fs also doesn't show anything about overlayfs
> > >
> > > @Mickaël Salaün
> > > Are you OK with SKIP the overlay test when mount("overlay",...) fails
> > > in FIXTURE_SETUP() ? Mount failure can be used as an indication.
> > >
> >
> > Maybe the error code returned from mount gives a hint. Also, how about
> > /proc/filesystems ?
> >
> > Guenter
> >
> > > Jeff
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Jul 14, 2022 at 5:35 PM Jeff Xu <jeffxu@google.com> wrote:
> > > >
> > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > > > >
> > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > > Chromium OS non-upstream patches?
> > > > > > > >
> > > > > > > >
> > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > > enabled in chromeOS.
> > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > > >
> > > > > >
> > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > > >
> > > > > > Could be. Landlock selftest currently is a user space program though,
> > > > > > IS_ENABLED will depend on the kernel header during compile time.
> > > > > >
> > > >
> > > >
> > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > > > possibly /proc/fs/.
> > > >
> > > > Thanks for clarifying.
> > > >
> > > > lsmod might be the one, such as:
> > > > lsmod | grep overlayfs
> > > >
> > > >
> > > > Thanks
> > > > Jeff
> > > >
> > > >
> > > >
> > > > On Thu, Jul 14, 2022 at 1:40 PM Guenter Roeck <groeck@google.com> wrote:
> > > > >
> > > > > On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
> > > > > >
> > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > > Chromium OS non-upstream patches?
> > > > > > > >
> > > > > > > >
> > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > > enabled in chromeOS.
> > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > > >
> > > > > >
> > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > > >
> > > > > > Could be. Landlock selftest currently is a user space program though,
> > > > > > IS_ENABLED will depend on the kernel header during compile time.
> > > > > >
> > > > >
> > > > > Ah, sorry, I thought it was an in-kernel test. Userspace should be
> > > > > able to determine if overlayfs is supported by checking /sys/fs/ or
> > > > > possibly /proc/fs/.
> > > > >
> > > > > Guenter
> > > > >
> > > > > >
> > > > > > On Wed, Jul 13, 2022 at 5:30 PM Guenter Roeck <groeck@google.com> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 13, 2022 at 4:44 PM Jeff Xu <jeffxu@google.com> wrote:
> > > > > > > >
> > > > > > > > > > a correction:
> > > > > > > > > >
> > > > > > > > > >     =====================================
> > > > > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > > > > >     any other
> > > > > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > > > > >          did not transition uids, start privileged, or have called
> > > > > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > > > > >          unchanged.
> > > > > > > > > >
> > > > > > > > > >     Test: All passing
> > > > > > > > > >
> > > > > > > > > > // Base_test: 7/7 pass.
> > > > > > > > > > // Fs_test 46/48 pass
> > > > > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > > > > //  Ptrace 8/8 pass
> > > > > > > >
> > > > > > > >
> > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > > Chromium OS non-upstream patches?
> > > > > > > >
> > > > > > > >
> > > > > > > > fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
> > > > > > > > enabled in chromeOS.
> > > > > > > > If there is a reliable way of detecting OVERLAYFS (checking mount
> > > > > > > > overlayfs is successful ? ), this is a good candidate to add SKIP.
> > > > > > > >
> > > > > > >
> > > > > > > IS_ENABLED(CONFIG_OVERLAY_FS) ?
> > > > > > >
> > > > > > > > Overall, all the failure of landlock selftest seen in chromeOS are
> > > > > > > > expected, we just need to modify the test.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Best Regards
> > > > > > > > Jeff
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jul 7, 2022 at 7:25 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 07/07/2022 01:35, Jeff Xu wrote:
> > > > > > > > > > a correction:
> > > > > > > > > >
> > > > > > > > > >     =====================================
> > > > > > > > > >     case 0 - classic ptrace permissions: a process can PTRACE_ATTACH to
> > > > > > > > > >     any other
> > > > > > > > > >          process running under the same uid, as long as it is dumpable (i.e.
> > > > > > > > > >          did not transition uids, start privileged, or have called
> > > > > > > > > >          prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
> > > > > > > > > >          unchanged.
> > > > > > > > > >
> > > > > > > > > >     Test: All passing
> > > > > > > > > >
> > > > > > > > > > // Base_test: 7/7 pass.
> > > > > > > > > > // Fs_test 46/48 pass
> > > > > > > > > > //.   not ok 47 layout2_overlay.no_restriction
> > > > > > > > > > //.   not ok 48 layout2_overlay.same_content_different_file
> > > > > > > > > > //  Ptrace 8/8 pass
> > > > > > > > >
> > > > > > > > > Hmm, well, it is not related to Yama then. Could it be linked to other
> > > > > > > > > Chromium OS non-upstream patches?

Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled

[Mickaël Salaün]

On 16/07/2022 23:45, Guenter Roeck wrote:
> On Fri, Jul 15, 2022 at 5:17 PM Jeff Xu <jeffxu@google.com> wrote:
>>
>>> Maybe the error code returned from mount gives a hint.
>>
>> It returns -1
>>
> Sorry, I meant errno, not the return value.
> 
>>>
>>> Also, how about
>>> /proc/filesystems ?
>>
>> Yes. it has what I want:
>> nodev overlay
>>
> Excellent.
> 
> Guenter
> 
>> Thanks for your help! I can use this at runtime check.
>>
>> Jeff
>>
>>
>> On Fri, Jul 15, 2022 at 3:42 PM Guenter Roeck <groeck@google.com> wrote:
>>>
>>> On Fri, Jul 15, 2022 at 2:42 PM Jeff Xu <jeffxu@google.com> wrote:
>>>>
>>>> Jeff Xu <jeffxu@google.com>
>>>>
>>>>> Jul 14, 2022, 5:35 PM (20 hours ago)
>>>>> to Guenter, Mickaël, linux-security-module, Jorge, Guenter, Kees
>>>>>> On Thu, Jul 14, 2022 at 11:37 AM Jeff Xu <jeffxu@google.com> wrote:
>>>>>>>
>>>>>>>>>> Hmm, well, it is not related to Yama then. Could it be linked to other
>>>>>>>>>> Chromium OS non-upstream patches?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> fs_test.c 47 and 48 are failing in chromeOS because OVERLAYFS is not
>>>>>>>>> enabled in chromeOS.
>>>>>>>>> If there is a reliable way of detecting OVERLAYFS (checking mount
>>>>>>>>> overlayfs is successful ? ), this is a good candidate to add SKIP.
>>>>>>>>>
>>>>>>>
>>>>>>>> IS_ENABLED(CONFIG_OVERLAY_FS) ?
>>>>>>>
>>>>>>> Could be. Landlock selftest currently is a user space program though,
>>>>>>> IS_ENABLED will depend on the kernel header during compile time.
>>>>>>>
>>>>
>>>>
>>>>
>>>>>> Ah, sorry, I thought it was an in-kernel test. Userspace should be
>>>>>> able to determine if overlayfs is supported by checking /sys/fs/ or
>>>>>> possibly /proc/fs/.
>>>>
>>>>
>>>>> Thanks for clarifying.
>>>>
>>>>
>>>>> lsmod might be the one, such as:
>>>>> lsmod | grep overlayfs
>>>>
>>>>
>>>> I built a kernel with overlayfs on chromeos, and lsmod didn't give me
>>>> what I wanted.
>>>> /sys/fs and /proc/fs also doesn't show anything about overlayfs
>>>>
>>>> @Mickaël Salaün
>>>> Are you OK with SKIP the overlay test when mount("overlay",...) fails
>>>> in FIXTURE_SETUP() ? Mount failure can be used as an indication.

In a normal scenario, all configurations in 
tools/testing/selftests/landlock/config should be enabled, but I think 
it makes sense for some use cases like chromeOS to be able to not fail 
if overlayfs is not supported. Please patch 
FIXTURE_SETUP(layout2_overlay) to skip these tests if the related 
filesystem string is present (with or without "nodev") in 
/proc/filesystems . You can create a is_filesystem_supported(const char 
*filesystem) helper before prepare_layout() for this check, we'll need 
it for future tests.


>>>>
>>>
>>> Maybe the error code returned from mount gives a hint. Also, how about
>>> /proc/filesystems ?
>>>
>>> Guenter