What could possibly break ? Whatever application needing to associate some user id to its user name. ls as an example.

For curiosity, why do you want to prevent users from being able to see other system users?

This is a webserver hosting many websites - and usernames/group names contain the names which allow to identify which websites are running on the server. I.e. a username can be "example.com", or "example.tld" (or similar, which allow to figure out the full domain name). Because the sites run similar software - if one site is hacked due to some vulnerability - the attacker could enumerate the sites running on the server and infect them using the same vulnerability. Hiding the ability to simply list the domains makes it harder for the attacker, and gives more time for website owners to update.

It sounds like a better approach would have been to use more anonymous usernames. Or, by disallowing shell access. Also, if one site is hacked, the other sites are compromised, regardless.

I agree regarding more anonymous usernames. However, this is an existing system and it would be too much effort to change it. Regarding shell access - this is required by site owners. But even if it wasn't allowed - a compromised site could run any system command using uploaded or modified PHP files. I don't agree with "if one site is hacked, the other sites are compromised, regardless" - with enough isolation, other sites are protected, because the attacker has no means to access them (assuming the compromised site only runs as a normal, unprivileged user different from other sites).

"with enough isolation" -- if you assume your kernel doesn't have local privilege escalation bugs, but that's a foolish thing to assume. Local privilege escalation bugs are a dime a dozen.

"Local privilege escalation bugs are a dime a dozen" Please name one kernel privilege escalation exploit for a recent Ubuntu kernel? I don't claim they don't exist, or won't ever exist - but probability is dim. Anyway, whether I chmod 640 /etc/passwd doesn't make kernel exploits easier or harder.

@Tomasz ubuntu.com/search?q=privilege+escalation+CVE

@Kusalananda "recent Ubuntu kernel" (or otherwise userspace). Most of these are exotic setups and all of them are quite old. Again - I don't claim new ones won't ever exist, but that's what system updates are for.

Well, I suppose you're safe then.

@Kusalananda you just made the whole docker and other container world very insecure!

I don't really know what you're getting at. You first say that you're concerned about hacked sites on your server. You then claim you won't be touched by privilege escalation exploits because they aren't common. When pointing you to Ubuntu privilege escalation CVE's, you now claim that I have said something about container security? If you're using containers, then what's the issue with /etc/passwd?!

Kernel privilege escalations work very well in container scenarios. If these kernel privilege escalations were however so common as pictured here, the containers wouldn't be a thing we see today. Ergo: kernel privilege escalations are not so common in real world and assuming I run a sufficiently updated system, there is little danger in my case.

I honestly fail to follow the logic of this. Are you using containers? Are you worried about privilege escalation exploits? Why are these things not part of your question at all if they are so central to the comment thread?

It’s honestly not hard for a remote attacker to figure out that you happen to host some other site.. I can think of half a dozen ways to do it on a typical (reasonably secure) virtual hosting setup from an unprivileged remote ACE exploit without even considering your specific username quirk.

@AustinHemmelgarn "I can think of half a dozen ways to do it" Could you give at least one way? For now, there are the following limitations in place, but I'd be glad to know if I overlooked anything: 1) website user (no matter if shell or PHP code) can only see its own processes, 2) website user can't see user/group list, 3) website user can't read the webserver, PHP configuration, 4) website user can't see what other databases are on the system, 5) website user can't list the directory where other sites are located, 6) website user can't list cronjobs, 7) website user can't read logs

@Tomasz Unless you’re using TLS SNI with ECH and forcing use of HTTPS (with no HTTP access at all, not even a redirect), getting remote ACE on the web server process will allow an attacker to inspect incoming traffic and see what virtual hosts clients are connecting to. It’s unlikely you’ve closed that scenario off, as doing so actually breaks a lot of web browsers.

@AustinHemmelgarn "getting remote ACE on the web server process will allow an attacker to inspect incoming traffic" - no, by default in most Linux distributions, unprivileged users are not allowed to capture traffic (pcap), this scenario won't work.

@Tomasz The web server is the thing handling the traffic already. If someone gets arbitrary code execution in that process context, they can trivially read any data that process is able to read, including all of the data being sent over any connection to that web server. No need for pcap or special privileges.

@AustinHemmelgarn Getting privilege escalation from some-user (our hacked user) to webserver or php-fpm control process is equivalent to getting root. There were bugs which allowed that (also recently), but this is VERY hard to do in updated systems.

@Tomasz It’s more correct to say that there are not known bugs that allow it on up to date systems. Rule two of proper security (right after maintaining proper physical security) is to never assume your system is secure just because you do not know of any security issues with it.