On Fri, Jun 28, 2019 at 11:47 AM Matthew Garrett wrote:
>
> On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski wrote:
> > They're really quite similar in my mind. Certainly some things in the
> > "integrity" category give absolutely trivial control over the kernel
> > (e.g. modules) while others
On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski wrote:
> They're really quite similar in my mind. Certainly some things in the
> "integrity" category give absolutely trivial control over the kernel
> (e.g. modules) while others make it quite challenging (ioperm), but
> the end result is very
On Thu, Jun 27, 2019 at 7:35 AM Stephen Smalley wrote:
>
> On 6/26/19 8:57 PM, Andy Lutomirski wrote:
> >
> >
> >> On Jun 26, 2019, at 1:22 PM, James Morris wrote:
> >>
> >> [Adding the LSM mailing list: missed this patchset initially]
> >>
> >>> On Thu, 20 Jun 2019, Andy Lutomirski wrote:
> >>>
On Thu, Jun 27, 2019 at 4:16 PM Matthew Garrett wrote:
>
> On Thu, Jun 27, 2019 at 1:16 PM Stephen Smalley wrote:
> > That would only allow the LSM to further lock down the system above the
> > lockdown level set at boot, not grant exemptions for specific
> > functionality/interfaces required by
On Thu, Jun 27, 2019 at 1:16 PM Stephen Smalley wrote:
> That would only allow the LSM to further lock down the system above the
> lockdown level set at boot, not grant exemptions for specific
> functionality/interfaces required by the user or by a specific
> process/program. You'd have to boot
On 6/27/19 2:06 PM, James Morris wrote:
On Thu, 27 Jun 2019, Stephen Smalley wrote:
There are two scenarios where finer-grained distinctions make sense:
- Users may need to enable specific functionality that falls under the
umbrella of "confidentiality" or "integrity" lockdown. Finer-grained
On Thu, 27 Jun 2019, Stephen Smalley wrote:
> There are two scenarios where finer-grained distinctions make sense:
>
> - Users may need to enable specific functionality that falls under the
> umbrella of "confidentiality" or "integrity" lockdown. Finer-grained lockdown
> reasons free them from
On 6/26/19 8:57 PM, Andy Lutomirski wrote:
On Jun 26, 2019, at 1:22 PM, James Morris wrote:
[Adding the LSM mailing list: missed this patchset initially]
On Thu, 20 Jun 2019, Andy Lutomirski wrote:
This patch exemplifies why I don't like this approach:
@@ -97,6 +97,7 @@ enum
> On Jun 26, 2019, at 1:22 PM, James Morris wrote:
>
> [Adding the LSM mailing list: missed this patchset initially]
>
>> On Thu, 20 Jun 2019, Andy Lutomirski wrote:
>>
>> This patch exemplifies why I don't like this approach:
>>
>>> @@ -97,6 +97,7 @@ enum lockdown_reason {
>>>
[Adding the LSM mailing list: missed this patchset initially]
On Thu, 20 Jun 2019, Andy Lutomirski wrote:
> This patch exemplifies why I don't like this approach:
>
> > @@ -97,6 +97,7 @@ enum lockdown_reason {
> > LOCKDOWN_INTEGRITY_MAX,
> > LOCKDOWN_KCORE,
> >
On Thu, Jun 20, 2019 at 10:22 PM Andy Lutomirski wrote:
> On Thu, Jun 20, 2019 at 6:21 PM Matthew Garrett
> wrote:
> > --- a/security/lockdown/lockdown.c
> > +++ b/security/lockdown/lockdown.c
> > @@ -33,6 +33,7 @@ static char
> > *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> >
On Thu, Jun 20, 2019 at 6:21 PM Matthew Garrett
wrote:
>
> From: David Howells
>
> There are some bpf functions can be used to read kernel memory:
> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
> private keys in kernel memory (e.g. the hibernation image signing key) to
From: David Howells
There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program and kernel memory to be altered without
13 matches
Mail list logo
