/proc/sys/kernel/random/boot_id doesn’t exist on Whonix for me but it does exist on my host (Arch). Even if it did exist, I assume it’s random as it’s in a directory called “random”.
/ proc / sys / kernel / random / boot_id no existe en Whonix para mí, pero sí existe en mi host (Arch). Incluso si existiera, asumo que es aleatorio ya que está en un directorio llamado “aleatorio”.
3 Likes
It turns out, the boot ID is a thing. Running hostnamectl shows a unique “Boot ID” that’s changed each reboot.
Running journalctl --list-boots gives you the boot ID of every past session (as long as persistent journal logs are enabled).
It seems like this is useful for getting the logs of specific past sessions as you can use journalctl --boot=id.
I’m not sure how this can be set to the same for each boot session for every Whonix user or even if it’s worth doing.
1 Like
The boot ID is set in /proc/sys/kernel/random/boot_id (dunno why I couldn’t find it before) and that can be changed with sysctl.
Maybe, it’d be possible to create a file in /etc/sysctl.d with
kernel.random.boot_id=b08dfa60-83e7-567a-1921a715000001fb
Although, I’ve tried this and it didn’t work.
1 Like
Dunno either. To get more brain power processing this question it’s always worth asking on the tor-talk mailing list and/or reporting bugs against Tails.
1 Like
I can’t find anything about changing the boot ID which makes me think it isn’t possible so we’d probably need to make a bug report of some package. Since the ID is in /proc/sys (a directory containing kernel tunables), it’d probably have to be a bug report against the kernel.
There’s also /proc/sys/kernel/random/uuid but this changes every time you try to check what’s in it so it doesn’t seem like a problem.
1 Like
Actually, an extremely hacky way to hide these would be to bind mount a file on top of it.
For example, we can create a systemd service that runs
mount --bind /etc/machine-id /proc/sys/kernel/random/boot_id
Then the boot ID should be the same as /etc/machine-id.
Since this doesn’t properly change the ID, the actual boot ID may be found out through other means e.g. journalctl although journalctl isn’t available to the user user (it’s not part of the required groups) so this might be somewhat effective at hiding the boot ID from unprivileged attackers.
1 Like
This looks to me like a feature. Any program/script requiring an uuid can use that as API.
Remember the Debian OpenSSL bug: maintainer thinks “random something - I don’t like that - nuke it” and then all OpenSSL keys created on Debian were weak. Upstream needs to be consulted.
2 Likes
Exactly! We need o find out why upstream wanted this feature to begin with.
1 Like
I’m pretty sure the boot ID is only used for filtering journal logs for specific past boots or something to do with emacs.
I’ve found these two links that talk about changing the boot IDs for containers.
https://lists.linuxfoundation.org/pipermail/containers/2012-August/030168.html
https://bugzilla.redhat.com/show_bug.cgi?id=854604
There weren’t really any objections except people who didn’t think it was a kernel bug or people who didn’t think it would be useful. No “this will break everything” messages.
Lennart Poettering suggested to overmount the file in userspace.
Overmounting the boot id in userspace is very easy, so I’d suggest doing this all in userspace where necessary.
This message says why the boot IDs can be useful Virtualizing /proc/sys/kernel/random/boot_id per container ?
SystemD records log messages for all system services in their journal. They can show you all log messages for the current service execution, all log messages for a service since system boot, or all log messsages ever. The boot_id value is used as a unique tag to allow grouping of the log messages per system boot. When we run systemd inside a container we want to get that grouping of log messages generated by services inside the container, to take account of the container boot, not the host boot. Hence the desire to have the boot_id value reflect when a container is booted.
1 Like
/proc/sys/kernel/random/boot_id: A random ID that is regenerated on each boot. As such it can be used to identify the local machine’s current boot. It’s universally available on any recent Linux kernel. It’s a good and safe choice if you need to identify a specific boot on a specific booted kernel.
1 Like
We can create a systemd service with Before=systemd-journald.service to run it before the systemd logs are created so the actual boot ID won’t be stored in the logs.
But, this breaks a whole bunch of things, likely because systemd-journald.service is getting started too late.
1 Like
I can confirm that on a regular Debian Buster installation, hostnamectl run in terminal returns a whole suite of values: static-hostname, icon name, chassis, machine id, boot id, kernel, operating system and architecture.
I followed those links you posted and found them very helpful to explain what the values like boot id mean.
2 Likes
We can fix this with apparmor-profile-everything but that might break too many things.
1 Like
hi guys, there are still parts that need to be activated, an attacker is able to know more information about your hardware .
/proc/version // version OS
/proc/sys/kernel/ostype // type OS
/proc/sys/kernel/osrelease // Information OS
/run/udev/data/+pci:0000:00:00.0 // Processor / GPU name
/run/udev/data/+pci:0000:00:02.0 // Display info / GPU
/proc/sys/kernel/random/boot_id // boot id
/run/udev/data/+dmi:id // Motherboard info
/run/udev/data/+input:input3 // keyboard
/run/udev/data/+input:input4 // mouse
/run/udev/data/+pci:0000:00:1b.0 // sound1
/run/udev/data/+sound:card0 / sound2
in turn they could obtain information online for Tor
since each user has a unique hardware