Comment by Joker_vD

14 days ago

Nope! But basically, expect anything that resolves usernames, or host names, to be done in the userspace by NSS.

    Sun engineers Thomas Maslen and Sanjay Dani were the first to design and implement
    the Name Service Switch. They fulfilled Solaris requirements with the nsswitch.conf
    file specification and the implementation choice to load database access modules as
    dynamically loaded libraries, which Sun was also the first to introduce.

    Sun engineers' original design of the configuration file and runtime loading of name
    service back-end libraries has withstood the test of time as operating systems have
    evolved and new name services are introduced. Over the years, programmers ported the
    NSS configuration file with nearly identical implementations to many other operating
    systems including FreeBSD, NetBSD, Linux, HP-UX, IRIX and AIX.[citation needed] More
    than two decades after the NSS was invented, GNU libc implements it almost identically.

It's by design, you see.

6 comments

Joker_vD

Reply
jsdfasds  14 days ago

This is precisely why I don't link with glibc anymore.

  • Arch-TK  14 days ago

    musl has its own approach to this, it's called nscd

    It would have avoided the "running code as root" part, but it would still allow an attacker to control the result of the function call.

    I mean, the problem being solved here isn't exactly a bad problem to try to solve. You either permanently hard-code `/etc/passwd` as the user database, and `/etc/resolv.conf` as the source of DNS server information, or you allow these to be handled in a more complex way (thus allowing YellowPages, LDAP, or whatever you can imagine).

    • Joker_vD  14 days ago

      Obviously, if you tie the ability to handle those things to your filesystem layout, either by loading dynamic libraries from whatever is /usr/lib, or by reading /etc/whatever.conf, or even providing a whole virtual mount à la /proc, chroot'ing gives you both with the ability to override the system-wide policy for yourself (pretty reasonable for DNS lookups, kinda dubious for username lookups) and the opportunity to accidentally pwn yourself.

      Frankly, sometimes I feel that on Linux, root should be restricted to executing/loading only a whitelist of executables/shared objects, identified by hash of the contents, not the file paths. But then again, you'll need a allow_for_root(1) utility to maintain this whitelist, and people absolutely will call it in their setup scripts in all kinds of dubious manner.

      3 replies →