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

Lennart Poettering, Christian Brauner founded a new company

amutable.com

Post reply on HN
Print view View original

421–430 of 770 posts

Re: Lennart Poettering, Christian Brauner founded a new company

#421

Post by PunchyHamster »

quotemstr wrote: post #353

People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out. Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S i…

> People demonize attestation. They should keep in mind that far from enslaving users, attestation actually enables some interesting, user-beneficial software shapes that wouldn't be possible otherwise. Hear me out.

But it won't be used like that. It will be used to take user freedoms out.

> But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.

That use case you're describing is already there and is currently being done with DRM, either in browser or in app itself.

You are right in the "it will make easier for app user to do it", and in theory it is still better option in video games than kernel anti-cheat. But it is still limiting user freedoms.

> Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.

Majority of the uses will be user-hostile things. Because those are only cases where someone will decide to fund it.

Re: Lennart Poettering, Christian Brauner founded a new company

#423

Post by faust201 »

AnthonyMouse wrote: post #372
ahepp wrote: post #355

Earlier quoted context omitted.

as you say, a lot of this stuff is already happening. Won’t it be good to have a FOSS attestation stack that breaks the iOS/android duopoly?

Banks don't use these things because they provide any real security. They use them because the platform company calls it a "security feature" and banks add "security features" to their checklists. The way you defeat things like that is through political maneuvering and guile rather than submission to their artificial narrative. Publish your own papers and documentation that recommends apps not support any device with…

Well summarised.

Another point is (often )the apps that banks makes are 3rd party developed by outsourcing (even if within the same developed country). If someone uses some MiTM or logcat to see some traffic and publishes it then banks get bad publicity. So to prevent this the banks, devs tell anything that is not normal (i.e) non-stock ROM is bad.

FOSS is also something many app-based software devs don't like on their products. While people in cloud, infra like it the app devs like these tools while developing or building a company but not when making end resulting apps.

Re: Lennart Poettering, Christian Brauner founded a new company

#424

Post by coppsilgold »

stogot wrote: post #337
coppsilgold wrote: post #331

Remote attestation only works because your CPU's secure enclave has a private key burned-in (fused) into it at the factory. It is then provisioned with a digital certificate for its public key by the manufacturer. Every time you perform an attestation the public key (and certificate) is divulged which makes it a unique identifier, and one that can be traced to the point of sale - and when buying a used device, a poin…

I’m not sure I understand the threat model for this. Why would I need to worry about my enclave being identifiable? Or is this a business use case? Or why buy used devices if this is a risk?

It's a privacy consideration. If you desire to juggle multiple private profiles on a single device extreme care needs to be taken to ensure that at most one profile (the one tied to your real identity) has access to either attestation or DRM. Or better yet, have both permanently disabled.

Hardware fingerprinting in general is a difficult thing to protect from - and in an active probing scenario where two apps try to determine if they are on the same device it's all but impossible. But having a tattletale chip in your CPU an API call away doesn't make the problem easier. Especially when it squawks manufacturer traceable serials.

Remote attestation requires collusion with an intermediary at least, DRM such as Widevine has no intermediaries. You expose your HWID (Widevine public key & cert) directly to the license server of which there are many and under the control of various entities (Google does need to authorize them with certificates). And this is done via API, so any app in collusion with any license server can start acquiring traceable smartphone serials.

Using Widevine for this purpose breaks Google's ToS but you would need to catch an app doing it (and also intercept the license server's certificate) and then prove it which may be all but impossible as an app doing it could just have a remote code execution "vulnerability" and request Widevine license requests in a targeted or infrequent fashion. Note that any RCE exploit in any app would also allow this with no privilege escalation.

Re: Lennart Poettering, Christian Brauner founded a new company

#425

Post by lugu »

I see the use case for servers targeted by malicious actors. A penetration test on an hardened system with secure boot and binary verification would be much harder.

For individuals, IMO the risk mostly come from software they want to run (install script or supply chain attack). So if the end user is in control of what gets signed, I don't see much benefit. Unless you force users to use an app store...

Re: Lennart Poettering, Christian Brauner founded a new company

#426

Post by forty »

storystarling wrote: post #191
forty wrote: post #107

Earlier quoted context omitted.

Quadlet are great but running podman via systemd as a non root user worked perfectly well before quadlets and I have no idea what your parent is talking about (I'm currently in the process of converting my home services from rootless podman over systemd to quadlet)

Fair, it worked, but podman generate systemd is deprecated now. I found the generated unit files pretty brittle to maintain compared to just having a declarative config that handles the lifecycle.

I agree 100%, I was stuck without quadlet in previous Debian stable so I had to work with systemd generate, but quadlets are undoubtedly better, and I was looking forward to upgrade Debian just for that, and now that I did, I'm really happy to migrate. Especially custom container image management is so much smoother.

Re: Lennart Poettering, Christian Brauner founded a new company

#427

Post by UltraSane »

Trusted computing and remote attestation is like two people who want to have sex requiring clean STD tests first. Either party can refuse and thus no sex will happen. A bank trusting a random rooted smartphone is like having sex with a prostitute with no condom. The anti-attestation position is essentially "I have a right to connect to your service with an unverified system, and refusing me is oppression." Translate that to the STD context and it sounds absurd - "I have a right to have sex with you without testing, and requiring tests violates my bodily autonomy."

You're free to root your phone. You're free to run whatever you want. You're just not entitled to have third parties trust that device with their systems and money. Same as you're free to decline STD testing - you just don't get to then demand unprotected sex from partners who require it.

Re: Lennart Poettering, Christian Brauner founded a new company

#429

Post by its-summertime »

drdaeman wrote: post #379
cyphar wrote: post #51

Earlier quoted context omitted.

I'm Aleksa, one of the founding engineers. We will share more about this in the coming months but this is not the direction nor intention of what we are working on. The models we have in mind for attestation are very much based on users having full control of their keys. This is not just a matter of user freedom, in practice being able to do this is far more preferable for enterprises with strict security controls. I…

Can you (or someone) please tell what’s the point, for a regular GNU/Linux user, of having this thing you folks are working on? I can understand corporate use case - the person with access to the machine is not its owner, and corporation may want to ensure their property works the way they expect it to be. Not something I care about, personally. But when it’s a person using their own property, I don’t quite get the p…

https://attestation.app/about For mobiles, it helps make tampering obvious.

https://doc.qubes-os.org/en/latest/user/security-in-qubes/an... For laptops, it helps make tampering obvious. (a different attestation scheme with smaller scope however)

This might not be useful to you personally, however.

Re: Lennart Poettering, Christian Brauner founded a new company

#430

Post by forty »

plagiarist wrote: post #179
storystarling wrote: post #97

Earlier quoted context omitted.

Quadlet actually solves this. It's the newer way to define containers for systemd and handles the rootless user case properly. I migrated my services to it recently and it's much more robust than the old generate scripts.

Could you give an example system-level quadlet that accepts connections on a low port, like 80, but runs the actual container as a non-root user (and plays nice with systemd, no force kill after timeout to stop, no reporting as failed for a successful stop)? My understanding is quadlet does not solve this, and my options are calling "systemctl --user" or "--userns auto". I would love to be wrong here.

As an alternative solution to the sibling comment, I do run everything rootless in systemd --user so my services don't have access to privileged ports, and use firewall rules to redirect the external interface low ports, to the local high ports (that sounds annoying but in practice I only redirect a single port - 443 - to traefik and the use it to route to the right container service depending on domain)
Post reply on HN