Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1650233 > unrolled thread

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image David Howells <dhowells@redhat.com> - 2017-05-25 09:00 +0200
    Re: [PATCH 3/5] Add the ability to lock down access to the running  kernel image Casey Schaufler <casey@schaufler-ca.com> - 2017-05-25 20:20 +0200
      Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image David Howells <dhowells@redhat.com> - 2017-05-26 14:50 +0200
        Re: [PATCH 3/5] Add the ability to lock down access to the running  kernel image joeyli <jlee@suse.com> - 2017-05-26 19:10 +0200

#1650233 — Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

Casey Schaufler <casey@schaufler-ca.com> wrote:

> > +#ifdef CONFIG_LOCK_DOWN_KERNEL
> > +extern bool kernel_is_locked_down(void);
> > +#else
> > +static inline bool kernel_is_locked_down(void)
> 
> Should this be a bool or an int? I can imagine that someone is going to want
> various different degrees of lock down for kernels. As an int you could
> return a bitmap indicating which features were locked. This would allow
> additional things to be locked down without changing the interface.

At the moment it makes no difference, since the return value is only ever
passed directly to an if-statement.

Also, do you have an idea as to how is should be divided up?

There aren't so many cases, at least not yet, that they can't be fixed up,
perhaps with a coccinelle script.

David

[toc] | [next] | [standalone]

#1650713 — Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On 5/24/2017 11:53 PM, David Howells wrote:
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>>> +#ifdef CONFIG_LOCK_DOWN_KERNEL
>>> +extern bool kernel_is_locked_down(void);
>>> +#else
>>> +static inline bool kernel_is_locked_down(void)
>> Should this be a bool or an int? I can imagine that someone is going to want
>> various different degrees of lock down for kernels. As an int you could
>> return a bitmap indicating which features were locked. This would allow
>> additional things to be locked down without changing the interface.
> At the moment it makes no difference, since the return value is only ever
> passed directly to an if-statement.
>
> Also, do you have an idea as to how is should be divided up?

You called out five distinct features in 0/5, so how about
a bit for each of those?

Actually, I don't care which way you go. The current code works
for me. I am just concerned that the granularity fiends might come
around later.


>
> There aren't so many cases, at least not yet, that they can't be fixed up,
> perhaps with a coccinelle script.
>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[toc] | [prev] | [next] | [standalone]

#1651363

Casey Schaufler <casey@schaufler-ca.com> wrote:

> You called out five distinct features in 0/5, so how about
> a bit for each of those?

Actually, there are more than five in that list - there are three in the first
item - and I'm not sure the remaining categories are quite as well defined as
I made it seem.

Also, that sort of categorisation might not be what we actually need: it might
end up coming down to a no-write vs no-read-or-write split instead.

> Actually, I don't care which way you go. The current code works
> for me. I am just concerned that the granularity fiends might come
> around later.

In that case, I'll leave it as is for the moment.  It doesn't introduce so
many calls that they're impossible to change.

David

[toc] | [prev] | [next] | [standalone]

#1651527 — Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote:
> Casey Schaufler <casey@schaufler-ca.com> wrote:
> 
> > You called out five distinct features in 0/5, so how about
> > a bit for each of those?
> 
> Actually, there are more than five in that list - there are three in the first
> item - and I'm not sure the remaining categories are quite as well defined as
> I made it seem.
>

Do we have a public place (e.g. wiki page) to put the list of lock-down
functions?

Thanks a lot!
Joey Lee 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web