The latest Devuan release has this little tidbit in the release notes:
With further explanation at https://git.devuan.org/devuan-packag...e102bd225a511e :
This makes machine-id unique to each running instance of the OS on the machine.

I can't vouch for any security implications, as I don't know how one could "spoof" a D-Bus machine-id remotely. But looking through the Slackware init scripts, it would be pretty easy to mimic Devuan's new behavior, simply by deleting /var/lib/dbus/machine-id, after stopping D-Bus, in rc.6 and rc.0:
On the next boot, rc.messagebus will automatically re-create it, with a new ID.

Excuse my ignorance, but how can be spoofed remotely a local service like DBUS? And even if you manage this, you get what? considering that that DBUS has its own authentication methods for its clients?

Maybe they expose somehow the DBUS to network and this trick could have some value for Devuan, but I doubt its usefulness for Slackware or any other sane distribution...

1 members found this post helpful.

There are related conversations online. Opinions vary whether the file contents are a meaningful security or privacy risk.

Poking around the web indicates the file was introduced in 2006. That means the file has been in use for 13 years.

dbus expects this file and expects legitimate contents rather than zero or sym linking to /dev/null. The file is used in Slackware as can be seen in $HOME/.dbus/session-bus. The dbus-uuidgen man page explicitly warns against modifying the file contents.

If the file is deleted the contents will be regenerated in rc.messagebus: /usr/bin/dbus-uuidgen --ensure.

There are other ways software could fingerprint any system. For security or privacy concerns, probably the best that can be established is regenerating at each boot. In Slackware that means using rc.local_shutdown to modify the contents and letting rc.messagebus to repopulate.

1 members found this post helpful.

I have noticed that when starting Chrome (rebuilt from an offcial binary) I got an error message about an invalid value in /etc/machine-id. I could get rid of this messag with this command:Which means that the browser can easily track my activity as this is an UUID.

So, either do not set it at all or change it often (at boot time or in a cron job) if want to make harder to spy you.

To know more: https://www.freedesktop.org/software...achine-id.html

1 members found this post helpful.

So, for Slackware users that use Chrome, re-generating the machine-id during boot is probably a good idea for online privacy.

Should machine-id regeneration be the default Slackware behavior? Is there any reason for regular* Slackware users to keep a persistent machine-id?

(*)That includes users like me who run -current, even with a few tweaks.

1 members found this post helpful.

Running without dbus is a hobby for some Devuan users, which I think is great.

I stopped using PDF viewers that demand machine-id exist.

Not sure whether this is actually a risk or not. I just think it's stupid. Any design that requires me to have a unique ID like that, I really don't want if I can help it. Never needed it years ago, can't figure out why I should entertain it now. It's not like there are any highly technical people interested in helping me make a very informed decision about this, so I'll just err on the side of "This isn't the sort of feature I like." It's my computer, so I get to decide.

1 members found this post helpful.

Come on! Let's do NOT put the tinfoils...

For example, a rougue program can also well to hash the content of "/etc/os-release" and its creation timestamp to create a quite unique fingerprint.

Anyways, there are tons of other ways for a rougue program to fingerprint you. And what stops this rogue program to generate and store locally its own UUID?

3 members found this post helpful.

Since when the Devuan's nuts devs had been become the poster children of Linux security?

2 members found this post helpful.

That isn't a case against machine-id regeneration. Rogue programs store their data (including UUID's) in available rogue locations.

Do you have a reason why /var/lib/dbus/machine-id should not get a new value at every system boot?

I think that the main point of his discourse against this machine-id regeneration is that that's useless.

3 members found this post helpful.

No in my opinion. This setting belongs to the end user or admin, depending on the context and use case.

There can be, depending of the context, and of the kind of "regular" user. For instance, an admin of many servers may want to use that to monitor them using this feature. On the other hand, users of a personal computer they own may not want that.

1 members found this post helpful.

... the game is already lost.

The output of this alone is likely enough to uniquely identify you: stat -c %W /, and it's not as if you can prevent programs from calling stat().


If you want privacy, the only solution is to not run privacy invading code. The absence of a dbus machine-id buys you little.

3 members found this post helpful.

I think this comes down to Slackware's philosophy. And that philosophy is to deliver packages as upstream intends, barring major issues.

Having machine-id being static seems to be upstream's default, so unless you can point to a specific CVE, I doubt this will be changed by Pat and team.

If a user wants to change this, then they are given the ability due to Slackware's willingness to let users be their own admin!

1 members found this post helpful.

To my understanding, the contents of machine-id does not need to be permanent. The file just needs to exist and contain legitimate contents. Regenerating should not impact dependent apps. Deleting the file in /etc/rc.d/rc.local_shutdown should suffice as rc.message will regenerate.

Not to shrug but any app or service from Don't Be Evil Google is long known not to respect privacy.

Share the list please?

I have read the file may be used by some DHCP clients.

Perhaps a simple community experiment. While rc.message ensures the file contents, something in rc.local could delete the file. Then see what breaks during the day.

The code has existed since 2006. While I expect anything from Don't Be Evil Google to use mechanisms like this to violate privacy, I have not read of anything else that does.

Agree. I don't expect Pat to spend energy working around this.

With some idle moments I fiddled with /var/lib/dbus/machine-id and not regenerating the file. Deleting the file, setting to zero size, or 32 zeroes results in X not launching with startx.

The dbus-uuidgen man page states:

"The important properties of the machine UUID are that 1) it remains unchanged until the next reboot and 2) it is different for any two running instances of the OS kernel."

The first condition implies that regenerating at each boot is safe.

As dbus is for IPC and not interhost communication, a sweet summer child view is the file should not be used by other software for non IPC purposes.

Yet since the location of the file is well known, nothing stops other software from using the file as a fingerprint. Regenerating at each boot probably throws some sand into data mining and tracking gears, but even Slackware uses and needs the file.

1 members found this post helpful.