4 ms·

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 h

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.

cqqxo4zV46cp 3y ago
Yeah. It’s a pretty old-hat way of thinking. The ‘unified authentication database’ ship sailed long ago, for better or worse.
candiddevmike 3y ago
Unraveling this and dumping NSS would probably have a measurable increase in security and isolation. A backdoor xz thing in libnss would be catastrophic.
- duskwuff 3y ago
  You're probably thinking of PAM (passwords and authentication), not NSS (hostname lookup). Both are direly in need of modernization, though.
segfaultbuserr 3y ago
"No password = locked account" is today's default policy on most systems, for a reason.
- jesprenj 3y ago
  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.
  - segfaultbuserr 3y ago
    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.
    - 0x0 3y ago
      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.
  - TacticalCoder 3y ago
    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.
okl 3y ago
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-authentication.html https://www.postgresql.org/docs/current/client-authenticatio...]
jra_samba 3y ago
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.

cqqxo4zV46cp 3y ago

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

candiddevmike 3y ago

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

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

segfaultbuserr 3y ago

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

jesprenj 3y ago
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.
- segfaultbuserr 3y ago
  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.
  - 0x0 3y ago
    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.
- TacticalCoder 3y ago
  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.

okl 3y ago

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-authentication.html https://www.postgresql.org/docs/current/client-authenticatio...]

jra_samba 3y ago

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.