Thank you. The LSM stacking seems to be working as expected.
But this one should not be considered as a bug.
If something went wrong before loading access control rules,
it is pointless to continue. Thus, stopping with kernel panic.
If this path is trivially triggered enough to prevent testing, syzbot can
load access control rules from /etc/tomoyo/ directory of the filesystem
image and make tomoyo_policy_loaded = true by executing /sbin/init .
Hmm, maybe we need to think about automated testing environments where
neither built-in access control rules nor run-time access control rules
can be provided ... ?
#syz invalid
Thank you. The LSM stacking seems to be working as expected.
But this one should not be considered as a bug.
If something went wrong before loading access control rules,
it is pointless to continue. Thus, stopping with kernel panic.
Hi Tetsuo,
What misconfiguration you mean?
If this path is trivially triggered enough to prevent testing, syzbot can
load access control rules from /etc/tomoyo/ directory of the filesystem
image and make tomoyo_policy_loaded = true by executing /sbin/init .
Hmm, maybe we need to think about automated testing environments where
neither built-in access control rules nor run-time access control rules
can be provided ... ?
#syz invalid
--
You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/8d94063c-e10c-c470-8ce0-1f86c517b1b4%40i-love.sakura.ne.jp.
For more options, visit https://groups.google.com/d/optout.
Thank you. The LSM stacking seems to be working as expected.
But this one should not be considered as a bug.
If something went wrong before loading access control rules,
it is pointless to continue. Thus, stopping with kernel panic.
Hi Tetsuo,
What misconfiguration you mean?
To use security modules, access control rules need to be loaded. Regarding
TOMOYO, access control rules can be loaded from the kernel itself (built-in)
and/or from /etc/tomoyo/ directory via /sbin/tomoyo-init (run-time).
Since the kernel is built without built-in policy and /sbin/tomoyo-init does
not exist, memory allocation failure is handled as a fatal problem.
But if syzbot cannot test other paths due to hitting this path, we need to somehow
avoid panic(). Can you add tomoyo-tools package into your rootfs images? It is
explained at https://tomoyo.osdn.jp/2.6/chapter-3.html .
On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
[off-list ref] wrote:
On 2019/02/28 15:51, Dmitry Vyukov wrote:
quoted
On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
quoted
Thank you. The LSM stacking seems to be working as expected.
But this one should not be considered as a bug.
If something went wrong before loading access control rules,
it is pointless to continue. Thus, stopping with kernel panic.
Hi Tetsuo,
What misconfiguration you mean?
To use security modules, access control rules need to be loaded. Regarding
TOMOYO, access control rules can be loaded from the kernel itself (built-in)
and/or from /etc/tomoyo/ directory via /sbin/tomoyo-init (run-time).
Since the kernel is built without built-in policy and /sbin/tomoyo-init does
not exist, memory allocation failure is handled as a fatal problem.
But if syzbot cannot test other paths due to hitting this path, we need to somehow
avoid panic(). Can you add tomoyo-tools package into your rootfs images? It is
explained at https://tomoyo.osdn.jp/2.6/chapter-3.html .
Is installing the package everything that needs to be done? It's not a
standard package, right?
What does it do? Frequently there is like 3 DVD's of some software,
but everything that needs to be done is a single system call? What
exactly from kernel perspective we need to do?
On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
[off-list ref] wrote:
quoted
On 2019/02/28 15:51, Dmitry Vyukov wrote:
quoted
On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
quoted
Thank you. The LSM stacking seems to be working as expected.
But this one should not be considered as a bug.
If something went wrong before loading access control rules,
it is pointless to continue. Thus, stopping with kernel panic.
Hi Tetsuo,
What misconfiguration you mean?
To use security modules, access control rules need to be loaded. Regarding
TOMOYO, access control rules can be loaded from the kernel itself (built-in)
and/or from /etc/tomoyo/ directory via /sbin/tomoyo-init (run-time).
Since the kernel is built without built-in policy and /sbin/tomoyo-init does
not exist, memory allocation failure is handled as a fatal problem.
But if syzbot cannot test other paths due to hitting this path, we need to somehow
avoid panic(). Can you add tomoyo-tools package into your rootfs images? It is
explained at https://tomoyo.osdn.jp/2.6/chapter-3.html .
Is installing the package everything that needs to be done? It's not a
standard package, right?
What does it do? Frequently there is like 3 DVD's of some software,
but everything that needs to be done is a single system call? What
exactly from kernel perspective we need to do?
From kernel perspective, just building the kernels with
CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER=y after doing
echo 'PROFILE_VERSION=20150505' > security/tomoyo/policy/profile.conf
echo '0-CONFIG={ mode=learning grant_log=no reject_log=yes }' >> security/tomoyo/policy/profile.conf
from the kernel source tree is needed.
But the problem is that since syzbot is automated, there is no chance to
edit the content of security/tomoyo/policy/ directory when building the
kernels. Therefore, I expected that we can add tomoyo-tools package and
/etc/tomoyo/ directory generated by executing /usr/lib/tomoyo/init_policy
into the rootfs images. tomoyo-tools package is easy to install because of
little dependency (e.g. glibc and ncurses).
Maybe disabling panic() if CONFIG_FAULT_INJECTION=y is simpler...
@@ -24,7 +24,7 @@ void tomoyo_warn_oom(const char *function)pr_warn("ERROR: Out of memory at %s.\n",function);tomoyo_last_pid=pid;}-if(!tomoyo_policy_loaded)+if(!IS_ENABLED(CONFIG_FAULT_INJECTION)&&!tomoyo_policy_loaded)panic("MAC Initialization failed.\n");}
But the problem is that since syzbot is automated, there is no chance to
edit the content of security/tomoyo/policy/ directory when building the
kernels.
Thinking again, I realized that it would be possible to automatically
generate the content of security/tomoyo/policy/ directory specialized
for fuzzing tests using some kernel config option, for syzbot can enable
some kernel config option. I'll try it.