LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-30-2019, 03:09 PM   #1
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 218

Rep: Reputation: Disabled
security implications of /var/lib/dbus/machine-id. Thoughts?


The latest Devuan release has this little tidbit in the release notes:
Quote:
dbus patch to generate new dbus machine-id on boot. This behavior is configurable in /etc/default/dbus
With further explanation at https://git.devuan.org/devuan-packag...e102bd225a511e :
Quote:
In theory, the machine-id should be a persistent identifier of the current host. In practice, this causes some privacy concerns. As a consequence, in Devuan the dbus machine-id is recreated at each boot.
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:
Code:
# Stop D-Bus:
if [ -x /etc/rc.d/rc.messagebus ]; then
  /etc/rc.d/rc.messagebus stop
  rm -f /var/lib/dbus/machine-id
fi
On the next boot, rc.messagebus will automatically re-create it, with a new ID.
 
Old 11-30-2019, 03:24 PM   #2
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 373

Rep: Reputation: 340Reputation: 340Reputation: 340Reputation: 340
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...

Last edited by ZhaoLin1457; 11-30-2019 at 03:29 PM.
 
1 members found this post helpful.
Old 11-30-2019, 06:32 PM   #3
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS
Posts: 1,328

Rep: Reputation: Disabled
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.
Old 11-30-2019, 07:04 PM   #4
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,107

Rep: Reputation: Disabled
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:
Code:
dbus-uuidgen --ensure=/etc/machine-id
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.
Old 11-30-2019, 09:02 PM   #5
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 218

Original Poster
Rep: Reputation: Disabled
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.
Old 11-30-2019, 09:35 PM   #6
freemedia2018
Member
 
Registered: Mar 2019
Distribution: various automated remasters
Posts: 181
Blog Entries: 2

Rep: Reputation: 156Reputation: 156
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.

Last edited by freemedia2018; 11-30-2019 at 09:41 PM.
 
1 members found this post helpful.
Old 11-30-2019, 10:41 PM   #7
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 373

Rep: Reputation: 340Reputation: 340Reputation: 340Reputation: 340
Quote:
Originally Posted by Didier Spaier View Post
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:
Code:
dbus-uuidgen --ensure=/etc/machine-id
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
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?

Last edited by ZhaoLin1457; 11-30-2019 at 11:02 PM.
 
3 members found this post helpful.
Old 11-30-2019, 10:47 PM   #8
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 373

Rep: Reputation: 340Reputation: 340Reputation: 340Reputation: 340
Quote:
Originally Posted by freemedia2018 View Post
Running without dbus is a hobby for some Devuan users, which I think is great.
Since when the Devuan's nuts devs had been become the poster children of Linux security?

Last edited by ZhaoLin1457; 11-30-2019 at 11:09 PM.
 
2 members found this post helpful.
Old 11-30-2019, 11:40 PM   #9
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 218

Original Poster
Rep: Reputation: Disabled
Quote:
what stops this rogue program to generate and store locally its own UUID?
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?
 
Old 12-01-2019, 12:01 AM   #10
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 475

Rep: Reputation: 289Reputation: 289Reputation: 289
Quote:
Originally Posted by gus3 View Post
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.
Old 12-01-2019, 01:41 AM   #11
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,107

Rep: Reputation: Disabled
Quote:
Originally Posted by gus3 View Post
Should machine-id regeneration be the default Slackware behavior?
No in my opinion. This setting belongs to the end user or admin, depending on the context and use case.

Quote:
Is there any reason for regular* Slackware users to keep a persistent machine-id?
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.

Last edited by Didier Spaier; 12-01-2019 at 04:08 AM.
 
1 members found this post helpful.
Old 12-01-2019, 05:32 AM   #12
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,298
Blog Entries: 18

Rep: Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063Reputation: 3063
Quote:
Originally Posted by upnort View Post
There are other ways software could fingerprint any system. For security or privacy concerns...
... 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.
Old 12-01-2019, 06:10 AM   #13
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,279

Rep: Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028Reputation: 4028
Quote:
Originally Posted by gus3 View Post
Should machine-id regeneration be the default Slackware behavior?
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.
Old 12-01-2019, 12:02 PM   #14
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS
Posts: 1,328

Rep: Reputation: Disabled
Quote:
Do you have a reason why /var/lib/dbus/machine-id should not get a new value at every system boot?
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.

Quote:
So, for Slackware users that use Chrome, re-generating the machine-id during boot is probably a good idea for online privacy.
Not to shrug but any app or service from Don't Be Evil Google is long known not to respect privacy.

Quote:
I stopped using PDF viewers that demand machine-id exist.
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.

Quote:
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.
Agree. I don't expect Pat to spend energy working around this.
 
Old 12-01-2019, 06:57 PM   #15
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS
Posts: 1,328

Rep: Reputation: Disabled
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] hostnamectl not working, system_bus_socket in /run/dbus not in /var/run/dbus hieberm CentOS 1 05-23-2018 08:44 AM
What are the implications of moving /var/log/packages to other folder? mlpa Slackware 10 10-14-2014 01:12 PM
dbus "rm /var/run/dbus/Desktop can't remove..." longus Slackware 6 12-15-2008 04:33 AM
Fedora Core 9 update dbus.exception & dbus.proxies & DBus.Error.AccessDenied errors trien27 Fedora 1 12-09-2008 12:23 AM
Compromised? Files "/usr/lib.hwm", "/usr/lib.pwd", "/usr/lib.pwi" Klaus Pforte Linux - Security 4 09-29-2004 12:33 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:06 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration