mbox series

[v5,00/38] LSM: Module stacking for SARA and Landlock

Message ID 50db058a-7dde-441b-a7f9-f6837fe8b69f@schaufler-ca.com (mailing list archive)
Headers show
Series LSM: Module stacking for SARA and Landlock | expand

Message

Casey Schaufler Nov. 26, 2018, 11:22 p.m. UTC
v5: Include Kees Cook's rework of the lsm command
    line interface. Stacking is not conditional.
v4: Finer granularity in the patches and other
    cleanups suggested by Kees Cook.
    Removed dead code created by the removal of SELinux
    credential blob poisoning.
v3: Add ipc blob for SARA and task blob for Landlock.
    Removing the SELinux cred blob pointer poisoning
    results selinux_is_enabled() being unused, so it and
    all it's overhead has been removed.
    Broke up the cred infrastructure patch.
v2: Reduce the patchset to what is required to support
    the proposed SARA and LandLock security modules

The SARA security module is intended to be used
in conjunction with other security modules. It requires
state to be maintained for the credential, which
in turn requires a mechanism for sharing the credential
security blob. It also uses the ipc security blob. The
module also requires mechanism for user space manipulation
of the credential information, hence an additional
subdirectory in /proc/.../attr.

The LandLock security module provides user configurable
policy in the secmark mechanism. It requires data in
the credential, file, inode and task security blobs. For
this to be used along side the existing "major" security
modules mechanism for sharing these blobs are provided.

A side effect of providing sharing of the crendential
security blob is that the TOMOYO module can be used at
the same time as the other "major" modules. The "security="
option works as before. A new "lsm=" option allows the
order of module execution to be supplied at boot time.

The security module stacking issues around networking and
IPC are not addressed here as they are beyond what is
required for TOMOYO, SARA and LandLock.

git://github.com/cschaufler/lsm-stacking.git#blob-4.20-rc2

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
 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(-)

Comments

Kees Cook Dec. 5, 2018, 12:31 a.m. UTC | #1
On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> v5: Include Kees Cook's rework of the lsm command
>     line interface. Stacking is not conditional.

Can you resend this series with corrected "From:" lines in the body, etc?

Beyond that, I obviously like it. James, what's needed for this to move forward?
Casey Schaufler Dec. 5, 2018, 2:37 a.m. UTC | #2
On 12/4/2018 4:31 PM, Kees Cook wrote:
> On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> v5: Include Kees Cook's rework of the lsm command
>>     line interface. Stacking is not conditional.
> Can you resend this series with corrected "From:" lines in the body, etc?

Yes, I can. I was hoping to hear something other than crickets.

> Beyond that, I obviously like it. James, what's needed for this to move forward?

Agreed.
John Johansen Dec. 5, 2018, 2:52 a.m. UTC | #3
On 12/4/18 6:37 PM, Casey Schaufler wrote:
> On 12/4/2018 4:31 PM, Kees Cook wrote:
>> On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> v5: Include Kees Cook's rework of the lsm command
>>>     line interface. Stacking is not conditional.
>> Can you resend this series with corrected "From:" lines in the body, etc?
> 
> Yes, I can. I was hoping to hear something other than crickets.
> 
I am trying to get to it, its the next thing on my list. So hopefully this week


>> Beyond that, I obviously like it. James, what's needed for this to move forward?
> 
> Agreed.
>
James Morris Dec. 11, 2018, 6:57 p.m. UTC | #4
On Tue, 4 Dec 2018, Kees Cook wrote:

> On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > v5: Include Kees Cook's rework of the lsm command
> >     line interface. Stacking is not conditional.
> 
> Can you resend this series with corrected "From:" lines in the body, etc?
> 
> Beyond that, I obviously like it. James, what's needed for this to move forward?

If there are no outstanding issues, I plan to merge this for 4.21.
Kees Cook Dec. 11, 2018, 9:19 p.m. UTC | #5
On Tue, Dec 11, 2018 at 10:57 AM James Morris <jmorris@namei.org> wrote:
>
> On Tue, 4 Dec 2018, Kees Cook wrote:
>
> > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > v5: Include Kees Cook's rework of the lsm command
> > >     line interface. Stacking is not conditional.
> >
> > Can you resend this series with corrected "From:" lines in the body, etc?
> >
> > Beyond that, I obviously like it. James, what's needed for this to move forward?
>
> If there are no outstanding issues, I plan to merge this for 4.21.

Yeah, it looks good to me. (Excepting getting the authorship sorted.)

Thanks!
Kees Cook Jan. 8, 2019, 1:29 a.m. UTC | #6
On Tue, Dec 11, 2018 at 1:19 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Tue, Dec 11, 2018 at 10:57 AM James Morris <jmorris@namei.org> wrote:
> >
> > On Tue, 4 Dec 2018, Kees Cook wrote:
> >
> > > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > > v5: Include Kees Cook's rework of the lsm command
> > > >     line interface. Stacking is not conditional.
> > >
> > > Can you resend this series with corrected "From:" lines in the body, etc?
> > >
> > > Beyond that, I obviously like it. James, what's needed for this to move forward?
> >
> > If there are no outstanding issues, I plan to merge this for 4.21.
>
> Yeah, it looks good to me. (Excepting getting the authorship sorted.)

I didn't see this actually get merged? Was there something that needed
fixing? Should I send you a direct pull request for v5.1?
James Morris Jan. 8, 2019, 9:05 p.m. UTC | #7
On Mon, 7 Jan 2019, Kees Cook wrote:

> On Tue, Dec 11, 2018 at 1:19 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Tue, Dec 11, 2018 at 10:57 AM James Morris <jmorris@namei.org> wrote:
> > >
> > > On Tue, 4 Dec 2018, Kees Cook wrote:
> > >
> > > > On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > > > v5: Include Kees Cook's rework of the lsm command
> > > > >     line interface. Stacking is not conditional.
> > > >
> > > > Can you resend this series with corrected "From:" lines in the body, etc?
> > > >
> > > > Beyond that, I obviously like it. James, what's needed for this to move forward?
> > >
> > > If there are no outstanding issues, I plan to merge this for 4.21.
> >
> > Yeah, it looks good to me. (Excepting getting the authorship sorted.)
> 
> I didn't see this actually get merged? Was there something that needed
> fixing? Should I send you a direct pull request for v5.1?

Yep, please send a new pull request.
Casey Schaufler Jan. 8, 2019, 9:37 p.m. UTC | #8
On 1/8/2019 1:05 PM, James Morris wrote:
> On Mon, 7 Jan 2019, Kees Cook wrote:
>
>> On Tue, Dec 11, 2018 at 1:19 PM Kees Cook <keescook@chromium.org> wrote:
>>> On Tue, Dec 11, 2018 at 10:57 AM James Morris <jmorris@namei.org> wrote:
>>>> On Tue, 4 Dec 2018, Kees Cook wrote:
>>>>
>>>>> On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> v5: Include Kees Cook's rework of the lsm command
>>>>>>     line interface. Stacking is not conditional.
>>>>> Can you resend this series with corrected "From:" lines in the body, etc?
>>>>>
>>>>> Beyond that, I obviously like it. James, what's needed for this to move forward?
>>>> If there are no outstanding issues, I plan to merge this for 4.21.
>>> Yeah, it looks good to me. (Excepting getting the authorship sorted.)
>> I didn't see this actually get merged? Was there something that needed
>> fixing? Should I send you a direct pull request for v5.1?
> Yep, please send a new pull request.

Do you want it as is or rebased on 5.0-rc1?
Kees Cook Jan. 8, 2019, 9:42 p.m. UTC | #9
On Tue, Jan 8, 2019 at 1:37 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 1/8/2019 1:05 PM, James Morris wrote:
> > On Mon, 7 Jan 2019, Kees Cook wrote:
> >
> >> On Tue, Dec 11, 2018 at 1:19 PM Kees Cook <keescook@chromium.org> wrote:
> >>> On Tue, Dec 11, 2018 at 10:57 AM James Morris <jmorris@namei.org> wrote:
> >>>> On Tue, 4 Dec 2018, Kees Cook wrote:
> >>>>
> >>>>> On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>>> v5: Include Kees Cook's rework of the lsm command
> >>>>>>     line interface. Stacking is not conditional.
> >>>>> Can you resend this series with corrected "From:" lines in the body, etc?
> >>>>>
> >>>>> Beyond that, I obviously like it. James, what's needed for this to move forward?
> >>>> If there are no outstanding issues, I plan to merge this for 4.21.
> >>> Yeah, it looks good to me. (Excepting getting the authorship sorted.)
> >> I didn't see this actually get merged? Was there something that needed
> >> fixing? Should I send you a direct pull request for v5.1?
> > Yep, please send a new pull request.
>
> Do you want it as is or rebased on 5.0-rc1?

I've rebased to 5.0-rc1, did some light (re)testing, and sent a pull request...
Casey Schaufler Jan. 8, 2019, 11:05 p.m. UTC | #10
On 1/8/2019 1:42 PM, Kees Cook wrote:
> On Tue, Jan 8, 2019 at 1:37 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 1/8/2019 1:05 PM, James Morris wrote:
>>> On Mon, 7 Jan 2019, Kees Cook wrote:
>>>
>>>> On Tue, Dec 11, 2018 at 1:19 PM Kees Cook <keescook@chromium.org> wrote:
>>>>> On Tue, Dec 11, 2018 at 10:57 AM James Morris <jmorris@namei.org> wrote:
>>>>>> On Tue, 4 Dec 2018, Kees Cook wrote:
>>>>>>
>>>>>>> On Mon, Nov 26, 2018 at 3:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>>> v5: Include Kees Cook's rework of the lsm command
>>>>>>>>     line interface. Stacking is not conditional.
>>>>>>> Can you resend this series with corrected "From:" lines in the body, etc?
>>>>>>>
>>>>>>> Beyond that, I obviously like it. James, what's needed for this to move forward?
>>>>>> If there are no outstanding issues, I plan to merge this for 4.21.
>>>>> Yeah, it looks good to me. (Excepting getting the authorship sorted.)
>>>> I didn't see this actually get merged? Was there something that needed
>>>> fixing? Should I send you a direct pull request for v5.1?
>>> Yep, please send a new pull request.
>> Do you want it as is or rebased on 5.0-rc1?
> I've rebased to 5.0-rc1, did some light (re)testing, and sent a pull request...

Thank you.