Cameron 
Is it possible to add a sysctl into #freebsd that can only be read by root? I see how to make it require root for writes, but not how to require root for reads…
Apr 2, 2024 at 1:04amWeb
Show threadAJCxZ0Apr 2, 2024

@cameron I think not, but am interested in the use case for secret or privileged keys and/or values. What do you have in mind?

https://wiki.freebsd.org/sysctl

sysctl - FreeBSD Wiki

Show threadCameron Apr 2, 2024
@AJCxZ0 I’m trying to add RFC7217 support for semantically opaque interface identifiers with SLAAC. To store the key, OpenBSD used a sysctl, so I figured I’d do the same. Would it maybe be a better idea to store the key elsewhere?
Show threadAJCxZ0Apr 3, 2024

@cameron I've not yet read the RFC, so don't have an opinion on this specific case.

It would hardly count as insightful to point out that storing secrets in places not intended for that purpose is at best unwise, potentially harmful and irresponsible in cases in which suitable alternatives exist.

Show threadAJCxZ0Apr 3, 2024
My conception of sysctl as a database for kernel tunables visible only to those with permission to run code on the host may lack some relevant nuance and I'm unaware of any relevant precedent beyond the OpenBSD example you mention and I am inclined to trust their judgment on "security" matters. That is to say - again - I don't know, but with more words.
Show threadCameron Apr 3, 2024

@AJCxZ0 I was looking at other operating systems to see how they did it, and both Linux and OpenBSD stored it in a sysctl so I figured that to be the most obvious.

Where do you think a better place to store it would be?
> An implementation MAY provide the means for the system administrator to display and change the secret key.

Show threadAJCxZ0Apr 3, 2024

@cameron Since I have still done no research on this, I still lack an opinion and would like to see informed opinions on this.

The precedent you mention, which itself is a strong motivator for consistency, strongly suggests that this key does not need to be kept secret from those who can run code on the host.
In any case, you get points for seriously considering the matter.

Show threadCameron Apr 3, 2024
@AJCxZ0 I guess I should have shown this quote from the RFC
> We note that since the privacy of the scheme specified in this document relies on the secrecy of the secret_key parameter, implementations should constrain access to the secret_key parameter to the extent practicable (e.g., require superuser privileges to access it).