Hi Linus,
Please pull these general updates for the security subsystem for v4.21.
The main changes here are Paul Gortmaker's removal of unneccesary module.h
infrastructure.
The following changes since commit 7566ec393f4161572ba6f11ad5171fd5d59b0fbd:
Linux 4.20-rc7 (2018-12-16 15:46:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
for you to fetch changes up to b49d564344f773d8afee982153c8493e5f2eaf38:
security: integrity: partial revert of make ima_main explicitly non-modular (2018-12-20 09:59:12 -0800)
----------------------------------------------------------------
James Morris (2):
Merge tag 'v4.20-rc2' into next-general
Merge tag 'v4.20-rc7' into next-general
Paul Gortmaker (6):
security: integrity: make ima_main explicitly non-modular
keys: remove needless modular infrastructure from ecryptfs_format
security: integrity: make evm_main explicitly non-modular
security: audit and remove any unnecessary uses of module.h
security: fs: make inode explicitly non-modular
security: integrity: partial revert of make ima_main explicitly non-modular
Yangtao Li (1):
tomoyo: fix small typo
security/apparmor/apparmorfs.c | 2 +-
security/commoncap.c | 1 -
security/inode.c | 6 ++----
security/integrity/evm/evm_crypto.c | 2 +-
security/integrity/evm/evm_main.c | 5 +----
security/integrity/evm/evm_posix_acl.c | 1 -
security/integrity/evm/evm_secfs.c | 2 +-
security/integrity/iint.c | 2 +-
security/integrity/ima/ima_api.c | 1 -
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/ima_fs.c | 2 +-
security/integrity/ima/ima_init.c | 2 +-
security/integrity/ima/ima_main.c | 5 ++---
security/integrity/ima/ima_policy.c | 2 +-
security/integrity/ima/ima_queue.c | 1 -
security/keys/encrypted-keys/ecryptfs_format.c | 5 ++---
security/keys/encrypted-keys/masterkey_trusted.c | 1 -
security/keys/gc.c | 1 -
security/keys/key.c | 2 +-
security/keys/keyctl.c | 1 -
security/keys/keyring.c | 2 +-
security/keys/permission.c | 2 +-
security/keys/proc.c | 1 -
security/keys/process_keys.c | 1 -
security/keys/request_key.c | 2 +-
security/keys/request_key_auth.c | 1 -
security/keys/user_defined.c | 2 +-
security/security.c | 2 +-
security/tomoyo/util.c | 2 +-
29 files changed, 22 insertions(+), 39 deletions(-)
On Mon, Dec 24, 2018 at 11:55 AM James Morris <[email protected]> wrote:
>
> The main changes here are Paul Gortmaker's removal of unneccesary module.h
> infrastructure.
I will point out a merge with a horrible commit message:
"Sync to Linux 4.20-rc2 for downstream developers"
that tells nobody anything.
Why was that merge done? If you can't explain the merge, just don't do
the merge.
Linus
The pull request you sent on Tue, 25 Dec 2018 06:55:00 +1100 (AEDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3f03bf93947fa2a2b84fac56e93c65d4fffed7f1
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
On Fri, Dec 28, 2018 at 8:09 PM James Morris <[email protected]> wrote:
>
> Yep, I understand what you mean. I can't find the discussion from several
> years ago, but developers asked to be able to work with more current
> kernels, and I recall you saying that if you want to do this, merge to a
> specific -rc tag at least.
If people really want it, maybe the merge can state that explicit
thing, as it is I'm trying to push back on empty merges that don't
explain why they even exist.
Linus
On Thu, 27 Dec 2018, Linus Torvalds wrote:
> On Mon, Dec 24, 2018 at 11:55 AM James Morris <[email protected]> wrote:
> >
> > The main changes here are Paul Gortmaker's removal of unneccesary module.h
> > infrastructure.
>
> I will point out a merge with a horrible commit message:
>
> "Sync to Linux 4.20-rc2 for downstream developers"
>
> that tells nobody anything.
>
> Why was that merge done? If you can't explain the merge, just don't do
> the merge.
I do this every development cycle, after requests from security subsystem
maintainers to sync to -rc kernels.
--
James Morris
<[email protected]>
On Fri, Dec 28, 2018 at 7:11 PM James Morris <[email protected]> wrote:
>
> I do this every development cycle, after requests from security subsystem
> maintainers to sync to -rc kernels.
Why?
A merge should have a *reason*.
Linus
On Fri, 28 Dec 2018, Linus Torvalds wrote:
> On Fri, Dec 28, 2018 at 7:11 PM James Morris <[email protected]> wrote:
> >
> > I do this every development cycle, after requests from security subsystem
> > maintainers to sync to -rc kernels.
>
> Why?
>
> A merge should have a *reason*.
Yep, I understand what you mean. I can't find the discussion from several
years ago, but developers asked to be able to work with more current
kernels, and I recall you saying that if you want to do this, merge to a
specific -rc tag at least.
I'm not personally fussed either way, and if anyone cc'd has an opinion,
please comment. Otherwise, I'll go back to merging to Linus only as
necessary.
--
James Morris
<[email protected]>
On 12/28/2018 8:15 PM, Linus Torvalds wrote:
> On Fri, Dec 28, 2018 at 8:09 PM James Morris <[email protected]> wrote:
>> Yep, I understand what you mean. I can't find the discussion from several
>> years ago, but developers asked to be able to work with more current
>> kernels, and I recall you saying that if you want to do this, merge to a
>> specific -rc tag at least.
> If people really want it, maybe the merge can state that explicit
> thing, as it is I'm trying to push back on empty merges that don't
> explain why they even exist.
>
> Linus
The security tree tends to get changed from multiple directions,
most of which aren't based out of the security sub-system. The mount
rework from David is an excellent example. It gets hit just about
any time there's a significant VFS or networking change. Keeping
it current has helped find issues much earlier in the process.
On Sat, 2018-12-29 at 10:34 -0800, Casey Schaufler wrote:
> On 12/28/2018 8:15 PM, Linus Torvalds wrote:
> > On Fri, Dec 28, 2018 at 8:09 PM James Morris <[email protected]> wrote:
> >> Yep, I understand what you mean. I can't find the discussion from several
> >> years ago, but developers asked to be able to work with more current
> >> kernels, and I recall you saying that if you want to do this, merge to a
> >> specific -rc tag at least.
> > If people really want it, maybe the merge can state that explicit
> > thing, as it is I'm trying to push back on empty merges that don't
> > explain why they even exist.
> >
> > Linus
>
> The security tree tends to get changed from multiple directions,
> most of which aren't based out of the security sub-system. The mount
> rework from David is an excellent example. It gets hit just about
> any time there's a significant VFS or networking change. Keeping
> it current has helped find issues much earlier in the process.
Agreed, the security subsystem is different than other subsystems. In
addition to VFS changes, are key changes. Changes in other subsystems
do affect the LSMs/integrity.
Included in this open window are a number of LSM changes, which were
not posted on the LSM mailing list and are not being upstreamed via
the LSMs.
Mimi
On Sat, 29 Dec 2018, Mimi Zohar wrote:
> On Sat, 2018-12-29 at 10:34 -0800, Casey Schaufler wrote:
> > On 12/28/2018 8:15 PM, Linus Torvalds wrote:
> > > On Fri, Dec 28, 2018 at 8:09 PM James Morris <[email protected]> wrote:
> > >> Yep, I understand what you mean. I can't find the discussion from several
> > >> years ago, but developers asked to be able to work with more current
> > >> kernels, and I recall you saying that if you want to do this, merge to a
> > >> specific -rc tag at least.
> > > If people really want it, maybe the merge can state that explicit
> > > thing, as it is I'm trying to push back on empty merges that don't
> > > explain why they even exist.
> > >
> > > Linus
> >
> > The security tree tends to get changed from multiple directions,
> > most of which aren't based out of the security sub-system. The mount
> > rework from David is an excellent example. It gets hit just about
> > any time there's a significant VFS or networking change. Keeping
> > it current has helped find issues much earlier in the process.
>
> Agreed, the security subsystem is different than other subsystems. In
> addition to VFS changes, are key changes. Changes in other subsystems
> do affect the LSMs/integrity.
Yep, I agree that if we get too far behind Linus then changes in things
like overlayfs (a recent example) may subtly break LSM and we don't see
this in the actual security development trees. In theory these things
will be picked up in next testing, although not everything spends long
enough in next.
And it's not necessarily changes to security code, it can be apparently
unrelated changes in the VFS or other subsystems which impact security
semantics.
> Included in this open window are a number of LSM changes, which were
> not posted on the LSM mailing list and are not being upstreamed via
> the LSMs.
If you see changes doing this, please call them out. Any changes to LSM
need to be cc'd at least to the LSM mailing list.
--
James Morris
<[email protected]>
On Tue, 2019-01-08 at 08:45 +1100, James Morris wrote:
> > Included in this open window are a number of LSM changes, which were
> > not posted on the LSM mailing list and are not being upstreamed via
> > the LSMs.
>
> If you see changes doing this, please call them out. Any changes to LSM
> need to be cc'd at least to the LSM mailing list.
Sure. I'm referring to Al's match_token() and other changes, which I
only learned about when Linus reviewed Eric Bigger's patch "KEYS: fix
parsing invalid pkey info string".
169d68efb03b selinux: switch away from match_token()
c3300aaf95fb smack: get rid of match_token()
Mimi