A simple easy way to keep a lid on privelige escalation is to remove all the files that you computer does not absolutely require to do its job.
Especially the development tools: the Morris worm enabled portability by distributing itself in source code form then building its binary on its target hosts.
My sister once read a novel about some very traditional, strictly religious people who fastened their shirts with string ties as they felt buttons were hooks that the Devil could use to grab hold of you.
I feel much the same way about files. I dont know what tomorrow's zero-day will look like but the chances are quite good that it will depend on a file that is installed by default. Cliff Stoll wrote in "The Cuckoo's Egg" of a subtle bug in a subprogram used by GNU emacs for email. Had the Lawrence Berkeley Laboratory used vi rather than emacs they would not have been vulnerable. ;-D
Yes it is a step in the right direction not to run daemons or windows services you dont need but its even better to remove them.
In 1990 I wrote an A/UX 2.0 remote root exploit to drive home my objection to one single file having incorrect permissions. Its source was about a dozen lines. That particular file was required but our default installs have many files we dont really need.
Also if you can read - not just execute - the binary to any program or library then your malware can load it into its memory then execute it. We have no way of knowing who is going to do that tomorrow but we do know there are many binaroies we do not really need.
If you develop code for your server, install the same distro in a vm on your desktop box then compile it there.
> A simple easy way to keep a lid on privelige escalation is to remove all the files that you computer does not absolutely require to do its job.
Taken to its logical conclusion, you sort of end up with a unikernel system, like Mirage OS[1]: only the code necessary for the execution of the service is compiled into the kernel. These systems don't even have a shell.
While it is helpful that hardware memory management will protect against erroneous and malicious code, even better is for the code to be correct and ethical.
This because the MMU hardware takes up power, it costs money, generates heat and uses real estate. Also the software is complex and uses a lot of memory for page tables and complex allocation schemes.
The Oxford Semiconductor 911, 912 and 922 didnt even have a kernel nor did they have dynamic memory allocation, just stack and static memory with an infinite loop operating a state machine. A huge PITA to debug but the memory and flash were quite cheap because there werent very much of either.
Especially the development tools: the Morris worm enabled portability by distributing itself in source code form then building its binary on its target hosts.
My sister once read a novel about some very traditional, strictly religious people who fastened their shirts with string ties as they felt buttons were hooks that the Devil could use to grab hold of you.
I feel much the same way about files. I dont know what tomorrow's zero-day will look like but the chances are quite good that it will depend on a file that is installed by default. Cliff Stoll wrote in "The Cuckoo's Egg" of a subtle bug in a subprogram used by GNU emacs for email. Had the Lawrence Berkeley Laboratory used vi rather than emacs they would not have been vulnerable. ;-D
Yes it is a step in the right direction not to run daemons or windows services you dont need but its even better to remove them.
In 1990 I wrote an A/UX 2.0 remote root exploit to drive home my objection to one single file having incorrect permissions. Its source was about a dozen lines. That particular file was required but our default installs have many files we dont really need.
Also if you can read - not just execute - the binary to any program or library then your malware can load it into its memory then execute it. We have no way of knowing who is going to do that tomorrow but we do know there are many binaroies we do not really need.
If you develop code for your server, install the same distro in a vm on your desktop box then compile it there.