Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devuan considers machine IDs

distrowatch.com

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Devuan considers machine IDs

#51

Post by LukeShu »

kazinator wrote: post #42

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.

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)

Re: Devuan considers machine IDs

#52

Post by patrickg_zill »

mirimir wrote: post #50
patrickg_zill wrote: post #43

Earlier quoted context omitted.

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 lin…

Does something like

dd if=/dev/urandom bs=1 count=16 | hexdump

Give you something that you can use?

Re: Devuan considers machine IDs

#53

Post by tinus_hn »

mirimir wrote: post #7

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 subsequen…

Because then Google doesn’t have a persistent identifier to track you, of course.

Re: Devuan considers machine IDs

#54

Post by kazinator »

LukeShu wrote: post #51
kazinator wrote: post #42

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.

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…

> it is necessarily something that would live in the filesystem, independent of the kernel.

Counterexample: struct utsname and the uname system call.

Re: Devuan considers machine IDs

#55

Post by mirimir »

patrickg_zill wrote: post #52
mirimir wrote: post #50

Earlier quoted context omitted.

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 lin…

Does something like dd if=/dev/urandom bs=1 count=16 | hexdump Give you something that you can use?

Well, the machine-id of that Debian VM was ...

    38d05397c25548b4f4bda7751b5062
... and ...

    $ FOO=`cat /dev/urandom | tr -dc a-z0-9 | head -c${1:-30}`
    $ echo $FOO
      6we4gvnmx00w208ffty6i11m82rw6d
But I have no clue whether systemd would be happy with that. Maybe later I can test more.

Edit: Oops. Make that ...

    $ FOO=`cat /dev/urandom | tr -dc abcdef0-9 | head -c${1:-30}`
    $ echo $FOO
      b486935dbb9e9fe603328a19e2b5b4

Re: Devuan considers machine IDs

#56

Post by LukeShu »

kazinator wrote: post #54
LukeShu wrote: post #51

Earlier quoted context omitted.

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…

> it is necessarily something that would live in the filesystem, independent of the kernel. Counterexample: struct utsname and the uname system call.

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.

Re: Devuan considers machine IDs

#57

Post by amaccuish »

amelius wrote: post #34
koolba wrote: post #31

Earlier quoted context omitted.

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…

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…

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

FYI that's exactly how iOS does it. When you choose a picture to upload from the camera roll, the target app only gains access to that one photo.

Re: Devuan considers machine IDs

#58

Post by 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}'

Re: Devuan considers machine IDs

#59

Post by kazinator »

LukeShu wrote: post #56
kazinator wrote: post #54

Earlier quoted context omitted.

> it is necessarily something that would live in the filesystem, independent of the kernel. Counterexample: struct utsname and the uname system call.

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.

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.

Re: Devuan considers machine IDs

#60

Post by [deleted] »

mirimir wrote: post #55
patrickg_zill wrote: post #52

Earlier quoted context omitted.

Does something like dd if=/dev/urandom bs=1 count=16 | hexdump Give you something that you can use?

Well, the machine-id of that Debian VM was ... 38d05397c25548b4f4bda7751b5062 ... and ... $ FOO=`cat /dev/urandom | tr -dc a-z0-9 | head -c${1:-30}` $ echo $FOO 6we4gvnmx00w208ffty6i11m82rw6d But I have no clue whether systemd would be happy with that. Maybe later I can test more. Edit: Oops. Make that ... $ FOO=`cat /dev/urandom | tr -dc abcdef0-9 | head -c${1:-30}` $ echo $FOO b486935dbb9e9fe603328a19e2b5b4

[deleted]
Post reply on HN