Earlier quoted context omitted.
Sure, but how do you know what programs are misusing it?
auditd(8)
Devuan considers machine IDs
41–50 of 76 posts
Re: Devuan considers machine IDs
#42How about making it a symlink to a kernel feature:
/etc/machine-id -> /proc/some/path/machine-id
Re: Devuan considers machine IDs
#43OK, from the man page: > The /etc/machine-id file contains the unique machine ID of the local system that is set during installation. The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16-byte/128-bit value. > The machine ID is usually generated from a random source during system installation and stays constant for all subsequen…
So basically deleting the file as the last step before a shut down or reboot will work, is that correct?
Re: Devuan considers machine IDs
#44Why would anyone worry that applications like chrome abuse that file? If chrome wants a unique identifier it could generate it itself.
Revisiting this, I agree that there's quite some "meh" about this. I mean, there's no way to really know how machines have and share identifiers. So one must assume that they have, and do. And deal with it.
VMs seem generally good enough. But then there's WebGL, which generates identifiers based on the host graphics system and guest virtual video driver. So all Debian VMs on a given host have the same identifier.
If it really matters, though, you gotta use different hardware.
Re: Devuan considers machine IDs
#45Earlier quoted context omitted.
I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. Interestingly for Windows they pull the machine id from the registry[1] and (at first glance) it doesn't seem like they're doing any hashing. The raw value gets used. Haven't checked if the value gets sent externally but based upon the comment…
> I checked the Chromium source and for Linux they explicitly mention not being allowed to send it externally[0]; they hash it via SHA1, encode it as base64, and use that value. /etc/machine-id seems to be a random value. What purpose does hashing it before sending it do? The hash should still uniquely identify a machine. Am I missing something? Kind of makes me think that it's just done so people say "it's ok, becau…
> Am I missing something?
The source code links https://www.freedesktop.org/software/systemd/man/machine-id.... mentions hashing using an "application-specific key", which would at least make it not correlatable between different apps (so $WEBSITE can't correlate machine IDs with $WELL_BEHAVED_APP 's machine IDs.)
But either I'm missing something, or Chromium is - it looks like it's straight up hashing the file and not actually using any application-specific keys!
Re: Devuan considers machine IDs
#46Earlier quoted context omitted.
apt doesn't know about any file the application might have ever created in your home directory.
Actually, apt does a pretty good job at finding stuff. Sometimes it can't delete, but it warns you about that.
Apt only knows about the files that are listed in the package.
Re: Devuan considers machine IDs
#47Earlier quoted context omitted.
That's basically how smartphones do it. The problem is still that the granularity is not right (except for users who simply want to trust the application). For example, when uploading a photo, I don't want to give Facebook access to my entire filesystem, just the photo that I click. And I don't want to give Facebook access to my camera indefinitely, just now. It will require a lot of design to get security right with…
> I don't want to give Facebook access to my entire filesystem, Android's systems of intents and changing how storage security works in Android Q will help with this somewhat. They start expressly prohibiting access to the full filesystem and images and other intent extras must be passed through the intent call, rather than a reference to it on the filesystem.
That sounds great. But what I really want is if the app does want access to the entire filesystem, then the OS will present the app with a sandboxed filesystem, instead of just blocking the app (causing the app to refuse to work, which is what will happen in practice).
Re: Devuan considers machine IDs
#48A random machine-id doesnt help. Use a static number instead such as 1111111111111111111111111111111111111111
Re: Devuan considers machine IDs
#49Earlier quoted context omitted.
Actually, apt does a pretty good job at finding stuff. Sometimes it can't delete, but it warns you about that.
Apt only knows about the files that are listed in the package.
Sure, but then that means that honest packages should document all files that the software can be configured to created automatically. Or at least, all but user-specified ones.
Re: Devuan considers machine IDs
#50OK, from the man page: > The /etc/machine-id file contains the unique machine ID of the local system that is set during installation. The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16-byte/128-bit value. > The machine ID is usually generated from a random source during system installation and stays constant for all subsequen…
So basically deleting the file as the last step before a shut down or reboot will work, is that correct?
I'll test that.
Edit: OK, so I created a Debian VM, noted /etc/machine-id, deleted it, and rebooted. And found that it was still missing.
Running systemd-machine-id-setup generated a new machine-id from the D-Bus machine ID. And it was the same as the initial one.
But I also see in man machine-id:
> The machine-id may also be set, for example when network booting, by setting the systemd.machine_id= kernel command line parameter or passing the option --machine-id= to systemd. A machine-id may not be set to all zeros.