Vogtinator
Joined 10 years ago
Karma
947
Submissions
295
Member since
Nov 9
Recent submissions
Comment · 2 months ago
Comment · 6 months ago
> If, for example, a company wants to issue fleet computers to workers or school to students, you want to have secure boot on those devices to prevent tampering. Secure boot makes it so that physical access is not the end all of security.
Measured boot is actually better for that: You can still boot whatever you want however you want, but hashes are different which can be used for e.g. remote attestation. Secure boot has to prevent that "unauthorized" code (whatever that means for each setup) can ever run. If it does, game over. That means less freedom and flexibility.
Comment · 7 months ago
AFAIK that's just when plugging in a USB 3 device into a USB 2 port or using a USB 2 cable.
Comment · 7 months ago
With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
Comment · 1 year ago
> For example, Aeon (of openSUSE MicroOS vintage) looks like all KDE Linux is aiming for, just with Gnome as DE.
And Kalpa is that just with Plasma as DE.
Comment · 1 year ago
swapfile on linux must be directly mapped, bypassing any filesystem level checksums (see https://btrfs.readthedocs.io/en/latest/Swapfile.html)
Comment · 1 year ago
ctrl-c sends SIGINT.
Comment · 1 year ago
errno is in thread-local storage (TLS)
Comment · 1 year ago
> Apps on Android have no access, or ability, to directly call kernel functions.
That is nonsense.
Comment · 1 year ago
That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
Comment · 1 year ago
> You can mitigate this by including PCRs that sign the kernel and initrd.
No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.
> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. > Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
Comment · 1 year ago
For multiple users on the same server it was IMO well designed. Everyone had their ~ and could place whatever libraries/binaries/etc. in there and do whatever they wanted.
Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.
FUSE doesn't really relate to single vs. multi-user AFAICT.
Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.
Comment · 1 year ago
For x86 cores this is visible in Agner Fog's instruction performance tables: https://agner.org/optimize/#manuals
The latency shows after how many cycles the result of an instruction can be consumed by another, while the throughput shows how many such instructions can be pipelined per cycle, i.e. in parallel.
On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.