Message ID | 20190108213504.GA32901@beast (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] blob-stacking updates for security-next | expand |
On Tue, 8 Jan 2019, Kees Cook wrote: > Hi James, > > Please pull these blob-stacking changes for security-next. > > Thanks! Merged to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general and next-testing. This passes the SELinux testsuite on my system, and I'm now running this on my laptop. Please test!
On Thu, Jan 10, 2019 at 3:34 PM James Morris <jmorris@namei.org> wrote: > On Tue, 8 Jan 2019, Kees Cook wrote: > > Hi James, > > > > Please pull these blob-stacking changes for security-next. > > > > Thanks! > > Merged to > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general > and next-testing. > > This passes the SELinux testsuite on my system, and I'm now running this > on my laptop. > > Please test! While not exhaustive by any stretch of the imagination, you might want to throw the audit-testsuite at it too. * https://github.com/linux-audit/audit-testsuite
On Thu, 10 Jan 2019, Paul Moore wrote: > > Please test! > > While not exhaustive by any stretch of the imagination, you might want > to throw the audit-testsuite at it too. > > * https://github.com/linux-audit/audit-testsuite I'm seeing lots of failures with vanilla -rc1, probably much to do with my kconfig: Test Summary Report ------------------- exec_name/test (Wstat: 0 Tests: 5 Failed: 2) Failed tests: 4-5 filter_exclude/test (Wstat: 0 Tests: 21 Failed: 2) Failed tests: 20-21 lost_reset/test (Wstat: 0 Tests: 5 Failed: 2) Failed tests: 4-5 netfilter_pkt/test (Wstat: 0 Tests: 13 Failed: 13) Failed tests: 1-13 syscalls_file/test (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 syscall_module/test (Wstat: 0 Tests: 6 Failed: 4) Failed tests: 2-3, 5-6 syscall_socketcall/test (Wstat: 0 Tests: 3 Failed: 3) Failed tests: 1-3 user_msg/test (Wstat: 0 Tests: 2 Failed: 2) Failed tests: 1-2 Files=14, Tests=80, 16 wallclock secs ( 0.04 usr 0.02 sys + 2.21 cusr 0.60 csys = 2.87 CPU) Result: FAIL Failed 8/14 test programs. 30/80 subtests failed. It would be good to have a defconfig to merge like with the SELinux testsuite.
On Thu, Jan 10, 2019 at 5:00 PM James Morris <jmorris@namei.org> wrote: > On Thu, 10 Jan 2019, Paul Moore wrote: > > > > Please test! > > > > While not exhaustive by any stretch of the imagination, you might want > > to throw the audit-testsuite at it too. > > > > * https://github.com/linux-audit/audit-testsuite > > I'm seeing lots of failures with vanilla -rc1, probably much to do with my > kconfig: FWIW, v5.0-rc1 passes on my test system. What userspace/distro are you running? > It would be good to have a defconfig to merge like with the SELinux > testsuite. Yeah, the audit-testsuite is still pretty rough, there are lots of things it needs.
On 2019/01/09 6:35, Kees Cook wrote: > Hi James, > > Please pull these blob-stacking changes for security-next. > > Thanks! > > -Kees > > The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: > > Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/blob-stacking-security-next > > for you to fetch changes up to a5e2fe7ede1268d2f80fe49ca1f717d0e3750995: > > TOMOYO: Update LSM flags to no longer be exclusive (2019-01-08 13:18:45 -0800) > And syzbot already found a bug. This is occurring immediately after memory allocation failure for cred object. We need to be prepared for free() function being called when alloc() function failed. [ 59.992498][ T8010] FAULT_INJECTION: forcing a failure. [ 59.992498][ T8010] name failslab, interval 1, probability 0, space 0, times 1 [ 60.005214][ T8010] CPU: 0 PID: 8010 Comm: syz-executor178 Not tainted 5.0.0-rc1-next-20190111 #10 [ 60.014337][ T8010] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 60.024383][ T8010] Call Trace: [ 60.027657][ T8010] dump_stack+0x1db/0x2d0 [ 60.063731][ T8010] should_fail.cold+0xa/0x14 [ 60.089894][ T8010] __should_failslab+0x121/0x190 [ 60.094810][ T8010] should_failslab+0x9/0x14 [ 60.099411][ T8010] __kmalloc+0x2dc/0x740 [ 60.124293][ T8010] security_prepare_creds+0x123/0x190 [ 60.129644][ T8010] prepare_creds+0x3c4/0x510 [ 60.149852][ T8010] __x64_sys_capset+0x58c/0x9b0 [ 60.185347][ T8010] do_syscall_64+0x1a3/0x800 [ 60.206747][ T8010] entry_SYSCALL_64_after_hwframe+0x49/0xbe
On 1/11/2019 2:38 AM, Tetsuo Handa wrote: > On 2019/01/09 6:35, Kees Cook wrote: >> Hi James, >> >> Please pull these blob-stacking changes for security-next. >> >> Thanks! >> >> -Kees >> >> The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: >> >> Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) >> >> are available in the Git repository at: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/blob-stacking-security-next >> >> for you to fetch changes up to a5e2fe7ede1268d2f80fe49ca1f717d0e3750995: >> >> TOMOYO: Update LSM flags to no longer be exclusive (2019-01-08 13:18:45 -0800) >> > And syzbot already found a bug. > This is occurring immediately after memory allocation failure for cred object. > We need to be prepared for free() function being called when alloc() function failed. > > [ 59.992498][ T8010] FAULT_INJECTION: forcing a failure. > [ 59.992498][ T8010] name failslab, interval 1, probability 0, space 0, times 1 > [ 60.005214][ T8010] CPU: 0 PID: 8010 Comm: syz-executor178 Not tainted 5.0.0-rc1-next-20190111 #10 > [ 60.014337][ T8010] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > [ 60.024383][ T8010] Call Trace: > [ 60.027657][ T8010] dump_stack+0x1db/0x2d0 > [ 60.063731][ T8010] should_fail.cold+0xa/0x14 > [ 60.089894][ T8010] __should_failslab+0x121/0x190 > [ 60.094810][ T8010] should_failslab+0x9/0x14 > [ 60.099411][ T8010] __kmalloc+0x2dc/0x740 > [ 60.124293][ T8010] security_prepare_creds+0x123/0x190 > [ 60.129644][ T8010] prepare_creds+0x3c4/0x510 > [ 60.149852][ T8010] __x64_sys_capset+0x58c/0x9b0 > [ 60.185347][ T8010] do_syscall_64+0x1a3/0x800 > [ 60.206747][ T8010] entry_SYSCALL_64_after_hwframe+0x49/0xbe I'm staring at the code and trying to see what this is telling me. There is a failure check immediately after the allocation. If any of the modules fail in their hooks, the whole thing is freed.
On Fri, Jan 11, 2019 at 2:38 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > On 2019/01/09 6:35, Kees Cook wrote: > > Hi James, > > > > Please pull these blob-stacking changes for security-next. > > > > Thanks! > > > > -Kees > > > > The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: > > > > Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) > > > > are available in the Git repository at: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/blob-stacking-security-next > > > > for you to fetch changes up to a5e2fe7ede1268d2f80fe49ca1f717d0e3750995: > > > > TOMOYO: Update LSM flags to no longer be exclusive (2019-01-08 13:18:45 -0800) > > > > And syzbot already found a bug. > This is occurring immediately after memory allocation failure for cred object. > We need to be prepared for free() function being called when alloc() function failed. > > [ 59.992498][ T8010] FAULT_INJECTION: forcing a failure. > [ 59.992498][ T8010] name failslab, interval 1, probability 0, space 0, times 1 > [ 60.005214][ T8010] CPU: 0 PID: 8010 Comm: syz-executor178 Not tainted 5.0.0-rc1-next-20190111 #10 > [ 60.014337][ T8010] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > [ 60.024383][ T8010] Call Trace: > [ 60.027657][ T8010] dump_stack+0x1db/0x2d0 > [ 60.063731][ T8010] should_fail.cold+0xa/0x14 > [ 60.089894][ T8010] __should_failslab+0x121/0x190 > [ 60.094810][ T8010] should_failslab+0x9/0x14 > [ 60.099411][ T8010] __kmalloc+0x2dc/0x740 > [ 60.124293][ T8010] security_prepare_creds+0x123/0x190 > [ 60.129644][ T8010] prepare_creds+0x3c4/0x510 > [ 60.149852][ T8010] __x64_sys_capset+0x58c/0x9b0 > [ 60.185347][ T8010] do_syscall_64+0x1a3/0x800 > [ 60.206747][ T8010] entry_SYSCALL_64_after_hwframe+0x49/0xbe Are there more details on this crash report?