mbox series

[GIT,PULL] blob-stacking updates for security-next

Message ID 20190108213504.GA32901@beast (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] blob-stacking updates for security-next | expand

Pull-request

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/blob-stacking-security-next

Message

Kees Cook Jan. 8, 2019, 9:35 p.m. UTC
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

Comments

James Morris Jan. 10, 2019, 8:34 p.m. UTC | #1
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!
Paul Moore Jan. 10, 2019, 9:21 p.m. UTC | #2
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
James Morris Jan. 10, 2019, 10 p.m. UTC | #3
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.
Paul Moore Jan. 10, 2019, 10:39 p.m. UTC | #4
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.
Tetsuo Handa Jan. 11, 2019, 10:38 a.m. UTC | #5
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
Casey Schaufler Jan. 11, 2019, 5:29 p.m. UTC | #6
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.
Kees Cook Jan. 11, 2019, 5:44 p.m. UTC | #7
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?