4 ms·

Or you can just mask the service (better than disabling): systemctl mask systemd-resolved.service Other services to consider masking if you are not using

Or you can just mask the service (better than disabling): systemctl mask systemd-resolved.service Other services to consider masking if you are not using SystemD for network configuration and time sync., etc.: systemctl mask systemd-hostnamed.service systemctl mask systemd-timesyncd.service systemctl mask systemd-networkd.service systemctl mask systemd-homed.service

westurner 5y ago
Yeah, but if you regress to 'legacy DNS' by removing systemd-resolved then there's no good way to do per-interface DNS (~client-split DNS), or (optionally) validate DNSSEC, or do DoH/DoT; and then nothing respawns and logs consistently-timestamped process events of substitute network service processes. FWIU, per-user DNS configs are still elusive. Per-user DNS would make it easier to use family-safe DNS (that redirects to family-safe e.g. SafeSearch domains) by default; some forums are essential for system administration.
- tptacek 5y ago
  Since nothing in the real world is or ever will be DNSSEC signed anyways, it's not that much of a loss. Meanwhile, the most important DoH user --- your browser --- has DoH baked in and doesn't need systemd-resolved's help.
  - westurner 5y ago
    Your system may also depend upon one or more package managers that do all depend upon DNS (and hopefully e.g. DNSSEC and DoH/DoT)
    - tptacek 5y ago
      Package managers don't rely on DNSSEC for package security (it would be deeply problematic if they did). But you can also just go look and see that, for instance, Ubuntu.com isn't signed, nor are most of the Pacman mirrors for Arch, nor is alpinelinux.org, &c. DNSSEC is simply not a factor in package management security. People have weird ideas about how this stuff works.
      - westurner 5y ago
        Unfortunately all packages aren't necessarily signed either; "Which package managers require packages to be cryptographically signed?" is similar to "Which DNS clients can operate DNS resolvers that require DNSSEC signatures on DNS records to validate against the distributed trust anchors?". FWIW, `delv pkg.mirror.server.org` is how you can check DNSSEC: man systemd-resolved # nmcli man delv man dnssec-trust-anchors.d delv pkg.mirror.server.org Sigstore is a free and open Linux Foundation service for asset signatures: https://sigstore.dev/what_is_sigstore/ https://sigstore.dev/what_is_sigstore/ The TUF Overview explains some of the risks of asset signature systems; key compromise, there's one key for everything that we all share and can't log the revocation of in a CT (Certificate Transparency) log distributed like a DLT, https://theupdateframework.io/overview/ https://theupdateframework.io/overview/ Certificate Transparency: https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency Yeah, there's a channel to secure there at that layer of the software supply chain as well. "PEP 480 -- Surviving a Compromise of PyPI: End-to-end signing of packages" (2014-) https://www.python.org/dev/peps/pep-0480/ https://www.python.org/dev/peps/pep-0480/ > Proposed is an extension to PEP 458 that adds support for end-to-end signing and the maximum security model. End-to-end signing allows both PyPI and developers to sign for the distributions that are downloaded by clients. The minimum security model proposed by PEP 458 supports continuous delivery of distributions (because they are signed by online keys), but that model does not protect distributions in the event that PyPI is compromised. In the minimum security model, attackers who have compromised the signing keys stored on PyPI Infrastructure may sign for malicious distributions. The maximum security model, described in this PEP, retains the benefits of PEP 458 (e.g., immediate availability of distributions that are uploaded to PyPI), but additionally ensures that end-users are not at risk of installing forged software if PyPI is compromised. One W3C Linked Data way to handle https://schema.org/SoftwareApplication https://schema.org/SoftwareApplication ( https://codemeta.github.io/user-guide/ https://codemeta.github.io/user-guide/ ) cryptographic signatures of a JSON-LD manifest with per-file and whole package hashes would be with e.g. W3C ld-signatures/ld-proofs and W3C DID (Decentralized Identifiers) or x.509 certs in a CT log.
chrisweekly 5y ago
Thanks; got a writeup abt these you might be willing to share?

westurner 5y ago

Yeah, but if you regress to 'legacy DNS' by removing systemd-resolved then there's no good way to do per-interface DNS (~client-split DNS), or (optionally) validate DNSSEC, or do DoH/DoT; and then nothing respawns and logs consistently-timestamped process events of substitute network service processes. FWIU, per-user DNS configs are still elusive. Per-user DNS would make it easier to use family-safe DNS (that redirects to family-safe e.g. SafeSearch domains) by default; some forums are essential for system administration.

tptacek 5y ago
Since nothing in the real world is or ever will be DNSSEC signed anyways, it's not that much of a loss. Meanwhile, the most important DoH user --- your browser --- has DoH baked in and doesn't need systemd-resolved's help.
- westurner 5y ago
  Your system may also depend upon one or more package managers that do all depend upon DNS (and hopefully e.g. DNSSEC and DoH/DoT)
  - tptacek 5y ago
    Package managers don't rely on DNSSEC for package security (it would be deeply problematic if they did). But you can also just go look and see that, for instance, Ubuntu.com isn't signed, nor are most of the Pacman mirrors for Arch, nor is alpinelinux.org, &c. DNSSEC is simply not a factor in package management security. People have weird ideas about how this stuff works.
    - westurner 5y ago
      Unfortunately all packages aren't necessarily signed either; "Which package managers require packages to be cryptographically signed?" is similar to "Which DNS clients can operate DNS resolvers that require DNSSEC signatures on DNS records to validate against the distributed trust anchors?". FWIW, `delv pkg.mirror.server.org` is how you can check DNSSEC: man systemd-resolved # nmcli man delv man dnssec-trust-anchors.d delv pkg.mirror.server.org Sigstore is a free and open Linux Foundation service for asset signatures: https://sigstore.dev/what_is_sigstore/ https://sigstore.dev/what_is_sigstore/ The TUF Overview explains some of the risks of asset signature systems; key compromise, there's one key for everything that we all share and can't log the revocation of in a CT (Certificate Transparency) log distributed like a DLT, https://theupdateframework.io/overview/ https://theupdateframework.io/overview/ Certificate Transparency: https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency Yeah, there's a channel to secure there at that layer of the software supply chain as well. "PEP 480 -- Surviving a Compromise of PyPI: End-to-end signing of packages" (2014-) https://www.python.org/dev/peps/pep-0480/ https://www.python.org/dev/peps/pep-0480/ > Proposed is an extension to PEP 458 that adds support for end-to-end signing and the maximum security model. End-to-end signing allows both PyPI and developers to sign for the distributions that are downloaded by clients. The minimum security model proposed by PEP 458 supports continuous delivery of distributions (because they are signed by online keys), but that model does not protect distributions in the event that PyPI is compromised. In the minimum security model, attackers who have compromised the signing keys stored on PyPI Infrastructure may sign for malicious distributions. The maximum security model, described in this PEP, retains the benefits of PEP 458 (e.g., immediate availability of distributions that are uploaded to PyPI), but additionally ensures that end-users are not at risk of installing forged software if PyPI is compromised. One W3C Linked Data way to handle https://schema.org/SoftwareApplication https://schema.org/SoftwareApplication ( https://codemeta.github.io/user-guide/ https://codemeta.github.io/user-guide/ ) cryptographic signatures of a JSON-LD manifest with per-file and whole package hashes would be with e.g. W3C ld-signatures/ld-proofs and W3C DID (Decentralized Identifiers) or x.509 certs in a CT log.

chrisweekly 5y ago

Thanks; got a writeup abt these you might be willing to share?