DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 3, 2022 12:59 UTC (Tue) by farnz (subscriber, #17727)
In reply to: DeVault: Announcing the Hare programming language by ddevault
Parent article: DeVault: Announcing the Hare programming language

The specific concern I have is related to a user trusting the programmer. The problem here is that the language sets me up for a fall if I do trust the programmer.

Assume I'm administrating a FreeBSD fleet; I discover a need, and find a program written in Hare that fills that need. The documentation written by the programmer asserts several security claims that are true on the assumption that a secure keystore is used, and false otherwise. Being a conscientious sysadmin, before relying on the documentation, I first compile the program and run its test suite.

Here's where the pain lies - because there's no way for a Hare programmer to fail the tests if the keystore is not actually secure (but instead heap memory), I see a full set of passes. And then I get burnt because I trusted the programmer, but the language provided no way for the programmer to tell me that, because of my system choices, my trust is misplaced.

And this applies even if the programmer is conscientious - in autotools C, for example, I'd note that keyctl is not available, and not compile in the "in memory secure" keystore, because it's not present on this platform. It'd then be obvious to the conscientious sysadmin that in memory key storage is not available on FreeBSD, and that you need another implementation (be that PKCS#11, TPMv2, Yubikey, or whatever else the programmer designed in), or that I can't trust the security claims that depend on keyctl.

If Hare wanted me to be able to trust the programmer, there would at a minimum be a way for the programmer to prevent the code relying on the key store if it's not secure. That mechanism is not present here.

to post comments

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:16 UTC (Tue) by ddevault (subscriber, #99589) [Link] (3 responses)

>The documentation written by the programmer asserts several security claims that are true on the assumption that a secure keystore is used, and false otherwise.

This is an error in the downstream software, not in Hare. We cannot prevent programmers from making untruthful claims about their software. And, *again*, storing secrets in the heap in the face of the lack of a kernel-managed keystore *does not directly make your program insecure*.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:40 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

It's also a bug in Hare, because it claims to be a secure keystore, but it's not on some systems. And while storing secrets in the heap does not directly make your program insecure, I'm not talking about that - I'm referring to the case where the program does things to ensure that it's secure as long as the keys are not on the heap or stack outside of the times they're used.

And again, it's trivial to fix in Hare - just an is_secure_store function that returns true on Linux, false on other platforms for now.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:43 UTC (Tue) by ddevault (subscriber, #99589) [Link] (1 responses)

Again, the "claims" it makes are, verbatim, the following:

> On platforms without a suitable feature, a fallback implementation stores the secrets in the process heap, providing no security. This is an opportunistic API which allows your program to take advantage of these features if available.

In my opinion, this is very clear.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:45 UTC (Tue) by farnz (subscriber, #17727) [Link]

And in my opinion, it's not clear at all - which platforms have secure storage? How do I tell my users that they've chosen a platform that doesn't work the way I want it to? How do I prevent use of the keystore when it's not actually secure?