
Devuan considers machine IDs - tomkat0789
https://distrowatch.com/dwres.php?resource=showheadline&story=7816
======
nickysielicki
If a file on your computer is being used by a program to send information to
someone, the answer isn't to destroy/randomize the file and break other
applications, the answer is to not use the program that is sending your
information somewhere.

~~~
mirimir
Sure, but how do you know what programs are misusing it?

~~~
btown
This speaks to a more general need for user-friendly audit logs of which
resources are accessed by which programs. I should be able to tell on any
platform if Spotify called fopen on something in my documents folder.

~~~
auslander
SELinux or app-armor, keep it in enforcing mode.

------
swinglock
Removing it just makes it more difficult to write legit programs that has use
of such features while anything nefarious will be able to find other things to
use as fingerprints, including hardware serials, MACs and their own
fingerprint files spread across the filesystem in non-standard locations.

Unless the OS is meant to be built for privacy and has a goal to run every app
in a sandbox where nothing is fingerprintable, removing easily available
fingerprintes would be a disservice to all.

~~~
JohnFen
> Removing it just makes it more difficult to write legit programs

Yeah, that's something I simply could not care less about.

That said, I don't remove it. I set its permissions so that it isn't world-
readable instead.

~~~
swinglock
Why?

------
mirimir
OK, 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 subsequent boots. Optionally, for
> stateless systems, it is generated during runtime at early boot if it is
> found to be empty.

So if that works for "stateless systems", why can't all machines be "stateless
systems"?

~~~
patrickg_zill
So basically deleting the file as the last step before a shut down or reboot
will work, is that correct?

~~~
JdeBP
Incorrect.

Machine IDs are stored in several places, some of which are not even files.

* [http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xm...](http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xml#STORAGE)

They can be resurrected if not all storage locations are dealt with. Moreover,
some systems use things like the SMBIOS product UUID.

* [http://jdebp.uk./Softwares/nosh/guide/commands/setup-machine...](http://jdebp.uk./Softwares/nosh/guide/commands/setup-machine-id.xml#FALLBACKS)

The correct approach is not deleting files.

* [http://jdebp.uk./Softwares/nosh/guide/commands/erase-machine...](http://jdebp.uk./Softwares/nosh/guide/commands/erase-machine-id.xml)

* [https://lists.debian.org/debian-user/2019/03/msg00550.html](https://lists.debian.org/debian-user/2019/03/msg00550.html)

~~~
mirimir
Thanks.

So at boot, one would run "erase-machine-id". Then create a random
30-character hexadecimal number. And then either set "the systemd.machine_id=
kernel command line parameter" to it. Or pass it via "the option --machine-id=
to systemd".

~~~
JdeBP
No.

    
    
        % system-control cat machine-id
        start:#!/bin/nosh
        start:true
        stop:#!/bin/nosh
        stop:envdir env
        stop:erase-machine-id
        run:#!/bin/nosh
        run:#Set up and tear down the machine ID
        run:envdir env
        run:setup-machine-id
        restart:#!/bin/sh
        restart:exec false      # ignore script arguments
        %

~~~
mirimir
OK, thanks.

So "setup-machine-id". Does that generate a value that's unrelated to any
preexisting versions, analogs, etc?

I ask because, when I deleted /etc/machine-id and ran "systemd-machine-id-
setup", it generated a new machine-id by copying the D-Bus machine ID.

------
salawat
What is it with the fetish for inflicting Truenaming in cyberspace?

It's incredibly annoying. It needlessly bloats digital footprints, and it
creates an opportunity for exploitation by nefarious actors.

Leave the Truenaming to the User's that need it. It doesn't do any good being
baked in by default. If they really need it, they'll figure out a way to
implement it. If they definitely _cannot_ afford it, and aren't aware it is
there by default, you are doing more harm putting It in than you would be by
leaving well enough alone.

------
jackewiehose
Why would anyone worry that applications like chrome abuse that file? If
chrome wants a unique identifier it could generate it itself.

~~~
mirimir
Because the machine-id by default never changes after OS installation.

~~~
swinglock
Neither does a file Chrome generates. Not even if reinstalled.

~~~
mirimir
Huh?

Even if you do

    
    
        $ sudo apt-get -y purge chrome
    

[or whatever its package name is]?

And if necessary, find and delete everything that it created.

~~~
pantalaimon
apt doesn't know about any file the application might have ever created in
your home directory.

~~~
mirimir
Actually, apt does a pretty good job at finding stuff. Sometimes it can't
delete, but it warns you about that.

~~~
Evidlo
Apt only knows about the files that are listed in the package.

~~~
mirimir
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.

------
morganvachon
Bad title (and I know that fault lies with the source site). At first glance
it reads as if the Devuan team is considering embracing/adopting machine IDs,
which is counter to their philosophy, when in fact they are against unique
identifiers.

------
amelius
Doesn't a MAC address lookup or disk UUID lookup provide similar
fingerprinting capabilities? Even the contents of one's .bashrc file could be
used for fingerprinting.

I mean, if you start blocking one thing, where do you stop?

~~~
koolba
Ideally you work in reverse and only need to grant access to things to which
you want to allow access. Start from zero and let an application provide a
manifest of what it wants to access. Ex:

* Open outbound TCP sockets * Read from $HOME/.config/chromium * Read from /etc/machine-id

It's not a new concept at all and there are multiple approaches for
implementing things like this. Getting mass market adoption is sadly next to
impossible.

~~~
amelius
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 without deteriorating
the UX too much.

But I agree, it's better than simply blocking everything.

~~~
qmarchi
> 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.

~~~
amelius
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).

------
SeriousM
Oh, chromium may break? Then I use an alternative. This is true for any other
program.

~~~
hedora
Or, devuan could arrange to always use 0xfoad or something appropriate if the
file is missing.

Even better, it looks like there has been a file that always has the same
value for a while; presumably they can just keep that in place.

------
squarefoot
Privacy concerns aside, using the boot device serial number might be a better
solution as it can't be deleted or modified and survives reboots and
reinstalls.

This line will find it easily. Not mine, I simply put together the work of
others adding only very small modifications. Needs smartctl (smartmontools
package on Debian) which can be run only by root.

smartctl -i `df -P / | tail -n 1 | awk '/.*/ { print $1 }'` | egrep ^"Serial
Number:" | awk '{print $3}'

------
gvand
Why is it there in the first place?

~~~
geofft
[https://dbus.freedesktop.org/doc/dbus-
uuidgen.1.html](https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html) has some
explanation, in particular:

> _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. That is, if two processes see the same UUID,
> they should also see the same shared memory, UNIX domain sockets, local X
> displays, localhost.localdomain resolution, process IDs, and so forth._

Because it's possible to forward things like D-Bus, the X11 $DISPLAY, etc.
over the network, two processes might be aware of each other over such a
connection but not be running on the same machine and therefore be unable to
share resources. The machine ID lets them check for that, so you can properly
handle things like "I'm going to send a message to the screensaver in my
display to not activate, I don't care if it's the same machine" vs. "I'm going
to send a message to the terminal in my display to open a new tab, but only if
it's actually on the same machine, otherwise I should start a new terminal".
(These days I think that definition should be updated to "container" instead
of "kernel": if you're running separate logical machines inside the same
kernel with separate PIDs etc., they should have separate machine IDs.)

systemd and (IIRC) cloud-init use it to run once-per-machine tasks on machines
that could come from images: if you want to prep a number of machines in
advance, do the install, then change the machine ID. At boot time, startup
scripts will say "Oh, this machine ID has not been initialized yet" and do
things, and then not do them on the next boot.

~~~
LukeShu
_> These days I think that definition should be updated to "container" instead
of "kernel": if you're running separate logical machines inside the same
kernel with separate PIDs etc., they should have separate machine IDs._

Indeed. If that weren't the case, and the "same kernel" were enough, then
things could just use /proc/sys/kernel/random/boot_id.

------
kazinator
How about making it a symlink to a kernel feature:

    
    
       /etc/machine-id -> /proc/some/path/machine-id
    

this fictitious proc entry that I just invented serves up bullshit content to
unprivileged processes, but a true ID to the superuser.

~~~
LukeShu
See also:

    
    
        /proc/sys/kernel/random/boot_id
        /proc/sys/kernel/random/uuid
    

\----

Because the machine-id is intended to be something that persists between
reboots, it is necessarily something that would live in the filesystem,
independent of the kernel.

Your described functionality could be accomplished with a FUSE filesystem,
though.

However, that functionality would be problematic. Programs (like D-Bus) expect
to be able to use it to identify whether 2 communicating processes are on the
same host.

If it served different bullshit to each process, it would be entirely non-
functional. (Sans returning the true ID to root, this is
/proc/sys/kernel/random/uuid)

Perhaps instead, use a determined-at-boot value (as the machine-id(5) docs say
is acceptable for stateless systems). If this is a kernel construct that isn't
associated with a specific (PID?) namespace, then this would also be
problematic, as different containers would be considered to be the same
"host". (Sans returning the true ID to root, this is
/proc/sys/kernel/random/boot_id)

~~~
kazinator
> _it is necessarily something that would live in the filesystem, independent
> of the kernel._

Counterexample: _struct utsname_ and the _uname_ system call.

~~~
LukeShu
That's a good counterpoint.

It would still have to live _somewhere_ in the filesystem, and have a
userspace program load it in to the kernel, just as `utsname.nodename` is
loaded from /etc/hostname.

~~~
kazinator
Yes; that area of the filesystem can be readable only to root. It could also
have other avenues of entry: it could come from the boot firmware via the
kernel command line, or be in a device tree blob or whatever.

------
kazinator
> _some applications, such as the Chromium web browser, may report an error if
> this file is not present_

Not present, or not present _and readable_ to the application?

------
privacyhellusa
A random machine-id doesnt help. Use a static number instead such as
1111111111111111111111111111111111111111

------
CodeArtisan
can't you simply symlink /etc/machine-id to /dev/random?

~~~
wicket
That won't work because /etc/machine-id is supposed to return a 32 character
hex string, but I like the idea. You could do something like this:

    
    
      # rm -f /etc/machine-id
      # mkfifo /etc/machine-id
      # while true; do head -c 16 /dev/urandom | od -A n -x | tr -d ' ' > /etc/machine-id; done &

~~~
wicket
A word of warning. If you try this, make sure the last command is started on
boot and runs before D-Bus! I completely forgot I had done this, and I just
spent a few hours trying to figure out why my system was hanging on boot. It
turns out that D-Bus reads /etc/machine-id on start-up, and naturally by
design, it will wait until it receives data from the named pipe before
proceeding with execution.

