manawyrm / anotterkiosk Goto Github PK

With the current Raspberry Pi images being downloaded, the pi user is allowed to call sudo nopasswd.
This isn't required for anything and is a pretty unnecessary security risk.
Administrative tasks can be done using SSH login as root.

x86 images are probably not affected (as the pi user is being created newly and shouldn't be in the sudoers/wheel group)

See #2 (comment)

From Linux 6.6, it's possible to disable io_uring with a new kernel sysctl.
https://www.phoronix.com/news/Linux-6.6-sysctl-IO_uring
This will take a while until it's available in Debian and the Raspberry Pi kernel.

https://www.phoronix.com/news/Google-Restricting-IO_uring

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!

Similar to AutoSSH, it would be very nice and useful to have Wireguard tunneling support.
This could even extend to routing the default gateway through the tunnel, in order to allow for access to private websites and/or internal systems.

It would require some sort of DNS resolve cronjob as Wireguard isn't capable of handling that itself and it would probably also require some sort of external tunnel watchdog.

See #2 (comment)

Having a hardened network mode for untrusted networks, where things like SSH being reachable from the network (instead of only via autossh) are disabled might be useful.

See #2 (comment)

bubblewrap is a nice little sandboxing tool, which (amongst other things) allows users to filter syscalls of a process.
The Chromium process could be limited to a very small number of syscalls, limiting the attack surface against the linux kernel.

A successful exploit would then need:

• a Chromium exploit (V8, etc.)
• a sandbox escape
• bubblewrap escape (with limited syscalls from a non-privileged user)
• Linux kernel local privilege escalation (from user to root/kernel)

Currently, the www-data user (and nginx/webserver) is being able to sudo to the root user.
This still requires an exploit in the (relatively small amount of) PHP code on the system, but other issues in PHP-FPM or nginx might endanger the system here.

It's not required to have sudo permissions, if the system statistics reporting would be done by an external service.

See #2 (comment)

https://github.com/rauc/rauc