This is the ages old question that started with “Multi-user” systems (Unix) many years ago … “Who can exec what, when and where?”. Over the decades, the same answer is “It Depends on how the system is to be used”. No one solution/configuration works for all conditions
“Generally” speaking, the convention was:
/sbin == system centric binaries that were there system to system (Standard Binaries)
/bin == usually binaries that were expected for convenience but not critcal
/usr == resource binaries and libraries (Unix System Resources)
/usr/local == binaries specific to the deployment
/opt == where AT&T usually put the binaries specific to the deployment
Linux still follows a lot of these same conventions to this day (Thankfully)
Then came the division of types of systems, servers vs workstations
Servers were usually very restrictive as most only had administrative user accounts and all execs were in specific places, usually not allowed in the user’s home directory and in some cases, chroot jails were fairly common (like on DoD systems/C2).
Workstations were similar to servers with one major difference, user’s where allowed to have execs in their home directory.
So, … “It Depends”
“In short I want a Linux system more like Android, as Android is damn secure, EVEN THOUGH it is the most popular OS on the planet”
The biggest reason this appears to be the case is because most Android deployments are read-only file systems and there is basically no root access as we know it in Linux UNLESS you root it… also Android is very rigorously QA’d. Android is also nowhere near as flexible as the typical Linux desktop/workstation (which would make me abandon Linux in favor of Free BSD or Open Solaris … or … maybe … even an Apple …)
Yes SELinux is for this, but only confined users (which, because they are still not ready, have been surpassed by Flatpak and might even be incompatible with it?) can protect USER DATA which is normally the most valuable data on a system.
(Insert root xkcd in here)
And yes, Android sandboxes every program, only allows code to be executed from installed apps, and protects user data. GrapheneOS improves this a lot more.
But please I dont want to discuss here, we already had a constructive thread before.
I moved the comments as they elongate the thread with stuff I dont want to discuss, at least not there. I hope you are okay with that.
Fyi /bin is a symlink to /usr/bin. Next the files in /usr/sbin will be moved to /usr/bin (f42 or f43?).
Historically /bin and /sbin contained the minimum set of programs needed to boot the system. /usr was mounted during boot to provide access to more programs. /usr was the very old name for /home but became the overflow for /bin.
“Age old questions” in the context of computer systems. What have we come to!!!
It is fun to think back to a time when /sbin was where statically linked binaries were placed and only more critical utilities were linked statically. That way an early boot failure could be debugged more easily though I think they were also used in a normal boot process before dynamic libraries were mounted. Once fully up and running you would use /bin/sh and not /sbin/sh for instance.
There was aways a /bin I recall as scripts expected utils like /bin/ls and /bin/sh to be runningable from absolute paths.
The reason for the spit between the programs in / and those in /usr was simply the need to run code to /sbin/mount /usr which was typical a bigger disk or partition.
… and I can remember entire sites/deployments mounting /usr read-only specifically to prevent unauthorized changes to the binaries. /bin and /sbin where in the root partition of the disk because the commands to bring the rest of the system to an operational state (like mount and sh …). I do also remember someone (yours truly) putting /bin and /sbin into their own partitions just to see what would happen… can you guess what happened on the next boot … yup … get the tapes out …
