Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secureblue: Hardened Immutable Fedora Images

github.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Secureblue: Hardened Immutable Fedora Images

#11

Post by dijit »

redder23 wrote: post #4

When I would use an Immutable Linux I would not be able to run Virtualbox right? Because that needs kernel modules loaded and changes to the core system that is immutable or do I get this wrong?

immutable means read-only; so if you repackage the OS to have virtualbox in the base image then it would work, theoretically.

But why virtualbox over qemu+kvm? KVM is baked into the kernel, is faster, is supported by vagrant (though not all public vagrant boxes) and has a much better track record of security (even now: Virtualbox disables ASLR).

Re: Secureblue: Hardened Immutable Fedora Images

#12

Post by yjftsjthsd-h »

redder23 wrote: post #4

When I would use an Immutable Linux I would not be able to run Virtualbox right? Because that needs kernel modules loaded and changes to the core system that is immutable or do I get this wrong?

Immutable is more about the root filesystem not letting you alter it easily; if the modules are included and not blacklisted (this project talks about blacklisting uncommon modules; I haven't looked at the list) there's no reason it wouldn't work fine.

Re: Secureblue: Hardened Immutable Fedora Images

#13

Post by Retr0id »

yjftsjthsd-h wrote: post #10

So I'm not against it in the general case, but there are some very specific tradeoffs being made here. > The following are not in scope for this project: > Anything related to increasing "privacy", especially when at odds with improving security > Anything related to "degoogling" Frankly, knowing nothing further, I'm a little concerned that degoogling would be necessary. Like, is that just because the system bakes in…

"degoogling" is nice in theory but I've rarely seen it done well in practice. There are either severe UX tradeoffs, or security pitfalls where maintainers mess with configs they don't actually understand.

Having not looked at this project in detail, perhaps it suffers the same fate regardless, but I do find their classification of it as a non-goal to be broadly reassuring.

"Not talking to google" might be more important to some people, and perhaps you're one of those people, so it's good that they're clear about priorities.

Re: Secureblue: Hardened Immutable Fedora Images

#14

Post by secureblue »

yjftsjthsd-h wrote: post #10

So I'm not against it in the general case, but there are some very specific tradeoffs being made here. > The following are not in scope for this project: > Anything related to increasing "privacy", especially when at odds with improving security > Anything related to "degoogling" Frankly, knowing nothing further, I'm a little concerned that degoogling would be necessary. Like, is that just because the system bakes in…

I'm a little concerned that degoogling would be necessary.

I don't follow. The readme specifically says it's not in scope.

How much of the user's privacy is this thing selling away in the name of "security"?

Nothing more or less than upstream fedora. The point of putting that in there is to make it so we don't get people opening issues to ask us to switch to Brave or what have you.

tradeoff

Yes, it's a tradeoff and it's made clear in the readme that we're doing this.

Why should I trust this? It's an unofficial respin by an anonymous user; why would a user trust it?

I would have the same question :)

As I said in another comment: All of the CICD is completely open and transparent. You can read through the github actions logs and build config to verify everything for yourself if you want.

Re: Secureblue: Hardened Immutable Fedora Images

#15

Post by yjftsjthsd-h »

dijit wrote: post #11
redder23 wrote: post #4

When I would use an Immutable Linux I would not be able to run Virtualbox right? Because that needs kernel modules loaded and changes to the core system that is immutable or do I get this wrong?

immutable means read-only; so if you repackage the OS to have virtualbox in the base image then it would work, theoretically. But why virtualbox over qemu+kvm? KVM is baked into the kernel, is faster, is supported by vagrant (though not all public vagrant boxes) and has a much better track record of security (even now: Virtualbox disables ASLR).

> KVM is baked into the kernel, is faster, is supported by vagrant (though not all public vagrant boxes) and has a much better track record of security (even now: Virtualbox disables ASLR).

Technically supported by Vagrant, but every time I tried it was really painful to try and actually use; it's not built-in, so you have to install the plugin which was awful, and then box support was really poor. (To be fair, I ended up dropping Vagrant rather than KVM)

Re: Secureblue: Hardened Immutable Fedora Images

#16

Post by secureblue »

apienx wrote: post #8

Could you please explain the thought process that led you to settle on Fedora? Thanks!

Universal blue, the starting point for this project, is fedora based. https://universal-blue.org/

No other distro has the same level of immutable tooling or support for immutable variants at this time. Also, Fedora has selinux tooling and enforcing mode out of the box and they're working on further selinux improvements upstream, so we'll get that for free.

Re: Secureblue: Hardened Immutable Fedora Images

#17

Post by INTPenis »

secureblue wrote: post #5
INTPenis wrote: post #2

Most of this can be done with Ansible. So why should I download images from a 3rd party outside of the Fedora project? If you really want to harden an OS with a good SElinux implementation you should try enabling user roles. Last time I tried that was maybe Fedora 20 something and it broke a lot.

Most of this can be done with Ansible. All of this can be done in several ways. Ansible, manually, a script, etc. Building it into an image just makes it more convenient. So why should I download images from a 3rd party outside of the Fedora project? All of the CICD is completely open and transparent. You can read through the github actions logs and build config to verify everything for yourself if you want. If you r…

The ublue images are useful to people, so I'm sure your images will be useful to someone. I'm just making a judgement call for myself.

Any other project ontop of Fedora increases the attack vector with its own maintainers.

If I can choose between legible Ansible yaml, and an ISO, I find the yaml much easier to grasp and understand.

Bundling things you could easily do with yaml into an ISO is almost obfuscation. Because most people are not going to read or understand your build config and logs. While Ansible yaml is clearly labeled and tagged for each action.

Re: Secureblue: Hardened Immutable Fedora Images

#18

Post by secureblue »

INTPenis wrote: post #17
secureblue wrote: post #5

Earlier quoted context omitted.

Most of this can be done with Ansible. All of this can be done in several ways. Ansible, manually, a script, etc. Building it into an image just makes it more convenient. So why should I download images from a 3rd party outside of the Fedora project? All of the CICD is completely open and transparent. You can read through the github actions logs and build config to verify everything for yourself if you want. If you r…

The ublue images are useful to people, so I'm sure your images will be useful to someone. I'm just making a judgement call for myself. Any other project ontop of Fedora increases the attack vector with its own maintainers. If I can choose between legible Ansible yaml, and an ISO, I find the yaml much easier to grasp and understand. Bundling things you could easily do with yaml into an ISO is almost obfuscation. Becau…

I'm just making a judgement call for myself. Any other project ontop of Fedora increases the attack vector with its own maintainers.

Totally understandable.

an ISO

Small point of correction: we're not publishing ISOs.

Re: Secureblue: Hardened Immutable Fedora Images

#19

Post by _ea1k »

yjftsjthsd-h wrote: post #10

So I'm not against it in the general case, but there are some very specific tradeoffs being made here. > The following are not in scope for this project: > Anything related to increasing "privacy", especially when at odds with improving security > Anything related to "degoogling" Frankly, knowing nothing further, I'm a little concerned that degoogling would be necessary. Like, is that just because the system bakes in…

I think there are some default libraries that support using Google Drive for backups, calendar, and email, among other things? TBH, I'd be surprised if those were in scope.
Post reply on HN