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)
----------------------------------------------------------------
LSM: Module stacking for SARA and Landlock
The combined series of LSM refactoring and addition of blob-sharing for
SARA and Landlock.
----------------------------------------------------------------
Casey Schaufler (19):
LSM: Add all exclusive LSMs to ordered initialization
procfs: add smack subdir to attrs
Smack: Abstract use of cred security blob
SELinux: Abstract use of cred security blob
SELinux: Remove cred security blob poisoning
SELinux: Remove unused selinux_is_enabled
AppArmor: Abstract use of cred security blob
TOMOYO: Abstract use of cred security blob
Infrastructure management of the cred security blob
SELinux: Abstract use of file security blob
Smack: Abstract use of file security blob
LSM: Infrastructure management of the file security
SELinux: Abstract use of inode security blob
Smack: Abstract use of inode security blob
LSM: Infrastructure management of the inode security
LSM: Infrastructure management of the task security
SELinux: Abstract use of ipc security blobs
Smack: Abstract use of ipc security blobs
LSM: Infrastructure management of the ipc security blob
Kees Cook (19):
LSM: Introduce LSM_FLAG_LEGACY_MAJOR
LSM: Provide separate ordered initialization
LSM: Plumb visibility into optional "enabled" state
LSM: Lift LSM selection out of individual LSMs
LSM: Build ordered list of LSMs to initialize
LSM: Introduce CONFIG_LSM
LSM: Introduce "lsm=" for boottime LSM selection
LSM: Tie enabling logic to presence in ordered list
LSM: Prepare for reorganizing "security=" logic
LSM: Refactor "security=" in terms of enable/disable
LSM: Separate idea of "major" LSM from "exclusive" LSM
apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUE
selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE
LSM: Split LSM preparation from initialization
LoadPin: Initialize as ordered LSM
Yama: Initialize as ordered LSM
LSM: Introduce enum lsm_order
capability: Initialize as LSM_ORDER_FIRST
TOMOYO: Update LSM flags to no longer be exclusive
Documentation/admin-guide/LSM/index.rst | 13 +-
Documentation/admin-guide/kernel-parameters.txt | 4 +
fs/proc/base.c | 64 ++-
fs/proc/internal.h | 1 +
include/linux/cred.h | 1 -
include/linux/lsm_hooks.h | 40 +-
include/linux/security.h | 15 +-
include/linux/selinux.h | 35 --
kernel/cred.c | 13 -
security/Kconfig | 41 +-
security/apparmor/Kconfig | 16 -
security/apparmor/domain.c | 2 +-
security/apparmor/include/cred.h | 16 +-
security/apparmor/include/file.h | 5 +-
security/apparmor/include/lib.h | 4 +
security/apparmor/include/task.h | 18 +-
security/apparmor/lsm.c | 65 ++-
security/apparmor/task.c | 6 +-
security/commoncap.c | 9 +-
security/loadpin/loadpin.c | 8 +-
security/security.c | 635 +++++++++++++++++++++---
security/selinux/Kconfig | 15 -
security/selinux/Makefile | 2 +-
security/selinux/exports.c | 23 -
security/selinux/hooks.c | 345 ++++---------
security/selinux/include/audit.h | 3 -
security/selinux/include/objsec.h | 38 +-
security/selinux/selinuxfs.c | 4 +-
security/selinux/ss/services.c | 1 -
security/selinux/xfrm.c | 4 +-
security/smack/smack.h | 44 +-
security/smack/smack_access.c | 4 +-
security/smack/smack_lsm.c | 316 ++++--------
security/smack/smackfs.c | 18 +-
security/tomoyo/common.h | 22 +-
security/tomoyo/domain.c | 4 +-
security/tomoyo/securityfs_if.c | 15 +-
security/tomoyo/tomoyo.c | 49 +-
security/yama/yama_lsm.c | 8 +-
39 files changed, 1133 insertions(+), 793 deletions(-)
delete mode 100644 include/linux/selinux.h
delete mode 100644 security/selinux/exports.c
--
Kees Cook
On Thu, Jan 10, 2019 at 3:34 PM James Morris <[email protected]> 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
--
paul moore
http://www.paul-moore.com
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!
--
James Morris
<[email protected]>
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.
--
James Morris
<[email protected]>
On Thu, Jan 10, 2019 at 5:00 PM James Morris <[email protected]> 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.
--
paul moore
http://www.paul-moore.com
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
<[email protected]> 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?
--
Kees Cook
On Thu, 10 Jan 2019, Paul Moore wrote:
> On Thu, Jan 10, 2019 at 5:00 PM James Morris <[email protected]> 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's f27 with a custom kernel config (attached).
--
James Morris
<[email protected]>