| Message ID | alpine.LRH.2.21.1812250652420.2714@namei.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] security: general updates for v4.21 | expand |
On Mon, Dec 24, 2018 at 11:55 AM James Morris <jmorris@namei.org> 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!
On Thu, 27 Dec 2018, Linus Torvalds wrote: > On Mon, Dec 24, 2018 at 11:55 AM James Morris <jmorris@namei.org> 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.
On Fri, Dec 28, 2018 at 7:11 PM James Morris <jmorris@namei.org> 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 <jmorris@namei.org> 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.
On Fri, Dec 28, 2018 at 8:09 PM James Morris <jmorris@namei.org> 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 12/28/2018 8:15 PM, Linus Torvalds wrote: > On Fri, Dec 28, 2018 at 8:09 PM James Morris <jmorris@namei.org> 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 <jmorris@namei.org> 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 <jmorris@namei.org> 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.
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
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(-)