Matthew Garrett wrote:
> Yes. Wouldn't having a mechanism to allow userspace to drop keys that
> have otherwise been imported be a generally useful solution to the issue
> you have with that?
"keyctl invalidate" could be a way to drop keys.
David
--
To unsubscribe from this list: send the lin
On Tue, 2014-06-10 at 15:49 +0300, Dmitry Kasatkin wrote:
> On 10/06/14 15:45, Mimi Zohar wrote:
> > On Tue, 2014-06-10 at 11:48 +0300, Dmitry Kasatkin wrote:
> >> Hi Mimi,
> >>
> >> As you asked ofline , here is possible equivalent and simpler alternative
> >> patches not requiring to have addit
On Wed, Jun 11, 2014 at 08:30:20AM -0400, Mimi Zohar wrote:
> On Wed, 2014-06-11 at 04:23 +0100, Matthew Garrett wrote:
> > Yes. Wouldn't having a mechanism to allow userspace to drop keys that
> > have otherwise been imported be a generally useful solution to the issue
> > you have with that?
>
On Wed, 2014-06-11 at 04:23 +0100, Matthew Garrett wrote:
> Yes. Wouldn't having a mechanism to allow userspace to drop keys that
> have otherwise been imported be a generally useful solution to the issue
> you have with that?
There are issues removing a key from both the local system(eg. cache
On Tue, Jun 10, 2014 at 11:08:15PM -0400, Mimi Zohar wrote:
> On Wed, 2014-06-11 at 03:22 +0100, Matthew Garrett wrote:
> > Providing a userspace mechanism for selectively dropping keys from the
> > kernel seems like a good thing?
>
> No, patch "KEYS: verify a certificate is signed by a 'trusted
On Wed, 2014-06-11 at 03:22 +0100, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 09:24:53PM -0400, Mimi Zohar wrote:
> > On Tue, 2014-06-10 at 22:40 +0100, Matthew Garrett wrote:
> > > The hole is that the system trusts keys that you don't trust. The
> > > appropriate thing to do is to remove
On Tue, Jun 10, 2014 at 09:24:53PM -0400, Mimi Zohar wrote:
> On Tue, 2014-06-10 at 22:40 +0100, Matthew Garrett wrote:
> > The hole is that the system trusts keys that you don't trust. The
> > appropriate thing to do is to remove that trust from the entire system,
> > not just one layer of the
On Tue, 2014-06-10 at 22:40 +0100, Matthew Garrett wrote:
> On Wed, Jun 11, 2014 at 12:34:28AM +0300, Dmitry Kasatkin wrote:
>
> > My statement is still valid. It is a hole...
> >
> > To prevent the hole it should be explained that one might follow
> > certain instructions
> > to take ownership
On 11 June 2014 00:40, Matthew Garrett wrote:
> On Wed, Jun 11, 2014 at 12:34:28AM +0300, Dmitry Kasatkin wrote:
>
>> My statement is still valid. It is a hole...
>>
>> To prevent the hole it should be explained that one might follow
>> certain instructions
>> to take ownership of your PC. Generat
On Wed, Jun 11, 2014 at 12:34:28AM +0300, Dmitry Kasatkin wrote:
> My statement is still valid. It is a hole...
>
> To prevent the hole it should be explained that one might follow
> certain instructions
> to take ownership of your PC. Generate your own keys and remove MS and
> Vendor ones...
Th
On 11 June 2014 00:34, Dmitry Kasatkin wrote:
> On 11 June 2014 00:25, Matthew Garrett wrote:
>> On Wed, Jun 11, 2014 at 12:17:53AM +0300, Dmitry Kasatkin wrote:
>>
>>> It is probably just a paranoia...
>>> Kconfig MODULE_SIG_UEFI should tell about threat of loading kernel
>>> modules from NSA or
On 11 June 2014 00:25, Matthew Garrett wrote:
> On Wed, Jun 11, 2014 at 12:17:53AM +0300, Dmitry Kasatkin wrote:
>
>> It is probably just a paranoia...
>> Kconfig MODULE_SIG_UEFI should tell about threat of loading kernel
>> modules from NSA or Lenovo signed by MS or Lenovo keys..
>>
>> This hole
On Wed, Jun 11, 2014 at 12:17:53AM +0300, Dmitry Kasatkin wrote:
> It is probably just a paranoia...
> Kconfig MODULE_SIG_UEFI should tell about threat of loading kernel
> modules from NSA or Lenovo signed by MS or Lenovo keys..
>
> This hole is opened without warning...
It's not typically a hole
On 11 June 2014 00:00, Dmitry Kasatkin wrote:
> On 10 June 2014 23:40, Matthew Garrett wrote:
>> On Tue, Jun 10, 2014 at 11:34:17PM +0300, Dmitry Kasatkin wrote:
>>
>>> Preventing loading keys from uefi except dbx by default actually improves
>>> security. Adding kernel parameter to read db we ma
On 10 June 2014 23:40, Matthew Garrett wrote:
> On Tue, Jun 10, 2014 at 11:34:17PM +0300, Dmitry Kasatkin wrote:
>
>> Preventing loading keys from uefi except dbx by default actually improves
>> security. Adding kernel parameter to read db we make system more
>> vulnerable.
>
> It only adds securi
On Tue, Jun 10, 2014 at 11:34:17PM +0300, Dmitry Kasatkin wrote:
> Preventing loading keys from uefi except dbx by default actually improves
> security. Adding kernel parameter to read db we make system more
> vulnerable.
It only adds security if you're performing a measured boot and remote
atte
On 10 June 2014 15:20, Josh Boyer wrote:
> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
>> Hi Mimi,
>>
>> As you asked ofline , here is possible equivalent and simpler alternative
>> patches not requiring to have additional keyring.
>>
>> First patch are irrelevant minor fixes.
On Tue, Jun 10, 2014 at 03:58:54PM +0300, Dmitry Kasatkin wrote:
> It is tricky issue. But yes and no... If I forced to trust MS key to run
> SHIM, it does not mean
> that I want to trust MS key to run kernel and load modules or use MS key
> to valid other keys on system keyring.
A kernel paramet
On Tue, 2014-06-10 at 09:29 -0400, Josh Boyer wrote:
> On Tue, Jun 10, 2014 at 04:21:36PM +0300, Dmitry Kasatkin wrote:
> > On 10/06/14 15:52, Mimi Zohar wrote:
> > > On Tue, 2014-06-10 at 08:20 -0400, Josh Boyer wrote:
> > >> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
> > >
On Tue, Jun 10, 2014 at 04:21:36PM +0300, Dmitry Kasatkin wrote:
> On 10/06/14 15:52, Mimi Zohar wrote:
> > On Tue, 2014-06-10 at 08:20 -0400, Josh Boyer wrote:
> >> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
> >>> Also I want to discuss here Fedora UEFI patches as they are t
On 10/06/14 15:52, Mimi Zohar wrote:
> On Tue, 2014-06-10 at 08:20 -0400, Josh Boyer wrote:
>> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
>>> Also I want to discuss here Fedora UEFI patches as they are the reason for
>>> the these original patchset.
>>>
>>> http://pkgs.fedora
On 10/06/14 15:20, Josh Boyer wrote:
> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
>> Hi Mimi,
>>
>> As you asked ofline , here is possible equivalent and simpler alternative
>> patches not requiring to have additional keyring.
>>
>> First patch are irrelevant minor fixes.
>>
>
On Tue, 2014-06-10 at 08:20 -0400, Josh Boyer wrote:
> On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
> > Also I want to discuss here Fedora UEFI patches as they are the reason for
> > the these original patchset.
> >
> > http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsi
On 10/06/14 15:45, Mimi Zohar wrote:
> On Tue, 2014-06-10 at 11:48 +0300, Dmitry Kasatkin wrote:
>> Hi Mimi,
>>
>> As you asked ofline , here is possible equivalent and simpler alternative
>> patches not requiring to have additional keyring.
> Please indicate which branch these patches apply to.
>
On Tue, 2014-06-10 at 11:48 +0300, Dmitry Kasatkin wrote:
> Hi Mimi,
>
> As you asked ofline , here is possible equivalent and simpler alternative
> patches not requiring to have additional keyring.
Please indicate which branch these patches apply to.
thanks,
Mimi
--
To unsubscribe from this
On Tue, Jun 10, 2014 at 11:48:14AM +0300, Dmitry Kasatkin wrote:
> Hi Mimi,
>
> As you asked ofline , here is possible equivalent and simpler alternative
> patches not requiring to have additional keyring.
>
> First patch are irrelevant minor fixes.
>
> Also I want to discuss here Fedora UEFI pa
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative
patches not requiring to have additional keyring.
First patch are irrelevant minor fixes.
Also I want to discuss here Fedora UEFI patches as they are the reason for
the these original patchset.
http://pkgs.fedora
27 matches
Mail list logo
