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

601–610 of 770 posts

Re: Lennart Poettering, Christian Brauner founded a new company

#601

Post by anonym29 »

stackghost wrote: post #48
enriquto wrote: post #41

Earlier quoted context omitted.

half of the founders of this thing come from Microsoft. I suppose this makes the answer to your question obvious.

My thoughts exactly. We're probably witnessing the beginning of the end of linux users being able to run their own kernels. Soon: - your bank won't let you log in from an "insecure" device. - you won't be able to play videos on an "insecure" device. - you won't be able to play video games on an "insecure" device. And so on, and so forth.

Torrenting is becoming more popular again. The alternative to being allowed to pay to watch on an "insecure" device isn't switching to an attested device, it's to stop paying for the content at all. Games industry, same thing (or just play the good older games, the new ones suck anyway).

Finances, just pay everything by cheque or physical pennies. Fight back. Starve the tyrants to death where you can, force the tyrants to incur additional costs and inefficiencies where you can't.

Re: Lennart Poettering, Christian Brauner founded a new company

#602

Post by stackghost »

bee_rider wrote: post #559
2pEXgD0fZ5cF wrote: post #500

Well I was wondering when the war on general computing and computer ownership would be carried into the heart of the open source ecosystems. Sure, there are sensible things that could be done with this. But given the background of the people involved, the fact that this is yet another clear profit-first gathering makes me incredibly pessimistic. This pessimism is made worse by reading the answers of the founders here…

I do sort of wonder if there’s room in my life for a small attested device. Like, I could actually see a little room for my bank to say “we don’t know what other programs are running on your device so we can’t actually take full responsibility for transactions that take place originated from your device,” and if I look at it from the bank’s point of view that doesn’t seem unreasonable. Of course, we’ll see if anybody…

The bank thing is a smoke screen.

This entire shit storm is 100% driven by the music, film, and tv industries, who are desperate to eke a few more millions in profit from the latest Marvel snoozefest (or whatever), and who tried to argue with a straight face that they were owed more than triple the entire global GDP [0].

These people are the enemy. They do not care about about computing freedom. They don't care about you or I at all. They only care about increasing profits via and they're using the threat of locking people out of Netflix via HDCP and TPM, in order to force remote attestation on everyone.

I don't know what the average age on HN is, but I came up in the 90s when "fuck corporations" and "information wants to be free" still formed a large part of the zeitgeist, and it's absolutely infuriating to see people like TFfounders actively building things that will measurably make things worse for everyone except the C-suite class. So much for "hacker spirit".

[0] https://globalnews.ca/news/11026906/music-industry-limewire-...

Re: Lennart Poettering, Christian Brauner founded a new company

#603

Post by cferry »

surajrmal wrote: post #540
inetknght wrote: post #305

Earlier quoted context omitted.

Can I build my own kernel and still use software that wants attestation?

Do you have a way to tell the software to trust your kernel? If so, yes. Things like the web show how we can achieve distributed trust.

That's the thing. I can only provide a piece of software with the guarantee it can run on my OS. It can trust my kernel to let it run, but shouldn't expect anything more. The editor is free to run code it wants to guarantee the integrity of on its own infrastructure; but whatever reaches my machine _may_ at best run as the editor intends.

Re: Lennart Poettering, Christian Brauner founded a new company

#604

Post by thewebguyd »

fc417fc802 wrote: post #591
thewebguyd wrote: post #571

Earlier quoted context omitted.

I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device." It would quickly get out of hand if every online service started to do the same though. But, if remote device attestation continues to be…

Why should I need a separate device? Doesn't a hardware security token suffice? I wouldn't even mind bringing my own but my bank doesn't accept them last I checked. (Do any of them?) If the bank can't be bothered to either implement support for U2F or else clearly articulate why U2F isn't sufficient then they don't have a valid position. Anything else they say on the matter should be disregarded.

You shouldn't need a separate device, but we are quickly entering an era where a lot of banking (and other) apps will outright refuse to run or allow logins if it detects a rooted device, or play integrity fails.

In this way, the banks are asserting control over your device. It's beyond authentication, they are saying "If you have full control over your device, you cannot access our services."

I'll agree with you that they don't have a valid position, because I can just as easily open up a web browser on said rooted device and access just fine via the web, but how long until services move away from web interfaces in favor of apps instead to assert more control?

Re: Lennart Poettering, Christian Brauner founded a new company

#605

Post by jcgl »

PunchyHamster wrote: post #411
dijit wrote: post #170

Earlier quoted context omitted.

The trick is the same: use a popular linux distribution and don't fight the kinks. The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way. SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work t…

> The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way. Incorrect. I used mainstream distro, still had issues, that just solved itself moving to pipewire. Issues like it literally crashing or emitting spur of max volume noise once every few months for no discernable reason. Pulseaudio also completely…

> Pulseaudio also completely denies existence of people trying to do music on Linux, there is no real way to make latency on it be good.

I don't care much about PA at this point tbh and don't know much about the inner workings; it always worked just fine for me. But from what I read from people more "in the know" at the time, I'd heard that a lot of the (very real) user-facing problems with PA were ultimately caused by driver and other low-level problems. Those were hacky, had poor assumptions, etc. PA ultimately exposed those failures, and largely got better over time because those problems got fixed upstream of PA.

My takeaway from what I read was basically that PA had to stumble and walk so that pipewire could run.

> For example systemd have no real method to tell it "turn off all apps after 5 minutes regardless of what silly package maintainers think". Now what happens if you have a server on UPS that have say 5 minutes of battery and one of the apps have some problem and doesn't want to close?

Add a TimeoutStopSec= to /etc/systemd/system/service.d/my-killing-dropin.conf more or less, I think? These are documented in the systemd.service and systemd.unit manpages respectively.

> Same problem also surfaced if you have say app with a bug that prevented it from closing from sigterm and you wanted to reboot a machine. Completely stuck

See the --force option on the halt, poweroff, and reboot subcommands of systemctl. The kill subcommand if you want to target that specific service.

> so I pasted the thing he decided to ignore in original ticket, and got ignored. Not even "pull requests welcome" (which I'd be fine with, I just wanted confirmation that the feature like that won't be rejected if I start writing it).

I'm certainly sympathetic to this pain point. I'd take Lennart at his word that he's not opposed. Generally speaking, from following the systemd project somewhat, it's a very busy project and it's hard for all issues to get serviced. But they're very open to PRs, generally speaking.

> Or the issue that resolvconf replacement in systemd will just roll a dice on DNS ordering, but hey, Mr. Lennart doesn't use openvpn so it's not real issue ( https://github.com/systemd/systemd/issues/27543 )

Quickly taking a peek here (and speaking as a relatively superficial user of resolved myself), isn't the proposed solution to define interface ordering?

> it will ask on all links in parallel if there's no better routing info available. In your case there is none (i.e. no ~. listed among your network interfaces), hence it will be asked on all interfaces at the same time.

Re: Lennart Poettering, Christian Brauner founded a new company

#606

Post by magicalhippo »

jcgl wrote: post #588
magicalhippo wrote: post #525

Earlier quoted context omitted.

> https://github.com/systemd/systemd/issues/4880 I'm not a systemd hater or anything, but I continue to read stuff from Poettering which to me is deeply disturbing given the programs he works on. Saying it's not a bug that service is launched despite a stated required prerequisite dependency failed... WTF? Sure, I agree with him that most computers should probably boot despite NTP being unable to sync. But proposing…

I'm not sure I understand why you think the solution proposed there is so bad. The question in that issue is around the semantics of time-sync. target . Targets are synchronization points for the system and don't (afaik) generally make promises about the units that are ordered before them (in this case chrony-wait.service. Does that answer your specific objection of "proposing that the solution to that is breaking Re…

No, that does not make sense, because it goes against the systemd documentation.

Targets[1]: Target units do not offer any additional functionality on top of the generic functionality provided by units. They merely group units, allowing a single target name to be used in Wants= and Requires= settings to establish a dependency on a set of units defined by the target, and in Before= and After= settings to establish ordering.

boot-complete.target[2]: Order units that shall only run when the boot process is considered successful after the target unit and pull in the target from it, also with Requires=.

Note use of "only run" with a reference to Requires=.

time-sync.target[3]: This target provides stricter clock accuracy guarantees than time-set.target (see above), but likely requires network communication and thus introduces unpredictable delays. Services that require clock accuracy and where network communication delays are acceptable should use this target.

Especially note the last sentence there.

The documentation clearly indicates that targets can fail, and that services that needs the target to be successful, should use Requires= to specify that.

If the above is not true, the Requires= and Targets documentation should be rewritten to explicitly say that targets might fulfill Requires= regardless of state. Also, the documentation for time-sync.target should explicitly remove the last sentence and instead state there is no functional difference between Requires=time-sync.target and Wants=time-sync.target, it is best-effort only.

[1]: https://www.freedesktop.org/software/systemd/man/latest/syst...

[2]: https://www.freedesktop.org/software/systemd/man/latest/syst...

[3]: https://www.freedesktop.org/software/systemd/man/latest/syst...

Re: Lennart Poettering, Christian Brauner founded a new company

#607

Post by fc417fc802 »

drdaeman wrote: post #593
fc417fc802 wrote: post #585

Earlier quoted context omitted.

The value is being able to easily and robustly verify that my device hasn't been compromised. Binding disk encryption keys to the TPM such that I don't need to enter a password but an adversary still can't get at the contents without a zero day. Of course you can already do the above with secure boot coupled with a CPU that implements an fTPM. So I can't speak to the value of this project specifically, only build and…

I don’t think attestation can provide such guarantees. To best of my understanding, it won’t protect from any RCE, and it won’t protect from malicious updates to configuration files. It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware). IDSes are sufficient for this…

I think all of that comes down to being a matter of what precisely you're attesting? So I'm not actually clear what we're talking about here.

Given secure boot and a TPM you can remotely attest, using your own keys, that the system booted up to a known good state. What exactly that means though depends entirely on what you configured the image to contain.

> it won’t protect from malicious updates to configuration files

It will if you include the verified correct state of the relevant config file in a merkel tree.

> It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware).

Shouldn't it permit running arbitrary binaries that you have signed? That places the root of trust with the build environment.

Now if you attempt to compile binaries and then sign them on the production system yeah that would open you up to attack (if we assume a process has been compromised at runtime). But wasn't that already the case? Ideally the production system should never be used to sign anything. (Some combination of SGX, TPM, and SEV might be an exception to that but I don't know enough to say.)

> Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.

If you remotely boot a box sitting in a rack on the other side of the world how can you be sure it hasn't been compromised? However you go about confirming it, isn't that what attestation is?

Re: Lennart Poettering, Christian Brauner founded a new company

#608

Post by charcircuit »

fc417fc802 wrote: post #591
thewebguyd wrote: post #571

Earlier quoted context omitted.

I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device." It would quickly get out of hand if every online service started to do the same though. But, if remote device attestation continues to be…

Why should I need a separate device? Doesn't a hardware security token suffice? I wouldn't even mind bringing my own but my bank doesn't accept them last I checked. (Do any of them?) If the bank can't be bothered to either implement support for U2F or else clearly articulate why U2F isn't sufficient then they don't have a valid position. Anything else they say on the matter should be disregarded.

A hardware token would not suffice. When you login with a hardware token it will generate some sort of token or cookie for further requests. This is where malware can steal that key and use it for whatever it wants. There is a benefit it knowing there is a high chance that the such a key is protected by the operating system's sandboxing technology. Without remote attestation you don't know if the sandbox is actually active or not.

Re: Lennart Poettering, Christian Brauner founded a new company

#609

Post by AnthonyMouse »

mariusor wrote: post #488
AnthonyMouse wrote: post #372

Earlier quoted context omitted.

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…

Are you saying that attestation doesn't really provide any real security? Not even from the bank's point of view?

If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.

It doesn't really provide any security.

On top of that, there are tons of devices that can pass attestation that have known vulnerabilities, so the attacker could just use one of those (or extract the keys from it) if they had any reason to. But in the mobile banking threat model they don't actually need to.

Re: Lennart Poettering, Christian Brauner founded a new company

#610

Post by MisterTea »

blacklion wrote: post #512
esjeon wrote: post #436

Earlier quoted context omitted.

Attestation is a critical feature for many H/W companies (e.g. IoT, robotics), and they struggle with finding security engineers who expertise in this area (disclaimer: I used to work as a operating system engineer + security engineer). Many distros are not only designed for desktop users, but also for industrial uses. If distros ship standardized packages in this area, it would help those companies a lot.

IoT and robotics should (dare I say "must"?) not use general-purpose OSes at all. This «Linux have a finger in every pie» attitude is very harmful for industry, IMHO.

General purpose operating systems are fine and in some cases, preferable. However, they should be small, simple and designed with first class portability. Linux is none of those.
Post reply on HN