I do not understand how this applies to the question. No one will be in the sudoers file, so no one can type sudo in the production system. They won't be able to type su either. What would you do against these obstacles?

the question behind the question is "how can i protect myself against attacks" - isn't it?

so, i think one shouldn't get too hung up about root (esp. since this is a hypothetical scenario discussion) and see what else is possible to exploit.
quite a lot is possible without ever gaining root privileges.
quite a lot is possible without even writing to your system.

Mainstream distros too, like peppermint, use squashfs when you make a usb flash drive out of the .iso using rufus. Is openelec more attractive because it is true open source or something?

More like, "is this strategy, or anything inspired from this strategy, any good to protect myself against hackers that I knowingly mix with to learn underground security?".

The critical factor is nonpersistency, ie whatever malicious thing happens must be stoppable by unplugging the power supply. Hence the concern about root privileges that can modify the boot drive enough to make the malicious behaviour permanent.

They already look like they are read only for everyone but root, here's one, wouldn't it be a major oversight otherwise?

-rwsr-xr-x 1 root root 94792 Nov 24 00:25 /bin/mount

That is not read-only, your /bin/mount has the execute bit set for groups and others, but granted some programs require the execute bit in order for a regular user to be able launch them (such as /bin/mount and /bin/sudo), and to allow those programs to temporarily do what they need to do as root (then after drop those privileges and assume a less-privileged UID).. But I would take off the execute bit on any setuid program that you don't actually use.. And I agree it would be an oversight but remember that distributions set things up for you and assume what you want (mostly so things just work).. It's up to you to actually configure the system to how you actually want it configured.

So as it is now my /bin/mount cannot be used for privilege escalation the way you said, right?

If it had the write permission set for all users, wouldn't that be a terrible design?

Im not certain with /bin/mount but many programs have surprising capabilities that when combined with setuid or setgid permissions, could result in shockingly bad security.. For instance, with the setuid permission set for ls, one might be able to read the contents of a directory to which one's current user account is not supposed to have access.. Another example, the Vim text editor has the ability to execute shell commands. If Vim is setuid root, then even when it is being used as an unprivileged user one could execute commands from within Vim as if logged in at the shell as the root user account.. And yes giving all users write permissions would be a terrible idea which is why it's not there by default.

What bad things can an ordinary user who lacks root privileges do with the following binaries that are setuid root?

-rwsr-xr-x 1 root root 30800 May 15 2015 /bin/fusermount
-rwsr-xr-x 1 root root 94792 Nov 24 00:25 /bin/mount
-rwsr-xr-x 1 root root 44168 May 8 2014 /bin/ping
-rwsr-xr-x 1 root root 44680 May 8 2014 /bin/ping6
-rwsr-xr-x 1 root root 36936 Jan 27 2016 /bin/su
-rwsr-xr-x 1 root root 69120 Nov 24 00:25 /bin/umount
-rwsr-xr-x 1 root root 35608 Jun 28 2013 /sbin/mount.cifs
-rwsr-xr-x 1 root root 46424 Jan 27 2016 /usr/bin/chfn
-rwsr-xr-x 1 root root 41336 Jan 27 2016 /usr/bin/chsh
-rwsr-xr-x 1 root root 72280 Jan 27 2016 /usr/bin/gpasswd
-rwsr-xr-x 1 root lpadmin 14336 Feb 17 20:59 /usr/bin/lppasswd
-rwsr-xr-x 1 root root 75256 Oct 21 2013 /usr/bin/mtr
-rwsr-xr-x 1 root root 36592 Jan 27 2016 /usr/bin/newgrp
-rwsr-xr-x 1 root root 47032 Jan 27 2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 23304 Nov 24 2015 /usr/bin/pkexec
-rwsr-xr-x 1 root root 155008 Oct 14 2016 /usr/bin/sudo
-rwsr-xr-x 1 root root 23104 May 8 2014 /usr/bin/traceroute6.iputils
-rwsr-sr-x 1 root root 10192 Jan 27 2015 /usr/bin/X
-r-sr-xr-x 1 root root 18696 Apr 24 18:01 /usr/lib/chromium-browser/chrome-sandbox
-rwsr-xr-- 1 root messagebus 310800 Dec 7 13:02 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-x 1 root root 10240 Mar 27 18:34 /usr/lib/eject/dmcrypt-get-device
-rwsr-xr-x 1 root root 440416 Aug 11 2016 /usr/lib/openssh/ssh-keysign
-rwsr-xr-x 1 root root 14776 Nov 24 2015 /usr/lib/policykit-1/polkit-agent-helper-1
-r-sr-xr-x 1 root root 9532 Jun 2 2016 /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
-r-sr-xr-x 1 root root 14320 Jun 2 2016 /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper
-rwsr-xr-- 1 root dip 347296 Apr 21 2015 /usr/sbin/pppd
-rwsr-sr-x 1 libuuid libuuid 18904 Nov 24 00:25 /usr/sbin/uuidd

I haven't gotten to into this but something I would definitely do is disable chsh, and make is so that no one can view your /etc/group file.. Also you can audit setuid/setgid system calls..

There are many ways attackers use to inject holes into systems. Removing one entry point is unlikely to change their ability.

I was referring to the typical setup of the sudoers file with regard to the behavior of the wheel group.

"setuid" is another classic hole: if you can arrange for this bit to be turned on, and then for a program to become owned by root (and kindly notice that, frequently, all programs in /bin are owned by this user!), then you have a hole. A trojan horse.

@Ulysses I apologize I meant to say make it so that you they can't view the /etc/group file, if you chmod go-r /etc/passwd then you wont be able to login.. Here's a command you might find useful to change the permissions of setuid programs find / -perm -4000 -print -okdir chmod go-x {} \;
This will go through your list of setuid programs (one by one) and prompt you if you would like to change the permissions to read-only for groups and others. It's a lot faster than chmodding them manually...

I agree with this quote.. The problem is code that can be exploited is in most cases still in the program, and patches that try to fix the vuln do it in a way that just forces the attacker to take a different approach to exploit the vulnerable code again.. Like Adobe Flash for example all of their patches fix the same vulnerability. Or another example is disabling/enabling features such enabling airplane mode on your phone, or disabling JS on your browser (their just soft switches, disabling the features in those programs doesn't make the code disappear).. The best you can do is install a hardened kernel, keep up-to-date on CVEs, and keep your head below the firing line (i.e. switch up software or use a different versions of your current program (that are not exploitable), just temporarily until the vuln in your preferred program is fixed).

Or I switch to a security oriented distro that has all setuid root binaries set up for maximum security as it has everything set up for maximum security. Maybe with SElinux preconfigured with all binaries signed and checked or something.

Maybe one distro for the hypervisor, another for the guest that is exposed to danger. Maybe a bare metal hypervisor too. Any recommendations other than backtrack and kali?