Create a Rocky Linux version

[FlurryNight]

trafficstars

Hello, Thank you for this project.

Hope you continue it and add features to make it the best.

I was thinking if you could consider doing a version of AnotterKiosk using Rocky Linux 9, or switching entirely to it.

Rocky (CentOS-RHEL) is proved to be a much more stable and reasonable distro overall, And i think it would be a nice move for this project since its in is early phase (before V1).

Considering too the security issues mentioned on the readme to be solved in near versions, it would make sense to correct them whenever possible with the advantage of a cleaner distro like Rocky and also make use of SELinux (past V1 maybe).

Thanks again, Have a nice day

If you need any tips, advice or help , hmu Cheers!

[Manawyrm]

Hi,

I'm honestly a bit surprised about the request to move to Rocky Linux right now, especially amidst the whole Red Hat licensing debacle. Personally, I've been a Debian user for the last 20 years (on server systems) and a ArchLinux user for the past 10 years (mostly on desktop machines), but I'm lacking any professional experience using RHEL-based systems.

Funnily enough, a while ago I was looking for a similar approach to debootstrap for RHEL-based systems and could only find the "rinse" project, which was also developed by Debian (but targets only RHEL).

I don't personally see any stability concerns using the Debian stable distribution. debian-security always includes the current Chromium versions and the rest of the system is ... well, Debian 😄

A real issue for reliability and stability is the Raspberry Pi kernel and userland, which I'm including by using their image. That's certainly not known for being reliable or dependable in any way, but it's what we've got (especially when we want to have hardware acceleration). Running a mainline kernel for this application has proven to be wonky at best.

For additional security, we'd have to talk about threat models. With the current system, I do see some issues:

• SSH is available publicly (0.0.0.0), could be bound to AutoSSH only (optionally, in a hardened mode)
• NTP safety
• pi user being in sudoers/root (entirely unnecessary, I need to fix that)
• Webserver/sudo approach (could be dropped entirely with some effort)

A syscall-filtering eBPF tool like bubblewrap could also be utilised to heavily limit the syscalls that Chromium can run. There's a ton of syscalls which Chromium just doesn't need to run. Disabling kernel features like io_uring, etc. is probably worthwhile, too.

Most (feasible) attacks against the system boil down to 2 categories:

• Network-based attacks (ARP spoofing, fake DHCP, rouge SLAAC, etc.)
• Malicious website being surfed to

In my usage of AnotterKiosk, the website being displayed is fixed, but this might not be the case in all applications. I'm also reasonably confident that network-based attacks alone would not do anything helpful for exploiting the AnotterKiosk. All URLs used are HTTPS and an attacker would need to present a valid certificate for my domains in order to deliver malicious code.

Even when manually surfing to a malicious website, an attacker would need to have a Chromium (probably V8) exploit, sandbox escape and then something to do a local priviledge escalation (all of that on a read-only system, so that they can remount the root-fs as writable). While things like that have certainly happened in the past, I'm not aware of a single public exploit chain like that, so the attacker would need to be highly skilled. All publicly available Chrome(ium) exploits seem to only have x86 bytecode and are lacking Arm64 code (and probably need to be changed heavily, if Arm64 is affected at all).

Summarising: There's a lot of potential for security improvements, I think the biggest might be had by implementing a good auto-updater feature with A/B partitions and some way to trigger automatic CI builds when new Chromium and Linux kernel versions are released. I'm really not worried about someone exploiting the Chromium itself, otherwise I'd need to stop surfing the web itself.

If you're faced with a particular threat model, I'd love to hear about it. Maybe there's something I've overlooked entirely.

So long Manawyrm

[FlurryNight]

Hi,

I'm honestly a bit surprised about the request to move to Rocky Linux right now, especially amidst the whole Red Hat licensing debacle. Personally, I've been a Debian user for the last 20 years (on server systems) and a ArchLinux user for the past 10 years (mostly on desktop machines), but I'm lacking any professional experience using RHEL-based systems.

Funnily enough, a while ago I was looking for a similar approach to debootstrap for RHEL-based systems and could only find the "rinse" project, which was also developed by Debian (but targets only RHEL).

I don't personally see any stability concerns using the Debian stable distribution. debian-security always includes the current Chromium versions and the rest of the system is ... well, Debian 😄

A real issue for reliability and stability is the Raspberry Pi kernel and userland, which I'm including by using their image. That's certainly not known for being reliable or dependable in any way, but it's what we've got (especially when we want to have hardware acceleration). Running a mainline kernel for this application has proven to be wonky at best.

For additional security, we'd have to talk about threat models. With the current system, I do see some issues:

• SSH is available publicly (0.0.0.0), could be bound to AutoSSH only (optionally, in a hardened mode)
• NTP safety
• pi user being in sudoers/root (entirely unnecessary, I need to fix that)
• Webserver/sudo approach (could be dropped entirely with some effort)

A syscall-filtering eBPF tool like bubblewrap could also be utilised to heavily limit the syscalls that Chromium can run. There's a ton of syscalls which Chromium just doesn't need to run. Disabling kernel features like io_uring, etc. is probably worthwhile, too.

Most (feasible) attacks against the system boil down to 2 categories:

• Network-based attacks (ARP spoofing, fake DHCP, rouge SLAAC, etc.)
• Malicious website being surfed to

In my usage of AnotterKiosk, the website being displayed is fixed, but this might not be the case in all applications. I'm also reasonably confident that network-based attacks alone would not do anything helpful for exploiting the AnotterKiosk. All URLs used are HTTPS and an attacker would need to present a valid certificate for my domains in order to deliver malicious code.

Even when manually surfing to a malicious website, an attacker would need to have a Chromium (probably V8) exploit, sandbox escape and then something to do a local priviledge escalation (all of that on a read-only system, so that they can remount the root-fs as writable). While things like that have certainly happened in the past, I'm not aware of a single public exploit chain like that, so the attacker would need to be highly skilled. All publicly available Chrome(ium) exploits seem to only have x86 bytecode and are lacking Arm64 code (and probably need to be changed heavily, if Arm64 is affected at all).

Summarising: There's a lot of potential for security improvements, I think the biggest might be had by implementing a good auto-updater feature with A/B partitions and some way to trigger automatic CI builds when new Chromium and Linux kernel versions are released. I'm really not worried about someone exploiting the Chromium itself, otherwise I'd need to stop surfing the web itself.

If you're faced with a particular threat model, I'd love to hear about it. Maybe there's something I've overlooked entirely.

So long Manawyrm

Hey, Okay, no worries. I think to rocky linux is okay, they are a red hat partner ,other rhel based distros dunno..

I've found this the other day: https://github.com/serhepopovych/rhbootstrap

Alright.

Oh okay.

Exactly, i ve noticed u started creating issues regarding that, nice of you!.

I agree with what u said, all of it should be done

Thanks for your words.

Cheers