* [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
@ 2022-06-28 22:29 Jeff Xu
2022-06-30 15:09 ` Mickaël Salaün
2022-06-30 15:31 ` Mickaël Salaün
0 siblings, 2 replies; 17+ messages in thread
From: Jeff Xu @ 2022-06-28 22:29 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, Jeff Xu, Jorge Lucangeli Obes,
Guenter Roeck, Kees Cook
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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-06-28 22:29 [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled Jeff Xu
@ 2022-06-30 15:09 ` Mickaël Salaün
2022-06-30 15:31 ` Mickaël Salaün
1 sibling, 0 replies; 17+ messages in thread
From: Mickaël Salaün @ 2022-06-30 15:09 UTC (permalink / raw)
To: Jeff Xu
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-06-28 22:29 [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled Jeff Xu
2022-06-30 15:09 ` Mickaël Salaün
@ 2022-06-30 15:31 ` Mickaël Salaün
2022-07-05 21:49 ` Jeff Xu
1 sibling, 1 reply; 17+ messages in thread
From: Mickaël Salaün @ 2022-06-30 15:31 UTC (permalink / raw)
To: Jeff Xu
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-06-30 15:31 ` Mickaël Salaün
@ 2022-07-05 21:49 ` Jeff Xu
2022-07-06 23:41 ` Jeff Xu
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Jeff Xu @ 2022-07-05 21:49 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-05 21:49 ` Jeff Xu
@ 2022-07-06 23:41 ` Jeff Xu
2022-07-07 14:24 ` Mickaël Salaün
[not found] ` <CALmYWFvcSn_wks0bXo3_DUyYGtVW_MHrrO1dRoYcxY4uiB1KEA@mail.gmail.com>
2 siblings, 0 replies; 17+ messages in thread
From: Jeff Xu @ 2022-07-06 23:41 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-05 21:49 ` Jeff Xu
2022-07-06 23:41 ` Jeff Xu
@ 2022-07-07 14:24 ` Mickaël Salaün
[not found] ` <CALmYWFvcSn_wks0bXo3_DUyYGtVW_MHrrO1dRoYcxY4uiB1KEA@mail.gmail.com>
2 siblings, 0 replies; 17+ messages in thread
From: Mickaël Salaün @ 2022-07-07 14:24 UTC (permalink / raw)
To: Jeff Xu
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
[not found] ` <CALmYWFvcSn_wks0bXo3_DUyYGtVW_MHrrO1dRoYcxY4uiB1KEA@mail.gmail.com>
@ 2022-07-07 14:25 ` Mickaël Salaün
2022-07-13 23:44 ` Jeff Xu
0 siblings, 1 reply; 17+ messages in thread
From: Mickaël Salaün @ 2022-07-07 14:25 UTC (permalink / raw)
To: Jeff Xu
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-07 14:25 ` Mickaël Salaün
@ 2022-07-13 23:44 ` Jeff Xu
2022-07-14 0:30 ` Guenter Roeck
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Xu @ 2022-07-13 23:44 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
> > 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-13 23:44 ` Jeff Xu
@ 2022-07-14 0:30 ` Guenter Roeck
2022-07-14 18:36 ` Jeff Xu
0 siblings, 1 reply; 17+ messages in thread
From: Guenter Roeck @ 2022-07-14 0:30 UTC (permalink / raw)
To: Jeff Xu
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-14 0:30 ` Guenter Roeck
@ 2022-07-14 18:36 ` Jeff Xu
2022-07-14 20:39 ` Guenter Roeck
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Xu @ 2022-07-14 18:36 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
> > > 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-14 18:36 ` Jeff Xu
@ 2022-07-14 20:39 ` Guenter Roeck
2022-07-15 0:35 ` Jeff Xu
0 siblings, 1 reply; 17+ messages in thread
From: Guenter Roeck @ 2022-07-14 20:39 UTC (permalink / raw)
To: Jeff Xu
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-14 20:39 ` Guenter Roeck
@ 2022-07-15 0:35 ` Jeff Xu
2022-07-15 21:41 ` Jeff Xu
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Xu @ 2022-07-15 0:35 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
> 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-15 0:35 ` Jeff Xu
@ 2022-07-15 21:41 ` Jeff Xu
2022-07-15 22:42 ` Guenter Roeck
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Xu @ 2022-07-15 21:41 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-15 21:41 ` Jeff Xu
@ 2022-07-15 22:42 ` Guenter Roeck
2022-07-16 0:16 ` Jeff Xu
0 siblings, 1 reply; 17+ messages in thread
From: Guenter Roeck @ 2022-07-15 22:42 UTC (permalink / raw)
To: Jeff Xu
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-15 22:42 ` Guenter Roeck
@ 2022-07-16 0:16 ` Jeff Xu
2022-07-16 21:45 ` Guenter Roeck
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Xu @ 2022-07-16 0:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
> 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-16 0:16 ` Jeff Xu
@ 2022-07-16 21:45 ` Guenter Roeck
2022-07-18 21:24 ` Mickaël Salaün
0 siblings, 1 reply; 17+ messages in thread
From: Guenter Roeck @ 2022-07-16 21:45 UTC (permalink / raw)
To: Jeff Xu
Cc: Mickaël Salaün, linux-security-module,
Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled
2022-07-16 21:45 ` Guenter Roeck
@ 2022-07-18 21:24 ` Mickaël Salaün
0 siblings, 0 replies; 17+ messages in thread
From: Mickaël Salaün @ 2022-07-18 21:24 UTC (permalink / raw)
To: Guenter Roeck, Jeff Xu
Cc: linux-security-module, Jorge Lucangeli Obes, Guenter Roeck, Kees Cook
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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-07-18 21:25 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-28 22:29 [PATCH] selftests/landlock: skip ptrace_test when YAMA is enabled Jeff Xu
2022-06-30 15:09 ` Mickaël Salaün
2022-06-30 15:31 ` Mickaël Salaün
2022-07-05 21:49 ` Jeff Xu
2022-07-06 23:41 ` Jeff Xu
2022-07-07 14:24 ` Mickaël Salaün
[not found] ` <CALmYWFvcSn_wks0bXo3_DUyYGtVW_MHrrO1dRoYcxY4uiB1KEA@mail.gmail.com>
2022-07-07 14:25 ` Mickaël Salaün
2022-07-13 23:44 ` Jeff Xu
2022-07-14 0:30 ` Guenter Roeck
2022-07-14 18:36 ` Jeff Xu
2022-07-14 20:39 ` Guenter Roeck
2022-07-15 0:35 ` Jeff Xu
2022-07-15 21:41 ` Jeff Xu
2022-07-15 22:42 ` Guenter Roeck
2022-07-16 0:16 ` Jeff Xu
2022-07-16 21:45 ` Guenter Roeck
2022-07-18 21:24 ` Mickaël Salaün
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.