Re: [GIT PULL] Security subsystem updates for 4.14

On Sat, 2017-09-09 at 05:57 +1000, James Morris wrote: > On Fri, 8 Sep 2017, Linus Torvalds wrote: > > > Now the whole security pull will be ignored because of this thing. I > > refuse to pull garbage where I notice major fundamental problems in > > code that has obviously never ever been tested.

Re: [GIT PULL] Security subsystem updates for 4.14

On Sat, 2017-09-09 at 05:57 +1000, James Morris wrote: > On Fri, 8 Sep 2017, Linus Torvalds wrote: > > > Now the whole security pull will be ignored because of this thing. I > > refuse to pull garbage where I notice major fundamental problems in > > code that has obviously never ever been tested.

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, Sep 14, 2017 at 2:13 PM, James Morris wrote: > On Thu, 14 Sep 2017, Kees Cook wrote: > >> How separable are the patches, normally? > > They're usually mostly separate, but may depend on some core LSM change, > or similar. > > Casey has mentioned off-list that it is

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, Sep 14, 2017 at 2:13 PM, James Morris wrote: > On Thu, 14 Sep 2017, Kees Cook wrote: > >> How separable are the patches, normally? > > They're usually mostly separate, but may depend on some core LSM change, > or similar. > > Casey has mentioned off-list that it is useful to have a

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, 14 Sep 2017, Kees Cook wrote: > How separable are the patches, normally? They're usually mostly separate, but may depend on some core LSM change, or similar. Casey has mentioned off-list that it is useful to have a coherent up to date security branch to work against when making core

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, 14 Sep 2017, Kees Cook wrote: > How separable are the patches, normally? They're usually mostly separate, but may depend on some core LSM change, or similar. Casey has mentioned off-list that it is useful to have a coherent up to date security branch to work against when making core

Re: [GIT PULL] Security subsystem updates for 4.14

On Sat, Sep 9, 2017 at 9:32 PM, James Morris wrote: > On Fri, 8 Sep 2017, Paul Moore wrote: > >> > This is also why I tend to prefer getting multiple branches for >> > independent things. > > [...] > >> >> Is it time to start sending pull request for each LSM and thing under >>

Re: [GIT PULL] Security subsystem updates for 4.14

On Sat, Sep 9, 2017 at 9:32 PM, James Morris wrote: > On Fri, 8 Sep 2017, Paul Moore wrote: > >> > This is also why I tend to prefer getting multiple branches for >> > independent things. > > [...] > >> >> Is it time to start sending pull request for each LSM and thing under >> security/

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 12:32 AM, James Morris wrote: > On Fri, 8 Sep 2017, Paul Moore wrote: > >> > This is also why I tend to prefer getting multiple branches for >> > independent things. > > [...] > >> >> Is it time to start sending pull request for each LSM and thing under

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 12:32 AM, James Morris wrote: > On Fri, 8 Sep 2017, Paul Moore wrote: > >> > This is also why I tend to prefer getting multiple branches for >> > independent things. > > [...] > >> >> Is it time to start sending pull request for each LSM and thing under >> security/

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, 2017-09-10 at 23:38 -0700, Christoph Hellwig wrote: > On Sun, Sep 10, 2017 at 10:02:42AM -0400, Mimi Zohar wrote: > > We need to differentiate between policies and x509 certificates.  In > > the policy case, they need to be signed and appraised, while in the > > x509 certificate case, the

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, 2017-09-10 at 23:38 -0700, Christoph Hellwig wrote: > On Sun, Sep 10, 2017 at 10:02:42AM -0400, Mimi Zohar wrote: > > We need to differentiate between policies and x509 certificates.  In > > the policy case, they need to be signed and appraised, while in the > > x509 certificate case, the

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 10:02:42AM -0400, Mimi Zohar wrote: > We need to differentiate between policies and x509 certificates.  In > the policy case, they need to be signed and appraised, while in the > x509 certificate case, the certificate itself is signed so the file > doesn't need to be signed

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 10:02:42AM -0400, Mimi Zohar wrote: > We need to differentiate between policies and x509 certificates.  In > the policy case, they need to be signed and appraised, while in the > x509 certificate case, the certificate itself is signed so the file > doesn't need to be signed

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, 2017-09-10 at 01:10 -0700, Christoph Hellwig wrote: > On Fri, Sep 08, 2017 at 10:25:53AM -0700, Linus Torvalds wrote: > > I don't think anybody actually tests linux-next kernels in any big > > way, and the automated tests that do get run probably don't run with > > any integrity checking

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, 2017-09-10 at 01:10 -0700, Christoph Hellwig wrote: > On Fri, Sep 08, 2017 at 10:25:53AM -0700, Linus Torvalds wrote: > > I don't think anybody actually tests linux-next kernels in any big > > way, and the automated tests that do get run probably don't run with > > any integrity checking

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 03:13:23AM -0400, Mimi Zohar wrote: > > From a file integrity perspective this would be interesting, but that > only addresses IMA-appraisal, not IMA-integrity or IMA-audit.  We > would still need to calculate the file hash to be included in the > measurement list and used

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, Sep 10, 2017 at 03:13:23AM -0400, Mimi Zohar wrote: > > From a file integrity perspective this would be interesting, but that > only addresses IMA-appraisal, not IMA-integrity or IMA-audit.  We > would still need to calculate the file hash to be included in the > measurement list and used

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 08, 2017 at 10:25:53AM -0700, Linus Torvalds wrote: > I don't think anybody actually tests linux-next kernels in any big > way, and the automated tests that do get run probably don't run with > any integrity checking enabled. Well, for the atual IMA deadlock issue I asked Mimi to

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 08, 2017 at 10:25:53AM -0700, Linus Torvalds wrote: > I don't think anybody actually tests linux-next kernels in any big > way, and the automated tests that do get run probably don't run with > any integrity checking enabled. Well, for the atual IMA deadlock issue I asked Mimi to

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 2017-09-08 at 18:38 -0400, Theodore Ts'o wrote: > On Fri, Sep 08, 2017 at 02:48:51PM +1000, James Morris wrote: > > > > Mimi and Christoph worked together on this over several iterations -- I'll > > let them respond. > > Mimi --- we should chat next week in LA. I've been working on a >

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 2017-09-08 at 18:38 -0400, Theodore Ts'o wrote: > On Fri, Sep 08, 2017 at 02:48:51PM +1000, James Morris wrote: > > > > Mimi and Christoph worked together on this over several iterations -- I'll > > let them respond. > > Mimi --- we should chat next week in LA. I've been working on a >

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, 2017-09-07 at 11:19 -0700, Linus Torvalds wrote: > On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > > > IMA: > > - A new integrity_read file operation method, avoids races when > > calculating file hashes > > Honestly, this seems really odd. > > It

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, 2017-09-07 at 11:19 -0700, Linus Torvalds wrote: > On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > > > IMA: > > - A new integrity_read file operation method, avoids races when > > calculating file hashes > > Honestly, this seems really odd. > > It documents that it needs

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, 10 Sep 2017, James Morris wrote: > next-apparmor-next (JJ's next branch) > next-integrity-next (Mimi's) > next-tpm-next(Jarkko's) without '-next' on the end... (editing while jetlagged). -- James Morris

Re: [GIT PULL] Security subsystem updates for 4.14

On Sun, 10 Sep 2017, James Morris wrote: > next-apparmor-next (JJ's next branch) > next-integrity-next (Mimi's) > next-tpm-next(Jarkko's) without '-next' on the end... (editing while jetlagged). -- James Morris

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 8 Sep 2017, Paul Moore wrote: > > This is also why I tend to prefer getting multiple branches for > > independent things. [...] > > Is it time to start sending pull request for each LSM and thing under > security/ directly? I'm not sure I have a strong preference either > way, I just

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 8 Sep 2017, Paul Moore wrote: > > This is also why I tend to prefer getting multiple branches for > > independent things. [...] > > Is it time to start sending pull request for each LSM and thing under > security/ directly? I'm not sure I have a strong preference either > way, I just

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 8 Sep 2017, Theodore Ts'o wrote: > On Fri, Sep 08, 2017 at 02:48:51PM +1000, James Morris wrote: > > > > Mimi and Christoph worked together on this over several iterations -- I'll > > let them respond. > > Mimi --- we should chat next week in LA. I've been working on a > design

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 8 Sep 2017, Theodore Ts'o wrote: > On Fri, Sep 08, 2017 at 02:48:51PM +1000, James Morris wrote: > > > > Mimi and Christoph worked together on this over several iterations -- I'll > > let them respond. > > Mimi --- we should chat next week in LA. I've been working on a > design

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 08, 2017 at 02:48:51PM +1000, James Morris wrote: > > Mimi and Christoph worked together on this over several iterations -- I'll > let them respond. Mimi --- we should chat next week in LA. I've been working on a design internally at work which proposes a generic VFS-layer library

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 08, 2017 at 02:48:51PM +1000, James Morris wrote: > > Mimi and Christoph worked together on this over several iterations -- I'll > let them respond. Mimi --- we should chat next week in LA. I've been working on a design internally at work which proposes a generic VFS-layer library

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 8 Sep 2017, Linus Torvalds wrote: > Now the whole security pull will be ignored because of this thing. I > refuse to pull garbage where I notice major fundamental problems in > code that has obviously never ever been tested. If I revert the change from my my tree, will you pull it then?

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, 8 Sep 2017, Linus Torvalds wrote: > Now the whole security pull will be ignored because of this thing. I > refuse to pull garbage where I notice major fundamental problems in > code that has obviously never ever been tested. If I revert the change from my my tree, will you pull it then?

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 8, 2017 at 1:25 PM, Linus Torvalds wrote: > On Fri, Sep 8, 2017 at 12:09 AM, Christoph Hellwig wrote: >> >> But yes, for the init-time integrity_read_file this is incorrect. >> It never tripped up, and I explicitly added the lockdep

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 8, 2017 at 1:25 PM, Linus Torvalds wrote: > On Fri, Sep 8, 2017 at 12:09 AM, Christoph Hellwig wrote: >> >> But yes, for the init-time integrity_read_file this is incorrect. >> It never tripped up, and I explicitly added the lockdep annotations >> so that anything would show up, and

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 8, 2017 at 12:09 AM, Christoph Hellwig wrote: > > But yes, for the init-time integrity_read_file this is incorrect. > It never tripped up, and I explicitly added the lockdep annotations > so that anything would show up, and it's been half a year since > I sent that

Re: [GIT PULL] Security subsystem updates for 4.14

On Fri, Sep 8, 2017 at 12:09 AM, Christoph Hellwig wrote: > > But yes, for the init-time integrity_read_file this is incorrect. > It never tripped up, and I explicitly added the lockdep annotations > so that anything would show up, and it's been half a year since > I sent that first RFC patch..

Re: [GIT PULL] Security subsystem updates for 4.14

The reason why I send out the original version of this patch is because IMA used to call ->read under i_rwsem, and that deadlocked on XFS and NFS, or ext3/4 with DAX. The call path for that is process_measurement (takes i_rwsem) -> ima_collect_measurement -> ima_calc_file_hash ->

Re: [GIT PULL] Security subsystem updates for 4.14

The reason why I send out the original version of this patch is because IMA used to call ->read under i_rwsem, and that deadlocked on XFS and NFS, or ext3/4 with DAX. The call path for that is process_measurement (takes i_rwsem) -> ima_collect_measurement -> ima_calc_file_hash ->

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, 7 Sep 2017, Linus Torvalds wrote: > On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > > > IMA: > > - A new integrity_read file operation method, avoids races when > > calculating file hashes > > Honestly, this seems really odd. > > It documents that it

Re: [GIT PULL] Security subsystem updates for 4.14

On Thu, 7 Sep 2017, Linus Torvalds wrote: > On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > > > IMA: > > - A new integrity_read file operation method, avoids races when > > calculating file hashes > > Honestly, this seems really odd. > > It documents that it needs to be called

Re: [GIT PULL] Security subsystem updates for 4.14

On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > IMA: > - A new integrity_read file operation method, avoids races when > calculating file hashes Honestly, this seems really odd. It documents that it needs to be called with i_rwsem held exclusively, and even has

Re: [GIT PULL] Security subsystem updates for 4.14

On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > IMA: > - A new integrity_read file operation method, avoids races when > calculating file hashes Honestly, this seems really odd. It documents that it needs to be called with i_rwsem held exclusively, and even has a lockdep assert to