72
Linux has /etc/machine-id and you forgot to setup your init daemon to periodically truncate and regenerate a new machine-id so you can be tracked via user telemetry analytics. (lemmy.ml)
submitted 4 months ago by to c/privacy@lemmy.ml
76 comments fedilink hide all child comments
 

Ultimately, the problem is much bigger than /etc/machine-id since there are dozens of hardware IDs on any PC that can be used by malicious telemetry to silently to uniquely identify and track you, and the only solution to this problem currently is to make sure you really trust any software you use.

Systemd, in particular, acts a lot like malware for Linux because if you try to reset your machine-id a long list of stuff that breaks in in it. You could make a cron script to reset /etc/machine-id every day, but machine-id is so deep in the stack that you'd also have to reboot to ensure it's updated.

you are viewing a single comment's thread
view the rest of the comments
[–] 15 points 4 months ago (48 children)

Flatpaks might be the solution here. Flatpaks run in containers, they might have isolated machine-id already.

Though tbh if you don't trust the apps on your Linux system, you have more to worry about than fingerprinting. Regular executable binaries and system packages have zero isolation, any malware can wreak havoc. Flatpaks are getting there but many apps still ask for permissions they don't need, increasing risk.

For untrusted apps, run them in a browser (if a web-app), a container/distrobox, or a VM.

  • permalink
  • fedilink
  • source
  • hideshow 48 child comments
    •
  • [–] [S] 14 points 4 months ago (44 children)

    The browser itself is one of the biggest vectors of attacks here. Both Chrome and Firefox indirectly via libdbus, read your machine-id. Firefox shares browsing data and other unique info with 'with partners, service providers, suppliers and contractors' including Cloudflare and Google.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 44 child comments
    •
  • [–] 2 points 4 months ago (42 children)

    Well browsers are apps, just like any other app on your system. So the same advice applies. If you don't trust chrome and firefox but you still want to run them, use a container/distrobox/VM. There are plenty of more private browsers though, like Brave or Mullvad Browser.

    Web apps, on the other hand, run inside the browser sandbox, which is an entirely different environment. They don't have access to machineid unless the browser gave it to them, for example via a browser extension. There's still a lot of fingerprinting vectors though, so use Tor Browser or Mullvad Browser, ideally with JS disabled. This website is a great way to check your fingerprint: https://abrahamjuliot.github.io/creepjs/

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 42 child comments
    •
  • [–] [S] 21 points 4 months ago (38 children)

    Browsers aren't just apps, they're effectively platforms which run all kinds of apps you end up accessing online when you visit sites. Since the browser leaks the id to these apps, you're effectively trusting the apps. Sure, you could run your browser in a VM or whatever, but that's missing the point entirely. The real question is why your machine needs to have a unique identifier, and why the fuck it's baked into functionality of systemd which is now replacing the traditional tool chain with a monolith.

    And yes, I'm fully aware of other metadata that the browser leaks, and the fact that people are just starting to talk about that is also a problem. Running with Js disabled or putting a browser in a VM, is not really a solution for vast majority of people. The issue is that we have systems that are designed to enable tracking by default, and you have to jump through hoops to get around that. Telling people here are the hoops isn't really helpful.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 38 child comments
    •
  • [–] 5 points 4 months ago* (last edited 4 months ago) (37 children)

    I'm not familiar with the purposes or history of machine-id, I'd guess that it's just a legacy artifact that can't be easily removed now.

    There's definitely a lot to be desired when it comes to privacy on Linux. Unfortunately Linux was designed before many of the privacy and security best practices became established, which is why is it less secure than modern systems like Android (source). Trying to re-architect Linux at this point would be an insane undertaking. Machine-id is just one thing in a long list that would need to be changed. Nothing wrong with advocating for it, but I just wouldn't expect it to happen for at least 5 years.

    Containers are a modern technology with isolation and security as a core goal from the start. And by now, containers are already deeply integrated into the Linux community, for example look at how the entire Fedora Atomic project (including Bluefin, Aurora, Bazzite) uses container-based infrastructure to build the OS images. So that's why I've been moving towards it as a solution for my privacy needs, and I recommend others look into it as well.

    Edit: rewording some sentences

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 37 child comments
    •
  • [–] [S] 14 points 4 months ago (36 children)

    Systemd was designed long after a lot of these security practices and problems with tracking were well understood. There's very little excuse for it doing a lot of the things it does. Systemd is literally re-architecting how Linux was meant to work originally, and for the worse. I get the impression you're not actually familiar with the history of Linux or Unix philosophy in general.

    Having to put everything into containers is really just a work around bad architecture that keeps being pushed in the Linux world. Containers are useful, and probably the only way to actually keep apps from having too much access to the system at this point, but I don't see why bad architecture should be accepted and then have to be worked around.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 36 child comments
    •
  • [–] 3 points 4 months ago (35 children)

    I get the impression you're not actually familiar with the history of Linux or Unix philosophy in general.

    I've read enough mailing lists and issue trackers to know that they are far more complex than they look on the surface, so I definitely won't claim authority about them.

    Take this one that I found recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

    It's a bug report about Firefox's favicon cache. They started looking into it, but found out that if they fix this bug, it creates fingerprinting risk, so they have to address that as well. And so the issue gets stuck in limbo for like 10 years, and is still open till today.

    Regarding systemd, it had to be built on top of the existing architecture, and more importantly, had to appeal to the Linux community to be adopted, so it couldn't change too much. I assume they have their reasons for depending on machine-id. It might not even be a direct dependency. Maybe it allowed easier adoption by the big players.

    I don't know, and honestly, I don't really care about digging into every single fingerprinting vector (of which there are probably tons more), when I can just use containers. And while using containers might feel like a hack or workaround, if we look at Flatpak, it seems like containers are becoming the framework for app isolation on Linux, similar to what already exists on Android. So it may very well become the official solution to privacy and security on Linux.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 35 child comments
    •
  • [–] [S] 5 points 4 months ago (34 children)

    My point is that systemd did not have to be built at all. It's an abomination that goes directly against the original philosophy of Linux creating a monolithic monstrosity to replace individual and composable programs that used to be the way init works. Now, everything is tied to it and it's become like a cancer in a linux system that's inoperable. The whole system-id problem is just one example of why this is a terrible design.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 34 child comments
    •
  • [–] 4 points 4 months ago (4 children)

    After reading through this whole comment thread, reading this was the last straw. I've been planning my exodus for a while.

    Soon, I shall say "I use Artix, btw".

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 months ago (3 children)

    It's just another person explaining that they could have built a better init system, and literally every programmer was wrong except for them.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 months ago (2 children)

    mate it's a bit rude to necrobump

    also i'm switching to NetBSD now lol

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago* (1 child)

    Lmao hell yeah brother, enjoy your journey

    Also I got here from a recent comment link from another thread

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 4 months ago* (24 children)

    Well I'm not here to argue about systemd in general, that's a far larger topic. All I'll say is that from my experience, systemd felt cleaner than the competitors at the time and created a lot of conventions and standards that are taken for granted today.

    For example, to bring this back to the original topic, another commenter in this thread mentioned that systemd provides an API for generating randomized machine-ids that flatpak utilizes.

    Though flatpak is gaining more dependency on systemd, and I don't think that coupling is necessary, so I've been keeping an eye out in that space.

    Edit: researching a bit more on the topic, there's some interesting comments here about how systemd is not as monolithic as people think

    flatpak is not depending on systemd as a whole, they're depending on a new component called systemd-appd...it is an API + a spec, just like what you're asking for. But it's implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.

    [systemd] not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.

    systemd-appd will likely depend on some but not all of the rest of the systemd system.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 24 child comments
    •
  • [–] [S] 2 points 4 months ago (23 children)

    My view is that systemd was a mistake and I disagree with it on a philosophical level. I see stuff like machine-id getting baked in as a direct extension of this philosophy.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 23 child comments
    •
  • [–] 1 point 4 months ago (22 children)

    Many software decisions are more about strategy than philosophy. Compromising on ideals and principles to gain adoption. As mentioned before, I would not be surprised if dependence on machine-id was simply strategy.

    Systemd might be replaced in future. But currently it's used in all major distros. It's design and ideas will probably inspire whatever replaces it. If they had spent their time clinging to philosophy and ideals rather than making compromises, then they might have never left the ground.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 22 child comments
    •
  • [–] [S] 1 point 4 months ago (21 children)

    I'm not sure what was supposed to be leaving ground in your mind to be honest, or whose strategy you're talking about. Linux used to be a community driven effort rather than some company trying to gain growth. Why is gaining adoption so important all of a sudden when Linux has been around for ages without mass adoption, and it's been doing just fine. Seems like part of the issue is actually commercialization because a lot of the decisions are driven by distros that are backed by companies who do want to make profit off the platform.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 21 child comments
    •
  • [–] 2 points 4 months ago* (20 children)

    Well one reason why adoption matters is network effects. Increased Linux popularity, means that more developers will develop for Linux. At a broader level it means that the ideology and principles of the Linux community, like software freedom and privacy, can produce quality results and products for the masses. That brings more power for the Linux community, and more adoption of their principles.

    On the flipside, if the base Linux experience is mediocre, then nobody will bother developing apps and extensions for it.

    If you are completely happy with Linux the way it is now, then that adoption probably doesn't mean a lot. But I personally think there's a ton more that can be done in the Linux and privacy world

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 20 child comments
    •
  • [–] [S] 1 point 4 months ago (19 children)

    The whole context here is that Linux philosophy and principles are being gutted by companies trying to make a buck off it. In my view, benefits of wide adoption need to be balanced with actually retaining the principles which make Linux a good platform.

    Again, Linux has been around a long time before commercial interests started fucking with it. And I don't think chasing adoption for the sake of it is healthy. I'd rather it grows at its own pace. It's already a big enough community to make it sustainable indefinitely, there's absolutely no rush to gain market share here.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 19 child comments
    •
  • [–] 2 points 4 months ago* (18 children)

    I'm not sure if the principles have been gutted like you say. Fedora, for example, uses systemd, and is supported by the commercial RedHat. And yet it is well regarded in the Linux community, and has firmly stuck to open source and pro-privacy principles. They foster diversity too, like the Fedora Atomic and Universal Blue projects, which make it easy to fork distros and create new ones. Not to mention, Linus Torvalds uses Fedora.

    One could say that Linux is already growing at its own pace. There are some that wish it would move slower, some that wish it would move faster. systemd wasn't forced on distros. in fact Ubuntu fought it for years, since it was created by their competitor after all. Yet Ubuntu still adopted it in the end, so it must have been worth it.

    The way I see it, back in the day, Linux was too fragmented in some areas, and at the same time lacking isolation in others. Systemd standardized and addressed the fragmentation, while containers introduced isolation where needed. The lines are being re-drawn. But I don't think the principles of Linux were compromised that much.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 18 child comments
    •
  • [–] [S] 1 point 4 months ago (17 children)

    I'm not sure who regards RedHat well actually, they've always been doing shitty things like trying to charge for Fedora hence why people ended up forking it as CentOS. They're a poster child for the problems with Linux getting commercialized. Saying Linus uses something is just appeal to authority by the way.

    The problem, once again, is that a lot of the development is now driven by commercial companies like RedHat and Ubuntu that are in it to make money. So, in a way these things are actually pushed on the community because you either adopt them or it becomes increasingly difficult to run software on your distro.

    Fragmentation in init was a real problem, but it could've been solved much better by just creating a common standard for configurations while keeping the original modular design. Systemd approach is very heavy handed, and introduces a whole bunch of new problems which didn't exist. The fundamental Unix principle is having small programs that do a single thing well and that can be composed together. Systemd goes directly against this principle.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 17 child comments
    •
  • [–] 1 point 4 months ago (16 children)

    Saying Linus uses something is just appeal to authority by the way.

    I was giving Linus as an example of a member of the Linux community, and a particularly prominent one at that. There are many indicators that Fedora is well regarded, and that is just one of them.

    you either adopt them or it becomes increasingly difficult to run software on your distro.

    Arguably, systemd made it easier to run software on Linux. The standardization made it easier for devs to write software that worked across distros. Devs didn't have to fight fragmentation in the lower levels and could focus on building platforms on top like Flatpak, which in turn led to even more software and apps available on Linux. It's way easier to find and run software than a few years ago.

    I'm guessing what you were trying to say is that it's harder to find and run software on Linux that doesn't use systemd. That's fair. Just like it's hard to find apps nowadays that don't use web technology, and require something like Electron or Firefox to run. But if we think of systemd as a platform (though I think it's more complicated than that), does it go against the ideals of Linux?

    The fundamental Unix principle is having small programs that do a single thing well and that can be composed together

    First off, I know you didn't say this but I want to just clarify: software principles are different from community ideals. Software principles are a means to an end. And they are often broken. Modular design is hard to get right. Microservices often end up messier than the monolithic approach. Ultimately it's a balance. And strategy plays into this too. If monolithic design allows faster iteration, then even if it gets replaced with modular design later, you can use the lessons learned during those iterations to make the modular design.

    It's possible that someday Redhat tries to weaponize systemd and it ends up holding Linux back until we can replace it. But I doubt it. If you look at the recent backlash that Fedora and Firefox has gotten for AI, you can see that the Linux community is pretty vocal and active about their ideals.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 16 child comments
    •
  • [–] [S] 1 point 4 months ago* (15 children)

    I've already explained repeatedly how systemd goes against core Unix philosophy. Communities can form around all kinds of things, just because a community forms around bad idea that doesn't mean it should be automatically accepted. Linux did get modular design largely right, that's the whole problem here. Systemd throws the baby out with the bath water. Monolithic design was basically more convenient for companies trying to monetize the platform.

    Systemd has gotten plenty of backlash as well, I'm certainly not the only person who sees the problems with it. The problem is that it'll keep getting pushed by commercial interests. And the same thing will happen with AI incidentally.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 15 child comments
    •
  • [–] 1 point 4 months ago (14 children)

    I was agreeing with you. Systemd breaks unix philosophy. You know what else breaks unix philosophy? The Linux kernel. It's absolutely massive. If you want unix philosophy, switch to a microkernel.

    Also another commenter in this discussion pointed out that flatpak does not actually obfuscate machine-id. You can read the issue tracker here: https://github.com/flatpak/flatpak/issues/4311

    Basically comes down to a design decisions from 15+ years ago, in things that flatpak depends on. This is an open issue to this day. Would it have been better for flatpak to have delayed release until this was solved, possibly remaining unreleased to this day? Meanwhile everybody would have to use regular system packages, which not only have access to machine-id, but also the entire userspace, with zero sandboxing. I doubt that would be better.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] [S] 1 point 4 months ago (13 children)

    There are microkernels like minix and they work well, but that's a different animal because user space is where you actually do make changes much more commonly than in the kernel. Also, I don't really follow your argument regarding flatpack, it's like you're implying that containerized apps couldn't exist without using machine-id for some reason?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 13 child comments
    •
  • [–] 1 point 4 months ago (12 children)

    I'm saying that if flatpak tried to implemenet machine-id obfuscation before releasing, they might not have ever released. By constraining their scope, they were able to focus on their other goals and release, and a lot of Linux users including me, are glad they did so. You can think of systemd's machine-id situation in the same way

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] [S] 1 point 4 months ago (11 children)

    I'm saying flatpack didn't even have to use machine-id at all for anything it does. I don't know why you're so invested in the idea that this was somehow necessary and nothing better is possible.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 1 point 4 months ago (10 children)

    Perhaps ask in the github issue I linked earlier why machine-id is necessary at all. They may have their reasons. My guess is that it makes it easier for devs to port their applications to flatpak, namely legacy apps that depended on machine-id.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] [S] 1 point 4 months ago (9 children)

    It probably does, but I suspect they just didn't consider the problem in the first place rather than the issue being that not having a persistent id is somehow extraordinarily difficult.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 0 points 4 months ago (8 children)

    You could say the same about Linux itself and machine-id. Fingerprint resistance just wasn't in the project scope.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] [S] 1 point 4 months ago (7 children)

    You could, but there was no machine-id on Linux originally and it was something that got added and arguably shouldn't have been. Again, I'm really struggling to understand why you're so invested in defending this decision. Like it's obviously a bad decision, it's not necessary, why is it so hard for you to just say that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 4 months ago (6 children)

    I feel like my argument is not that hard to follow. I'm saying that just because machine-id makes fingerprinting easier, doesn't make it a bad decision because it could still lead to a net positive. In the Linux kernel's case, it might have been a simple solution to other problems, at a time when fingerprinting was not a concern. In systemd's case, it might have made it easier to accomodate legacy systems that depended on machine-id. Same with flatpak.

    Linux, systemd, and flatpak are all fairly successful within their target markets. Clearly, you're going to need more evidence if you want to claim it's a bad decision.

    In fact even if your goal is privacy and fingerprint resistance, just switching to another init system is not a panacea. First off, as mentioned in the flatpak github issue linked earlier, there are tons of other markers aside from machine-id that can be used for fingerprinting. And if you're using a mainstream distro, your new init system is likely less supported, meaning more bugs, worse security, and potentially a net loss in privacy.

    Win the battle, lose the war. This is why I brought up compromise and strategy earlier.

    In the end, it's hard to say how individual decisions like machine-id, contribute to the net result. There are pros and cons to each decision. Maybe if there was a competitor that didn't use machine-id and pulled ahead due to that decision, but I'm not seeing one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] [S] 1 point 4 months ago (5 children)

    You have yet to explain what the net positive that machine-id brings to the table is. I'm eagerly waiting for you thesis.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 3 months ago (4 children)

    First off, your post wasn't about machine-id, it was about systemd using machine-id, yes? If you think machine-id is a mistake, blame Linux, not systemd. This is a shift from your original claim.

    Second, I've already explained my argument many times. Machine-id was likely a simple solution to a few problems Linux faced, and Linux was able to keep pace with competition and gain popularity. Same with systemd adopting machine-id. If they focused on fingerprint resistance, then other core features of modern Linux distros would have lagged behind, and I might not be using Linux today.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 1 point 3 months ago (3 children)

    Maybe go back and read through the thread because I very clearly and repeatedly explained myself. I'm not going to do it once again for you here. You've basically made this huge assumption that machine-id was somehow critical to adopt for which I'm not aware of any supporting evidence, nor have you bothered providing any rationale for. You just keep stating it as fact. Meanwhile, as I've explained, systemd makes the whole situation worse precisely by creating a monolithic structure which everything depends on, and which makes solving the problem more difficult now. I don't think there's any point continuing the discussion though because we just keep restating the same points here and I don't think any further understanding will be gained by anyone from continuing to do that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 0 points 3 months ago* (2 children)

    My evidence was small but should have been easy to understand:

    1. systemd uses machine-id 2 systemd adoption is high amongst distros

    You can argue correlation vs cause but I'd argue this is not zero evidence.

    You are on the other hand assuming that it would have been easy to avoid machine-id. Do you have evidence for this claim?

    Why should I have to provide evidence while you provide none

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 3 months ago (1 child)

    That's not evidence of anything, it's just a tautology stating that machine-id is indeed used, which has never been under any dispute throughout this discussion. What I provided was rationale for why machine-id is problematic, and why systemd makes the problem worse. You have not provided any rationale for why it's necessary aside from stating a tautological fact here. Again, nothing new has been added to the discussion in the process, but you insist on continuing it for reasons unknown. I'll just let you have the last word here since that's what you seem to be after.

    Have a good day.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 months ago

    it's just a tautology stating that machine-id is indeed used

    I stated two things, that machine-id is used and that adoption is high. You're ignoring the latter. Might be correlation or causation, but definitely not tautology.

    You have not provided any rationale for why it's necessary aside from stating a tautological fact here

    This is a gross misrepresentation of my words. I'm not saying it's necessary, I'm saying it contributed to the success of some of the most private distros that exist today. In other words a net positive. You provided zero evidence that it was a net negative, and demonstrated ignorance about the complexity of engineering.

    Either you keep misunderstanding my argument, or deliberately misrepresenting it to avoid admitting its merits. It's becoming clear which is true.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 4 months ago* (3 children)

    My point is that systemd did not have to be built at all. It’s an abomination that goes directly against the original philosophy of Linux creating a monolithic monstrosity to replace individual and composable programs that used to be the way init works. Now, everything is tied to it and it’s become like a cancer in a linux system that’s inoperable.

    amen and try sharing this view on c/linux or c/privacy. lol

    i struggle to understand why both communities are such fervent systemd and proton supporters when other similar communities on other lemmy instances aren't.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 4 months ago (2 children)

    Yeah, I have a hard time understanding the justification for systemd. The only real argument I've seen is that it standardizes the process, but that could've been done as a spec where you define a common config format, lifecycle, etc., and then keep the actual utilities decoupled from each other, but behaving in a uniform way.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 4 months ago (2 children)

    Running browsers safely in a Linux container/sandbox is not straightforward, for instance Flatpak blocks unprivileged namespaces which breaks the browser's own sandboxing so it's recommended to avoid Flatpak browsers.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    Tbh I haven't kept up with that issue for a while now. I'm guessing it still isn't addressed. I usually disable JS anyways so that mitigates almost all attacks. But I have installed browsers in Distrobox before, installing the browser as a system package instead of a Flatpak. Do you know how the sandboxing works in that case?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 4 months ago

    Not sure, although I just did some searches and it appears that Distrobox uses rootless Podman which supports nested unprivileged namespaces. And if it broke the saneboxing there probably would have been an error when you tried to run it.

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (-1 replies)
  • [–] 9 points 4 months ago* (last edited 4 months ago)

    Note that flatpaks are using systemd's sd_id128_get_machine_app_specific API, which generates an app-specific id that's derived from the original machine-id.

    The app-specific id will be unique per-app so it won't be shared between different apps / flatpaks. The apps can't know the original machine-id, but the id they get would still be the same on every restart of the app and in theory does not prevent different sessions within the same app to be fingerprinted as coming from the same user.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 7 points 4 months ago (1 child)

    Flatpak provides access to /etc/machine-id by default.

    flatpak run org.torproject.torbrowser-launcher && TOR_PROCESS_ID=$(flatpak ps | grep tor | cut -f 1 | head -n 1) && clear && flatpak enter $TOR_PROCESS_ID cat /etc/machine-id

    https://docs.flatpak.org/en/latest/sandbox-permissions.html

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 4 months ago*

    Good call, I double checked and you seem to be right.

    I found the github issue tracking this: https://github.com/flatpak/flatpak/issues/4311

    This is easy to state but a lot less easy to solve.

    Hiding /etc/machine-id isn't going to be a meaningful improvement if "other device identifiers" can't be hidden. The most obvious one is the MAC address of each network interface, which is globally unique and available to all processes that have network access.

    To prevent access to the machine ID, xdg-dbus-proxy would have to block all org.freedesktop.DBus.Peer.GetMachineId() calls, which is an incompatible change. That method was intended as a way to determine whether two processes on the bus are running on the same machine; with hindsight, it would have been better as IsOnSameMachine(s: unique_name) -> b on the message bus, rather than GetMachineId() -> s on each peer, but running untrusted software was not really a thing when the Peer interface was designed 15+ years ago.

    Just goes to show how much deeper these problems are than they appear on the surface. Design decisions from 15+ years ago haunting software of today

    P.S. You can shorten your command to simply flatpak run --command=bash org.torproject.torbrowser-launcher -c "cat /etc/machine-id"

    I use --command=bash a lot when I want to just enter a shell inside the flatpak environment

  • permalink
  • fedilink
  • source
  • parent