Kees Cook

Doing one of these things may introduce a security vulnerability, depending on the rest of your environment.

Some programs that use select(2) are known to assume that FD_SETSIZE is at least the maximum number of file descriptors available (instead of checking FD_SETSIZE). This lack of bounds checking may lead to a stack or heap overflow and a security vulnerability.

More recently, if you build with fortified glibc options, then you'll get automatic bounds checking, but do you know that your own daemons are built this way?

This is an example of why it's not a good idea to arbitrarily change a list of default settings system-wide without understanding the implications. The defaults have not been changed for a reason; otherwise distributions would already ship with these changes.

References: https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html http://www.outflux.net/blog/archives/2014/06/13/5-year-old-glibc-select-weakness-fixed/

not necessarily. there are software emulation -- examples would be W^X on OpenBSD[1] and Grsecurity/PaX on linux[2]. Ubuntu[3] and RedHat[4] also has (partial) NX-emulation thanks to ExecShield.

As for OpenBSD and Linux without grsec/pax, one can bypass NX (whether the CPU has the NX-bit or not) by marking the region with the shellcode as executable, eg:

mprotect(shellcode & -pagesize, len, PROT_EXEC);

((void()()) shellcode)();

in an exploit this could be accomplished by ROPing

1: http://marc.info/?l=openbsd-misc&m=105056000801065

2: https://pax.grsecurity.net/docs/mprotect.txt

3: https://outflux.net/blog/archives/2009/05/14/nx-emulation-in-ubuntu/

4: https://en.wikipedia.org/wiki/Exec_Shield

Kees Cook and others have been porting or reimplementing features exclusive to grsec in upstream linux.

https://outflux.net/blog/archives/2016/09/26/security-things-in-linux-v4-3/

https://outflux.net/blog/archives/2016/09/27/security-things-in-linux-v4-4/

https://outflux.net/blog/archives/2016/09/28/security-things-in-linux-v4-5/

https://outflux.net/blog/archives/2016/09/30/security-things-in-linux-v4-6/

https://outflux.net/blog/archives/2016/10/03/security-things-in-linux-v4-7/

https://outflux.net/blog/archives/2016/10/04/security-things-in-linux-v4-8/

And naturally some stuff is exclusive to linux upstream, though grsec will benefit from those automatically if they deem it good enough.

I like data like this - it reminds me of the pleasant places maps[1].

That said - you have to be wary of both types of maps because it doesn't take into account other potentially annoying factors. The biggest being humidity - there's a huge difference between 90 degree phoenix and 90 degree miami. Then there's rainfall, and one a lot of people don't think about - wind.

To add - if you're thinking about seriously comparing two climates, check out this comparison tool [2]. Has any metric you can dream of charted together.

1 - https://kellegous.com/j/2014/02/03/pleasant-places/

2 - https://outflux.net/weather/noaa/index.php

Any risk is increased by sloppy implementation. For example, every single keystroke is being sent over HTTP without encryption. (http://www.outflux.net/blog/archives/2012/11/09/product-search-in-ubuntu-12-10/)

Today, if you want to de-Amazon Ubuntu, it's not just the shopping lens you have to disable, you should also remove Unity web app integration. (https://news.ycombinator.com/item?id=4888234)

If it gets to the point where you have to run a shell script to remove the 'spyware' (for lack of a better word), Ubuntu will have a real marketing problem on its hands.

According to http://www.outflux.net/blog/archives/2009/10/22/tpm-as-rng/#comment-793, TPM may even be using PRNGs. So you're right that the quality of output need not be better than what a modern OS already provides. (I am not aware of any case where a properly-used /dev/random failed to produce sufficient entropy. Note that doing something sensible at boot is part of "properly-used" here.)

It is possible to provide true randomness from a chip, but it's probably cheaper not to.