RE: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Kevin Fenzi [mailto:kevin@xxxxxxxxx]
> Sent: Tuesday, January 25, 2022 7:30 PM
> On Fri, Jan 21, 2022 at 04:08:04PM +0000, Roberto Sassu via devel wrote:
> > Hi everyone
> >
> > (note for the infrastructure mailing list: please check if the changes
> > I'm proposing could be tested in the Fedora infrastructure, like Copr)
> 
> copr uses a different signing setup... so probibly won't work there.
> 
> We could perhaps work with you to try and get it in our staging env to
> test, but I am not sure how involved that might be. I guess the first
> step would be filing a infratructure ticket and explain what you would
> need to change/test.

Thanks, Kevin. Will do.

> So, question for the change owners:
> 
> This is not enabled by default, I assume you wish to enable it for
> something, can you expand on what you will use it for and what that
> helps you with?
> 
> Also, is there any plan to enable it by default? Is there some way this
> could be useful to all our users? or more of our users?
> 
> This change and the DIGLIM change both feel to me like we are spending
> time and effort enabling something that only helps a tiny fraction of
> our users. Is there some way this could be more generally useful to our
> users?

I guess not many would use the remote attestation capability
offered by DIGLIM (sealing a TPM key to the software running
in the machine). The two scenarios in which that could be used
are:

- web servers or other kind of servers where you, as client, would
  like the guarantee that your data is processed only if the software
  running in the server is not compromised

- closed networks where you, as network administrator, would like
  the guarantee that your clients can access those networks only if
  their software is not compromised


Probably, the secure boot functionality at application level is much
more appealing, and less invasive. It should have almost zero impact
if the users use their system for web browsing or writing. Although
it is unlikely to happen, this feature prevents arbitrary execution of
software, even by root. The trust anchor will be the kernel, and one
would not have to rely on the correct execution of the package
manager (and on its verification of the package signature).

If the users often make changes on their system, but confined to
their environment, DIGLIM could still be helpful, as the damage of
running arbitrary software will be limited to the users environment
(no arbitrary software execution as root).

If the users often make changes on their system, with high privileges,
I agree that DIGLIM would simply cause too much overhead for
the configuration (every time the users make a change, they have
to whitelist their software).

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux