LWN: Comments on "Another Fedora integrity-management proposal"

Another Fedora integrity-management proposal

NYKevin — Sat, 08 Jan 2022 09:02:01 +0000

Meh, it's even useful on individual, human-operated machines. Just because a computer is human-operated, it does not necessarily follow that the human is in fact the legal owner of the computer. Businesses routinely issue devices to their employees, and the business has every right to dictate what software the device"should" be running, because it's not the employee's device. It's the business's device.

Now, I'm sure that some of us would never touch such an arrangement with a ten-foot pole, but regarding it as unethical is an extreme overreaction IMHO. You cannot seriously claim that the ownership of the device changes just because someone is being allowed to borrow it, right?

Another Fedora integrity-management proposal

LtWorf — Thu, 06 Jan 2022 16:55:30 +0000

It is trivial to do a partition with the binaries that is mounted as RO and where the vm process has no write access, and separate partitions with noexec for the data. If you want to just verify the base system

Another Fedora integrity-management proposal

smoogen — Thu, 06 Jan 2022 15:21:37 +0000

I think it is a matter of a signed image is only good until it is run. You could only use that signature inside the image if you regenerate it against the entire image before execution of any binary. Once an update, or some other change happens that signature is no longer valid so you would need to drop the image, confirm the changes that were made were legitimate, and resign it and then rerun. These sorts of controls are to allow for updates of artifacts inside the image and knowing they are still valid.

When you have hundreds of thousands to millions of deployed systems being able to automatically block N systems versus manually finding them and then blocking is seen as beneficial. When you have just a laptop.. it is seen as not owning your system anymore and someone else deciding what is beneficial or not.

Another Fedora integrity-management proposal

rahulsundaram — Thu, 06 Jan 2022 12:48:02 +0000

> I guess Huawei? It seems the author of the proposed change works there.

As I already noted, I wasn't quoting the author of the proposal. If the software is open source and in user control, we aren't limited by author's intend anyway.

Another Fedora integrity-management proposal

LtWorf — Thu, 06 Jan 2022 10:50:38 +0000

Why not just sign the entire vm image?

Another Fedora integrity-management proposal

LtWorf — Thu, 06 Jan 2022 10:47:51 +0000

> Who is "they"?

I guess Huawei? It seems the author of the proposed change works there.

Another Fedora integrity-management proposal

martin.langhoff — Wed, 05 Jan 2022 19:21:47 +0000

We need this as part of security infra -- mechanisms to validate VM images and container images against SBOM-style manifests.

It's useful when you fetch images and perhaps when you boot them.

It's useful during runtime if the kernel enforces read-only, or refuses to open tampered files.

And it's useful for post-mortems in case of a breach – did the attacker plant or modify files? Which ones?

On my personal machine, I only want this kind of mechanism in a format I can trust, that's certain. But reinforcing what you can (to a large extent) already do with rpm --verify and dpkg --verify today is a positive.

Another Fedora integrity-management proposal

rahulsundaram — Wed, 05 Jan 2022 16:37:41 +0000

> Oh, I'm quite aware that they'll say this.

Who is "they"? I was quoting the editorial opinion from the LWN article and not from the proposal owner FYI. Also have you read Neal Gompa's post on user control quoted in the article?

Another Fedora integrity-management proposal

ddevault — Wed, 05 Jan 2022 15:02:25 +0000

Oh, I'm quite aware that they'll say this. But, this is not the first time we've seen this kind of thing. What's happening here is that they're starting with what they want - technology to enable DRM - and trying to come up with use-cases which are not DRM but which use the same technology as an excuse to shove the technology through.

Another Fedora integrity-management proposal

rahulsundaram — Wed, 05 Jan 2022 14:55:31 +0000

> Proponents of Digital Restrictions Management are to be given no quarter

From the article, "The concerns about locked-down systems and DRM are reasonable to a certain extent, but that is not at all what DIGLIM is targeting"

Another Fedora integrity-management proposal

ddevault — Wed, 05 Jan 2022 14:23:54 +0000

Proponents of Digital Restrictions Management are to be given no quarter. It is unethical for us to write software which is designed to deny the rights of our users. An outright refusal of any such feature requests is the only acceptable answer.

Another Fedora integrity-management proposal

ballombe — Wed, 05 Jan 2022 09:07:02 +0000

I am always skeptical of attempts to increase security by increasing complexity. This opens whole new avenues for attackers for DOSing systems or for blocking the application of security updates.

Another Fedora integrity-management proposal

taladar — Wed, 05 Jan 2022 08:18:39 +0000

I am very sceptical about this. I could see some certification authority certifying exact versions of packages (slowly, potentially only once every couple of years) and leaving systems that require that certification (to be more secure on paper) completely vulnerable in practice.

In other words I am sceptical about giving the "never change a running system" crowd even a millimetre because they are already been responsible for the vast majority of unpatched security holes on de facto existing systems.