Hacker News Reader

Comment by codedokode | Hacker News Reader

As I understand, the problem is that authentication used users from /etc/passwd and allowed to log in as any user, even as system user like "messagebus" which has no password. It is annoying that linux software uses system database for authorization, for example, Postgres and Samba do this and there is always a risk that you have some system user you don't know about which can be used to access your system.

View on HN

Samba has its own user DB with the default auth backend and allows per share restrictions. Same with Postgres. "PostgreSQL database user names are logically separate from user names of the operating system in which the server runs." [https://www.postgresql.org/docs/current/client-authenticatio...]

"No password = locked account" is today's default policy on most systems, for a reason.

Not really. To be really sure, set ! as a password in /etc/shadow. That's what most distributions do. PAM has another security measure, if user's shell is not in /etc/shells, it's also considered a locked account and will not allow login.

Of course, follow the best practices if you want to be really sure, e.g. set the password field to "!" so it's invalid, set the shell to /sbin/nologin, set the home directory to /dev/null (doesn't really do anything but it's a convention), etc, etc, etc. The "must have password" policy is for preventing accidental mistakes by people who don't know anything about what we just said, and my experience is that it's an effective one.

Setting the home directory to a special device node file "/dev/null" sounds like a good way to shoot yourself in the foot, and I've never heard of this practice before. On Debian, at least, it seems like setting the home directory to "/nonexistent" is more common.

For example, running "deluser" later could end up performing a "remove home" cleanup operation, and you certainly don't want to remove the /dev/null file.

Yup and for outgoing traffic firewalling rules can also be put in place to only allow users authorized to emit traffic. Drop or reject anything by default, then only allow some users to send packets (like "john" and "_apt" [to update packages], etc.).

It's not incompatible with the other measures you described.

FWIW I also log, for every "user" on the system, anything from a user that's not supposed to access the net.

Unraveling this and dumping NSS would probably have a measurable increase in security and isolation. A backdoor xz thing in libnss would be catastrophic.

You're probably thinking of PAM (passwords and authentication), not NSS (hostname lookup). Both are direly in need of modernization, though.

Samba doesn't use the passwords or users in /etc/passwd directly. You have to map any SMB users into /etc/passwd users in Sambas database. Without that mapping they don't exist for Samba.

Yeah. It’s a pretty old-hat way of thinking. The ‘unified authentication database’ ship sailed long ago, for better or worse.

Reply on news.ycombinator.com