OpenBSD system-call-origin verification

Posted Dec 19, 2019 10:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: OpenBSD system-call-origin verification by marcH
Parent article: OpenBSD system-call-origin verification

To be fair, musl libc is a full-blown replacement for glibc. And it's better in many regards.

OpenBSD system-call-origin verification

Posted Dec 19, 2019 15:46 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (9 responses)

Eh, without NSS or PAM, some of my use cases aren't supported. I already had to drop a Go program because it wouldn't use the `mymachines` NSS plugin from `systemd-machined` to be able to get hostnames of sibling containers.

OpenBSD system-call-origin verification

Posted Dec 19, 2019 20:15 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Well, would be nice to drop NSS libraries entirely.

OpenBSD system-call-origin verification

Posted Dec 20, 2019 17:06 UTC (Fri) by cortana (subscriber, #24596) [Link] (7 responses)

Somehow I get the feeling that many who dislike NSS won't be happy to replace it with systemd-resolved... ;)

OpenBSD system-call-origin verification

Posted Dec 20, 2019 20:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

It should be replaced by a simple local daemon with a simple well-defined protocol. Libraries that are loaded behind your back into the running process are just a bad idea.

OpenBSD system-call-origin verification

Posted Dec 21, 2019 13:26 UTC (Sat) by cortana (subscriber, #24596) [Link] (3 responses)

resolved for all then! :)

OpenBSD system-call-origin verification

Posted Dec 21, 2019 16:44 UTC (Sat) by dezgeg (subscriber, #92243) [Link] (2 responses)

Using nscd in non-caching configuration is already practical and done in NixOS for everything except the built-in NSS modules. IIRC not everything in NSS is supported via nscd though, but fixing nscd to have 100% feature parity should be much easier than reinventing anything new.

OpenBSD system-call-origin verification

Posted Dec 24, 2019 1:01 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

This kind of approach is certainly the best, but until then, those of us who need NSS-provided functionality are stuck on glibc.

OpenBSD system-call-origin verification

Posted Dec 24, 2019 12:31 UTC (Tue) by cortana (subscriber, #24596) [Link]

I believe nscd doesn't play well with sssd (though I haven't bothered to investigate why, perhaps it's just that it's unnecessary since sssd does it's own caching anyway).

And that NSS will tell you a host's addresses but not which interface they are reachable via, or whether the query was secured by DNSSEC, dns-over-tls, etc, which resolved does provide via its D-BUS API.

(As well as being able to do nifty things like LLMNR, or split-DNS. OTOH resolved does have its own bugs and limitations that drive me up the wall a bit...)

OpenBSD system-call-origin verification

Posted Jan 8, 2020 11:20 UTC (Wed) by nix (subscriber, #2304) [Link]

AIUI this is upstream glibc's longer-term goal too -- however, it will still look like NSS from the viewpoint of both NSS modules themselves and existing users. Quite what to do is still up in the air, but it's likely that we'll end up with something like an always-on, possibly autospawned nscd which aggressively loads all modules names in nsswitch.conf at startup and on nsswitch.conf change.

This isn't to avoid libraries getting loaded behind your back into a running process so much as it is to allow removal of the incredibly convoluted and invasive statically-linked dlopen() feature, which is only really there so that statically linked programs can do name lookups. (But moving all the NSS stuff out of every process's address space into one more controllable domain is definitely a side benefit!)

(I am only an egg, but this is my understanding, anyway. My apologies if I'm mischaracterizing anything or accidentally mixing it up with my own ideas of obviously right implementations etc: human memory is a fallible thing...)

OpenBSD system-call-origin verification

Posted Jan 9, 2020 1:34 UTC (Thu) by anselm (subscriber, #2796) [Link]

Probably not, given that the uses of NSS and those of systemd-resolved only overlap slightly.