> From: Roberto Sassu via devel [mailto:devel@lists.fedoraproject.org]
> Sent: Friday, February 18, 2022 4:27 PM
[...]
> Unlike the previous version of DIGLIM, this one does not
> have any dependency (I just had to add rpmplugin.h in
> the rpm-devel package).
>
> It can be configured with two
> From: David Sastre [mailto:d.sastre.med...@gmail.com]
> Sent: Saturday, February 19, 2022 11:56 PM
> (Secure Boot is concerned only with verifying the trustworthiness of the
> bootloader.
> From https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html:
> The Kernel Lockdown feature is
(Secure Boot is concerned only with verifying the trustworthiness of the
bootloader.
>From https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html:
The Kernel Lockdown feature is designed to prevent both direct
and indirect access to a running kernel image, attempting to
protect against
On Fri, Feb 18, 2022 at 4:27 PM Roberto Sassu via devel
wrote:
>
> Hi everyone
>
> I have very exciting news to share.
>
> Given the difficulty to have the DIGLIM kernel patches
> accepted, I checked if I could achieve the same goals
> with an eBPF program.
>
> I focused only on the functionality
Hi everyone
I have very exciting news to share.
Given the difficulty to have the DIGLIM kernel patches
accepted, I checked if I could achieve the same goals
with an eBPF program.
I focused only on the functionality side, it is probably
required some support from the kernel to have the
same
On Wed, Jan 19, 2022 at 11:34:28AM +, Roberto Sassu via devel wrote:
> > From: Roberto Sassu
> > Sent: Tuesday, January 18, 2022 3:36 PM
> > Hi everyone
> >
> > I recently sent to the kernel mailing lists a patch set to support
> > PGP keys and signatures.
> >
> > Other than allowing the
> From: Roberto Sassu
> Sent: Tuesday, January 18, 2022 3:36 PM
> Hi everyone
>
> I recently sent to the kernel mailing lists a patch set to support
> PGP keys and signatures.
>
> Other than allowing the appraisal of RPM headers without
> changes to the building infrastructure, it would also
Hi everyone
I recently sent to the kernel mailing lists a patch set to support
PGP keys and signatures.
Other than allowing the appraisal of RPM headers without
changes to the building infrastructure, it would also simplify
key management for the use cases requiring file or fsverity
signatures
Hi Kevin,
On Mon, Dec 27, 2021, at 11:50 AM, Kevin Kofler via devel wrote:
>
> But being allowed to run custom or self-developed software is a core feature
> of Free Software. If that stops working in the name of "security", Fedora is
> no better than iOS (where Apple also claims the
> From: Chris Murphy [mailto:li...@colorremedies.com]
> Sent: Thursday, January 6, 2022 9:34 PM
> Could this feature work with 3rd party kernel modules, in a UEFI
> Secure Boot (and thus kernel lockdown) context?
It could be possible to create a digest list of third-party kernel
modules. However,
Could this feature work with 3rd party kernel modules, in a UEFI
Secure Boot (and thus kernel lockdown) context?
Workstation working group is tracking this problem as
https://pagure.io/fedora-workstation/issue/155
If DIGLIM could be used for this use case, I further wonder whether
it's possible
> From: Panu Matilainen [mailto:pmati...@redhat.com]
> Sent: Tuesday, January 4, 2022 12:27 PM
> On 1/4/22 10:41, Roberto Sassu via devel wrote:
> > Hi everyone
> >
> > in the FESCo meeting yesterday, Zbigniew asked what is
> > the relationship between this feature and
> >
On 1/4/22 10:41, Roberto Sassu via devel wrote:
Hi everyone
in the FESCo meeting yesterday, Zbigniew asked what is
the relationship between this feature and
https://fedoraproject.org/wiki/Changes/FsVerityRPM.
I try to explain here.
Both features aim at providing reference values, i.e.
values
Hi everyone
in the FESCo meeting yesterday, Zbigniew asked what is
the relationship between this feature and
https://fedoraproject.org/wiki/Changes/FsVerityRPM.
I try to explain here.
Both features aim at providing reference values, i.e.
values of software fingerprint certified by the software
> From: Lennart Poettering [mailto:mzerq...@0pointer.de]
> Sent: Monday, January 3, 2022 1:33 PM
> On Do, 30.12.21 13:04, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
> > > From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> > > Sent: Thursday, December 30, 2021
> From: Lennart Poettering [mailto:mzerq...@0pointer.de]
> Sent: Monday, January 3, 2022 2:34 PM
> On Mo, 03.01.22 13:07, Roberto Sassu (roberto.sa...@huawei.com) wrote:
>
> > That would work if all digest lists are supported by the kernel.
> > The first version worked that way, I developed a
On Mo, 03.01.22 13:07, Roberto Sassu (roberto.sa...@huawei.com) wrote:
> That would work if all digest lists are supported by the kernel.
> The first version worked that way, I developed a simple parser
> of RPM headers, so that the kernel could process then without
> having an additional user
On Do, 30.12.21 13:04, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> > Sent: Thursday, December 30, 2021 1:02 PM
> > The gist of the proposal is described thus:
> > > The new feature behaves as follows. A modified
> From: Neal Gompa [mailto:ngomp...@gmail.com]
> Sent: Saturday, January 1, 2022 3:47 PM
> On Sat, Jan 1, 2022 at 5:51 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 31/12/2021 20:03, Nico Kadel-Garcia wrote:
> > > Sounds like, if this is enabled, they'll need a GPG key associated
> > > with
On Sat, Jan 1, 2022 at 5:51 AM Vitaly Zaitsev via devel
wrote:
>
> On 31/12/2021 20:03, Nico Kadel-Garcia wrote:
> > Sounds like, if this is enabled, they'll need a GPG key associated
> > with their personal repository.
>
> Locally built packages are always unsigned.
>
They don't have to be, but
On 31/12/2021 20:03, Nico Kadel-Garcia wrote:
Sounds like, if this is enabled, they'll need a GPG key associated
with their personal repository.
Locally built packages are always unsigned.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
On Thu, Dec 30, 2021 at 12:19:14 +0100,
Vitaly Zaitsev via devel wrote:
On 30/12/2021 09:21, Chris Murphy wrote:
CPU is proprietary, the firmware is proprietary. Guess we can't trust
our computers?
RISC-V.
RISC-V isn't the answer. It is an ISA (with varients), not a computer. A
RISC-V
On Fri, Dec 31, 2021 at 3:32 AM Vitaly Zaitsev via devel
wrote:
>
> On 30/12/2021 12:58, Roberto Sassu wrote:
> > This has not been decided yet, but likely the Fedora kernel will
> > contain the official Fedora keys, and the user will decide to add
> > new keys (including those from COPR).
>
> 1.
On 30/12/2021 12:58, Roberto Sassu wrote:
This has not been decided yet, but likely the Fedora kernel will
contain the official Fedora keys, and the user will decide to add
new keys (including those from COPR).
1. What about self-built RPMs? I always build RPMs in mock and test them
locally
On Thu, Dec 30, 2021 at 01:04:29PM +, Roberto Sassu via devel wrote:
> > From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> > Sent: Thursday, December 30, 2021 1:02 PM
> > The gist of the proposal is described thus:
> > > The new feature behaves as follows. A modified kernel with
> From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> Sent: Thursday, December 30, 2021 1:02 PM
> The gist of the proposal is described thus:
> > The new feature behaves as follows. A modified kernel with the DIGLIM
> > patches will expose to user space an interface to add/remove file
>
> From: Vitaly Zaitsev via devel [mailto:devel@lists.fedoraproject.org]
> Sent: Thursday, December 30, 2021 12:18 PM
> On 29/12/2021 15:20, Roberto Sassu via devel wrote:
> > The TPM has a fundamental advantage, compared to other
> > mechanisms. It is tamperproof, it often receives high-grade
> >
The gist of the proposal is described thus:
> The new feature behaves as follows. A modified kernel with the DIGLIM
> patches will expose to user space an interface to add/remove file
> digests from the kernel hash table. A user space parser, executed by
> the kernel during early boot, parses RPM
> From: Vitaly Zaitsev via devel [mailto:devel@lists.fedoraproject.org]
> Sent: Thursday, December 30, 2021 12:16 PM
> On 29/12/2021 21:53, Michel Alexandre Salim wrote:
> > If/when something like this gets shipped, I hope Fedora limits itself to
> > shipping a policy that is the equivalent of
On 30/12/2021 09:21, Chris Murphy wrote:
CPU is proprietary, the firmware is proprietary. Guess we can't trust
our computers?
RISC-V.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To
On 29/12/2021 15:20, Roberto Sassu via devel wrote:
The TPM has a fundamental advantage, compared to other
mechanisms. It is tamperproof, it often receives high-grade
certifications, and it is one of the few components that you
could rely on to protect your sensitive data in the event your
host
On 29/12/2021 21:53, Michel Alexandre Salim wrote:
If/when something like this gets shipped, I hope Fedora limits itself to
shipping a policy that is the equivalent of SELinux's 'targeted' policy:
protect the RPMs that Fedora ships from being tampered with, let users
do whatever on top.
What
On Wed, Dec 29, 2021 at 7:39 AM Vitaly Zaitsev via devel
wrote:
>
> On 29/12/2021 12:38, Neal Gompa wrote:
> > Were they really? TPM devices*are* commonly used today to support
> > attestation and multi-factor encryption and authentication mechanisms.
> > In many ways, the trusted computing
On Tue, Dec 28, 2021 at 09:20:11AM -0600, Bruno Wolff III wrote:
> On Tue, Dec 28, 2021 at 14:45:59 +0100,
> Kevin Kofler via devel wrote:
> >
> > But there is the inherent assumption there that the set of software released
> > by Fedora is identical to the set of software the user trusts. In
On Wed, Dec 29, 2021 at 1:35 PM Neal Gompa wrote:
>
> On Wed, Dec 29, 2021 at 11:03 AM Stephen Snow wrote:
> >
> > On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
> > > With Windows 11, they're *mandatory*. Corporate policies now
> > > effectively *require* TPM-based mechanisms *in
On Wed, Dec 29, 2021 at 11:03 AM Stephen Snow wrote:
>
> On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
> > With Windows 11, they're *mandatory*. Corporate policies now
> > effectively *require* TPM-based mechanisms *in addition* to classical
> > password or token-based multi-factor
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: Wednesday, December 29, 2021 2:06 PM
[...]
> > With Windows 11, they're *mandatory*. Corporate policies now
> > effectively *require* TPM-based mechanisms *in addition* to classical
> > password or token-based multi-factor
On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
> With Windows 11, they're *mandatory*. Corporate policies now
> effectively *require* TPM-based mechanisms *in addition* to classical
> password or token-based multi-factor authentication.
This certainly is not any reason to adopt this for
On 29/12/2021 12:38, Neal Gompa wrote:
Were they really? TPM devices*are* commonly used today to support
attestation and multi-factor encryption and authentication mechanisms.
In many ways, the trusted computing initiative was a success. And even
virtualization is used for implementing trusted
> From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> Sent: Wednesday, December 29, 2021 2:36 PM
> Hi,
>
> I'm still reading the discussion, so just a short meta-comment
> on grammar: please don't use masculine forms to describe all Fedora
> users, we're not all guys…
>
> On Tue, Dec
Hi,
I'm still reading the discussion, so just a short meta-comment
on grammar: please don't use masculine forms to describe all Fedora
users, we're not all guys…
On Tue, Dec 28, 2021 at 02:49:43PM +, Roberto Sassu via devel wrote:
> It could be even possible that a user installs
> his own
On Wed, Dec 29, 2021 at 6:39 AM Neal Gompa wrote:
>
> On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia wrote:
> >
> > On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel
> > wrote:
> > >
> > > > From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> > > > Sent: Wednesday, December 29, 2021
On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia wrote:
>
> On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel
> wrote:
> >
> > > From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> > > Sent: Wednesday, December 29, 2021 10:29 AM
> >
> > [...]
> >
> > > From one of the patches:
> > >
> > >
On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel
wrote:
>
> > From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> > Sent: Wednesday, December 29, 2021 10:29 AM
>
> [...]
>
> > From one of the patches:
> >
> > It accomplishes this task by storing reference values coming from
> >
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: Wednesday, December 29, 2021 10:29 AM
[...]
> From one of the patches:
>
> It accomplishes this task by storing reference values coming from
> software vendors and by reporting whether or not the
> digest of file content or
On Tue, Dec 28, 2021 at 8:07 PM Samuel Sieb wrote:
>
> On 12/28/21 16:45, Nico Kadel-Garcia wrote:
> > On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel
> > wrote:
> >>
> >> Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
> >>> But even off by default, I do not see how the "feature"
On 12/28/21 16:45, Nico Kadel-Garcia wrote:
On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel
wrote:
Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
But even off by default, I do not see how the "feature" implemented by this
Change provides any value at all that does not
On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel
wrote:
>
> Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
> > Matthew Miller wrote:
> >> 1. There is a mechanism for users to add their own digest lists, if they
> >> want. The change proposal could be a little more clear on how
On Tue, Dec 28, 2021 at 14:51:35 +0100,
Kevin Kofler via devel wrote:
Can we trust the security code submitted by a Huawei employee to not contain
hidden government-developed backdoors? (Basically the same question as for
the existing NSA SELinux code…)
I think that same question could be
On Tue, Dec 28, 2021 at 14:45:59 +0100,
Kevin Kofler via devel wrote:
But there is the inherent assumption there that the set of software released
by Fedora is identical to the set of software the user trusts. In practice,
those sets will, sure, be overlapping (non-disjoint), but still
> From: Neal Gompa [mailto:ngomp...@gmail.com]
> Sent: Tuesday, December 28, 2021 3:57 PM
[...]
> In general, Fedora does not include non-upstream functionality in its
> Linux kernel builds. This can be frustrating for development and cases
> where upstream requires downstream validation before
On Tue, Dec 28, 2021 at 9:50 AM Roberto Sassu via devel
wrote:
>
> Hi everyone
>
> thanks for the comments. I try to answer in one email.
>
> First, a clarification. Given that this feature is proposed
> for an open source distribution, its primary goal is to
> aid the users to satisfy their
On Tue, Dec 28, 2021 at 9:44 AM Michael Catanzaro wrote:
>
>
> On Mon, Dec 27 2021 at 11:04:01 PM -0800, Adam Williamson
> wrote:
> > For me this seems like kind of a non-starter unless these are merged
> > upstream. I do not think it makes sense for Fedora to carry these
> > patches downstream
Hi everyone
thanks for the comments. I try to answer in one email.
First, a clarification. Given that this feature is proposed
for an open source distribution, its primary goal is to
aid the users to satisfy their security needs, and let them
decide how this will be done. It is not going to
On Tue, Dec 28 2021 at 02:51:35 PM +0100, Kevin Kofler via devel
wrote:
Can we trust the security code submitted by a Huawei employee to not
contain
hidden government-developed backdoors? (Basically the same question
as for
the existing NSA SELinux code…)
I'm going to suggest we evaluate
On Mon, Dec 27 2021 at 11:04:01 PM -0800, Adam Williamson
wrote:
For me this seems like kind of a non-starter unless these are merged
upstream. I do not think it makes sense for Fedora to carry these
patches downstream long-term. If this is a good implementation of a
good feature, it should
Ben Cotton wrote:
> ** Maintain the following patch sets for the Linux kernel, and
> possibly have them accepted in the upstream kernel:
> ***
> [//lore.kernel.org/linux-integrity/20210409114313.4073-1-
roberto.sa...@huawei.com/
> IMA execution policies] ***
>
Mattia Verga via devel wrote:
> I do not see how this change goes against the definition of Free
> Software. It doesn't deny a user to install any software they want, it
> is about preventing unwanted/unsolicited/malevolent software from being
> installed without user (admin) approval.
But there
On Thu, Dec 16, 2021 at 17:27:29 -0500,
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/DIGLIM
More specifically, it will make a system running Fedora attestable
without the need of using dedicated remote attestation protocols. In
fact, the assertion that a system is running a
Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
> Matthew Miller wrote:
>> 1. There is a mechanism for users to add their own digest lists, if they
>> want. The change proposal could be a little more clear on how this
>> would work.
> There is no way I am going to jump through hoops
On 26/12/2021 12:25, Roberto Sassu via devel wrote:
This is the main point of the feature. It aims to protect the user
against untracked software spread in the disk, and to make him
accept the software he wants to run.
And this feature will be disabled by 99% of Fedora users then, because
the
On Thu, 2021-12-16 at 17:27 -0500, Ben Cotton wrote:
>
> == Scope ==
> * Proposal owners:
> ** Maintain the following patch sets for the Linux kernel, and
> possibly have them accepted in the upstream kernel:
> ***
>
Matthew Miller wrote:
> 1. There is a mechanism for users to add their own digest lists, if they
>want. The change proposal could be a little more clear on how this
>would work.
There is no way I am going to jump through hoops to whitelist software I
compiled myself, or installed from a
On Mon, Dec 27, 2021 at 05:50:25PM +0100, Kevin Kofler via devel wrote:
> But being allowed to run custom or self-developed software is a core feature
> of Free Software. If that stops working in the name of "security", Fedora is
> no better than iOS (where Apple also claims the restrictions are
On Mon, Dec 27, 2021 at 08:18:17AM -0500, Nico Kadel-Garcia wrote:
> On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák
> wrote:
> >
> It wouldn't be the first time software has been deliberately broken by
> well-intended kernel security changes. Remember when systemd decided
> to cancel all backgrounded
On Sunday, 26 December 2021 11:25:21 GMT Roberto Sassu via devel wrote:
> > From: Dan Čermák [mailto:dan.cer...@cgc-instruments.com]
> > Sent: Sunday, December 26, 2021 7:10 AM
> > Ben Cotton writes:
> >
> > *snip*
> > > == Upgrade/compatibility impact ==
> > > The user should ensure that
Nico Kadel-Garcia wrote:
> On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák
> wrote:
>>
>> Ben Cotton writes:
>>
>> *snip*
>>
>> > == Upgrade/compatibility impact ==
>> > The user should ensure that software (not updated) from the old
>> > distribution is packaged and the package header is signed, or
On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák
wrote:
>
> Ben Cotton writes:
>
> *snip*
>
> >
> > It will also make Fedora able to detect tampering of its components at
> > a more privileged level, the kernel, without the interference of user
> > space programs. Once tampering has been detected, the
> From: Dan Čermák [mailto:dan.cer...@cgc-instruments.com]
> Sent: Sunday, December 26, 2021 7:10 AM
> Ben Cotton writes:
>
> *snip*
>
> >
> > It will also make Fedora able to detect tampering of its components at
> > a more privileged level, the kernel, without the interference of user
> >
Ben Cotton writes:
*snip*
>
> It will also make Fedora able to detect tampering of its components at
> a more privileged level, the kernel, without the interference of user
> space programs. Once tampering has been detected, the actions of the
> altered component are prevented before that
https://fedoraproject.org/wiki/Changes/DIGLIM
== Summary ==
Digest Lists Integrity Module (DIGLIM) provides a repository of file
digests from authenticated sources, such as RPM headers, to be used by
kernel services for remote attestation and/or secure boot at
application level.
== Owner ==
*
https://fedoraproject.org/wiki/Changes/DIGLIM
== Summary ==
Digest Lists Integrity Module (DIGLIM) provides a repository of file
digests from authenticated sources, such as RPM headers, to be used by
kernel services for remote attestation and/or secure boot at
application level.
== Owner ==
*
72 matches
Mail list logo
