[RfD] Provide an 'Armbian security defaults' document in lib.docs

[tkaiser]

Based on discussions the last days/weeks it seems obvious to me that we should document default Armbian security so that people know what they get and where to tweak if they have specific concerns.

 

I took a few minutes to start with a list of issues that should IMO be addressed (no specific order):

• Explain where password strength policies originate
• Restore distro default sshd settings if concerned: sed -i 's/PermitRootLogin yes/PermitRootLogin without-password/' /etc/ssh/sshd_config
• Use and purpose of haveged: https://github.com/igorpecovnik/lib/issues/503
• 'Secure delete' on SD card, eMMC or SSD (overwriting contents on the FS layer requires a sync call if followed by a rm command since otherwise optimized FS drivers won't write data to media, use an appropriate amount of random data -- not /dev/zero since optimization strategies known from SSDs will appear in eMMC and maybe SD card controllers soon -- when overwriting to force the FTL to mark the relevant pages as unused and use 150 percent of the capacity of the flash media to really overwrite sensitive data. Basics here)

Would be great if others could add topics to be addressed by such a document to get an idea about contents and structure prior to actually writing this stuff.

[arox]

... document default Armbian security so that people know what they get and where to tweak ...

 

I fully approve. This should be done in every distro. There is a limit to auto-magically configure a system : no one can decide for others the level of security enforced nor lock everything in the system, although distributors are evidently very reluctant to provide an insecure system.

 

If you intend to use a board as - for example - a flying controller - not even connected to the network, you could as well do a "chmod -R 777 /". If you connect your board directly to Internet in a publicly available sensible site, even the more strict security policy may be insufficient. And I never saw a distro that install the internet browser in a sandbox - which should be in fact if you are intending to really protect your system.

 

The problem is to avoid stupid things :

- ask for a root password before being sure of keyboard map.

- silently invert security policy (change a no-listen-tcp to listen-tcp option in Xorg !)

- add security tricks in configuration files as for ssh without warning users in install tutorials.

- set a default root password not clearly exposed in install procedure (as if hackers would have more difficulty to find it that users ?!?)

 

I don't see other solution than clearly expose the level and place where security policy is enforced. At least, it is always possible to edit an SDCARD before install if you know you will run into trouble. (sometimes, I think it would be more logical to configure his install media than configure an auto-magic installing system - and btw be sure the flash procedure went well ...)