Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-05-02 Thread Andy Lutomirski
> On May 2, 2019, at 4:19 PM, James Morris wrote: > >> On Thu, 2 May 2019, Matthew Garrett wrote: >> >>> On Thu, May 2, 2019 at 2:07 PM James Morris wrote: >>> One possible direction is to (as previously mentioned) assign IDs to each >>> callsite and be able to check this ID against a simple

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-05-02 Thread James Morris
On Thu, 2 May 2019, Matthew Garrett wrote: > On Thu, May 2, 2019 at 2:07 PM James Morris wrote: > > One possible direction is to (as previously mentioned) assign IDs to each > > callsite and be able to check this ID against a simple policy array > > (allow/deny). The default policy choices could

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-05-02 Thread Matthew Garrett
On Thu, May 2, 2019 at 2:07 PM James Morris wrote: > One possible direction is to (as previously mentioned) assign IDs to each > callsite and be able to check this ID against a simple policy array > (allow/deny). The default policy choices could be reduced to 'all' or > 'none' during kconfig, and

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-05-02 Thread James Morris
On Mon, 29 Apr 2019, Matthew Garrett wrote: > Hi James, > > What's the best way forward with this? I'm still not entirely clear on > how it can be implemented purely as an LSM, but if you have ideas on > what sort of implementation you'd prefer I'm happy to work on that. It can't be implemented

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-04-29 Thread Matthew Garrett
Hi James, What's the best way forward with this? I'm still not entirely clear on how it can be implemented purely as an LSM, but if you have ideas on what sort of implementation you'd prefer I'm happy to work on that.

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-04-28 Thread Daniel Axtens
Hi, >>> I'm thinking about whether we should lock down the powerpc xmon debug >>> monitor - intuitively, I think the answer is yes if for no other reason >>> than Least Astonishment, when lockdown is enabled you probably don't >>> expect xmon to keep letting you access kernel memory. >> >> The or

[PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-04-03 Thread Matthew Garrett
From: David Howells Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise, f