clearlinux/clear-linux-documentation
2
0
Fork 0
mirror of https://github.com/clearlinux/clear-linux-documentation.git synced 2026-08-27 19:05:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clean up of last 2 tooling pages in preparation for translations (#651)

Browse Source 
* Clean up in preparation for translations

- Standardize use of roles (remove use of `` and * for emphasis on special words or options)
- Misc clean up (opportunistic)
- Move pages to tooling in prep for final organization

Signed-off-by: Kristal Dale <kristal.dale@intel.com>

* Fixes code-block errors; minor verbiage clean up.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>
This commit is contained in:
Kristal Dale
2019-07-20 20:27:25 -07:00
committed by michael vincerra
parent 551ab83221
commit b2566c9be0
5 changed files with 68 additions and 117 deletions
Download Patch File Download Diff File Expand all files Collapse all files
source/clear-linux/concepts/concepts.rst
+2 -2
View File
@@ -10,10 +10,10 @@ different.
.. toctree::
:maxdepth: 2
stateless
../guides/tooling/stateless
swupd-about
mixer-about
bundles-about
autospec-about
security
../guides/tooling/security
telemetry-about
source/clear-linux/concepts/figures/stateless-1.png → source/clear-linux/guides/tooling/figures/stateless-1.png
View File
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 94 KiB

After

Width:  |  Height:  |  Size: 94 KiB

source/clear-linux/concepts/figures/stateless-2.png → source/clear-linux/guides/tooling/figures/stateless-2.png
View File
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 88 KiB

After

Width:  |  Height:  |  Size: 88 KiB

source/clear-linux/concepts/security.rst → source/clear-linux/guides/tooling/security.rst
+48 -91
View File
@@ -1,45 +1,36 @@
.. _security:
OS Security
*************************
###########
|CL-ATTR| aims to make systemic and layered security-conscious decisions
that are both performant and practical. This security philosophy is rooted
within the project's codebase and operating culture.
.. contents:: :local:
:depth: 1
Security in updates
*******************
The |CL| team believes in the benefits of software security through open
sourcing, incremental updates, and rapidly resolving known security advisories.
Security in Updates
===================
The |CL| team believes in the benefits of
software security through open sourcing, incremental updates, and
rapidly resolving known security advisories.
The latest Linux* codebase
--------------------------
The latest Linux\* codebase
===========================
|CL| uses the newest version of the Linux kernel which allows the operating
system to leverage the latest features from the upstream Linux kernel,
including security fixes.
Automated Effective Updating
----------------------------
Automated effective updating
============================
|CL| is incrementally updated multiple times per day.
This `rolling release model`_ allows |CL| to consume the latest security
fixes of software packages as soon as they become available.
There is no waiting for major or minor releases on |CL|.
This `rolling release`_ model allows |CL| to consume the latest security fixes
of software packages as soon as they become available. There is no waiting for
major or minor releases on |CL|.
An update is not effective if it is just simply downloaded onto a system.
It needs to be obtained *AND* ensured that the new patched copy is being
@@ -47,47 +38,34 @@ used; not an older copy loaded into memory. |CL| will let you know when a
service needs to be rebooted or do it for your automatically after
a software update, if desired.
In |CL| updates are delivered automatically, efficiently, and effectively. For
more information about software updates in |CL|, refer to the :ref:`swupd-guide`
guide.
In |CL| updates are delivered automatically, efficiently,
and effectively. For more information see
`documentation about Software Updates`_ in |CL|.
Automated CVE Scanning and Remediation
--------------------------------------
Automated CVE scanning and remediation
======================================
The sheer number of software packages and security vulnerabilities is growing
exponentially. Repositories of Common Vulnerabilities and Exposures (CVEs)
and their fixes, if known, are published by :abbr:`NIST` in a
National Vulnerability Database \ |NVD|\ and at \ |MITRE|\ .
|CL| employs a proactive and measured approach to addressing known
and fixable :abbr:`CVEs (Common Vulnerabilities and Exposures)`.
Packages are automatically scanned against
:abbr:`CVEs (Common Vulnerabilities and Exposures)` daily, and security
Packages are automatically scanned against CVEs daily, and security
patches are deployed as soon as they are available.
These combined practices minimize the amount of
time |CL| systems are exposed to unnecessary security risk.
Security in Software
====================
These combined practices minimize the amount of time |CL| systems are exposed to unnecessary security risk.
Security in software
*********************
Minimized attack surface
-------------------------
========================
|CL| removes legacy, unneeded, or redundant standards and
components as much as possible to enable the use of best known security
standards. Below are some examples:
|CL| removes legacy, unneeded, or redundant standards and components as much as
possible to enable the use of best known security standards. Below are some
examples:
* `RC4`, `SSLv3`, `3DES`, and `SHA-1` ciphers which have had known
vulnerabilities, have been explicitly disabled within many |CL| packages to
@@ -96,12 +74,10 @@ standards. Below are some examples:
* Services and subsystems which expose sensitive system information
have been removed such as the `finger` and `tcpwrappers`.
* `SFTP` has been disabled by default due to security
considerations.
* `SFTP` has been disabled by default due to security considerations.
Verified trust
--------------
==============
|CL| encourages the use of secure practices such as encryption
and digital signature verification throughout the system and discourages blind
@@ -109,29 +85,23 @@ trust. Below are some examples:
* All update operations from swupd are transparently encrypted and checked
against the |CL| maintainers' public key for authenticity.
More information can be found in this blog post:
`blog post about swupd security`_
More information about swupd security can be found in the
`Security for software update in Clear Linux* OS`_ blog post.
* Before being built, packages available from |CL| verify checksums and
signatures provided by third party project codebases and maintainers.
* |CL| features a unified certificate store, `clrtrust`_ which comes
ready to work with well-known Certificate Authorities out of the box.
`clrtrust`_ also offers an easy to use command line interface for managing
clrtrust also offers an easy to use command line interface for managing
system-wide chains of trust, instead of ignoring foreign certificates.
Compiled with secure options
----------------------------
While |CL| packages are optimized for performance on
Intel® architecture, security conscious kernel and compiler options are
sensibly taken advantage of. Below are some examples:
============================
While |CL| packages are optimized for performance on Intel® architecture,
security conscious kernel and compiler options are sensibly taken advantage of.
Below are some examples:
* Kernels shipped with |CL| are signed and disallow the usage of
custom kernel modules to maintain verifiable system integrity.
@@ -139,23 +109,19 @@ sensibly taken advantage of. Below are some examples:
* `Address space layout randomization (ASLR)`_ and
`Kernel address space layout randomization (KASLR)`_ are kernel features
which defend against certain memory based attacks.
More information can be found in a `blog post about PIE executables`_ .
More information about PIE executables can be found in the
`Recent GNU* C library improvements`_ blog post.
Security in system design
*************************
Simple, yet effective, techniques are used throughout the |CL| system design to
defend against common attack vectors and enable good security hygiene. Below are
some examples:
Security in System Design
=========================
Simple, yet effective, techniques are used throughout the
|CL| system design to defend against common attack vectors and enable
good security hygiene. Below are some examples:
* Full disk encryption using `Linux Unified Key Setup`_ (LUKS) is available
during installation.
* Full disk encryption using :abbr:`LUKS (Linux Unified Key Setup)` is available
during installation. Refer to `cryptsetup`_ for additional information about
LUKS.
* |CL| uses the PAM cracklib module to harden user login and password
security resulting in:
@@ -172,22 +138,13 @@ good security hygiene. Below are some examples:
* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH
login patterns, is installed with the :command:`openssh-server` bundle.
.. _`documentation about Software Updates`: https://clearlinux.org/documentation/clear-linux/concepts/swupd-about
.. _`cve-check-tool`: https://github.com/clearlinux/cve-check-tool
.. _`blog post about swupd security`: https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel-architecture
.. _`rolling release model`: https://en.wikipedia.org/wiki/Rolling_release
.. _`Security for software update in Clear Linux* OS`: https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel-architecture
.. _`Recent GNU* C library improvements`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements
.. _`rolling release`: https://en.wikipedia.org/wiki/Rolling_release
.. _`clrtrust`: https://github.com/clearlinux/clrtrust
.. _`Address space layout randomization (ASLR)`: https://en.wikipedia.org/wiki/Address_space_layout_randomization
.. _`Kernel address space layout randomization (KASLR)`: https://lwn.net/Articles/569635/
.. _`dm-verity`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt
.. _`SELinux`: https://github.com/SELinuxProject
.. _`Linux Unified Key Setup`: https://gitlab.com/cryptsetup/cryptsetup/
.. _`blog post about PIE executables`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements
.. _`cryptsetup`: https://gitlab.com/cryptsetup/cryptsetup/
.. _`Tallow`: https://github.com/clearlinux/tallow
.. |NVD| raw:: html
source/clear-linux/concepts/stateless.rst → source/clear-linux/guides/tooling/stateless.rst
+18 -24
View File
@@ -3,24 +3,23 @@
Stateless
#########
In most operating systems, files can become intermingled with user and system
data and configurations.
In most operating systems, user data, system data, and configuration files
can become intermingled.
.. figure:: figures/stateless-1.png
:scale: 45%
:scale: 45%
:align: center
:alt: Stateless: User and system files mixed
Figure 1: Without stateless, user and system files become mixed on the filesystem over time.
|CL-ATTR| has a stateless design philosophy of which the goal is to provide an
|CL-ATTR| has a stateless design philosophy with the goal to provide an
:abbr:`OS (operating system)` that functions without excessive user
configuration or customization. Stateless in this context does *not* mean
ephemeral or non-persistent.
.. contents:: :local:
:depth: 2
:depth: 1
File-level separation
*********************
@@ -29,7 +28,7 @@ To accomplish a stateless design the Linux Filesystem Hierarchy is separated
between user-owned areas and |CL|-owned areas.
.. figure:: figures/stateless-2.png
:scale: 45%
:scale: 45%
:align: center
:alt: Stateless: User and system files separation
@@ -48,10 +47,10 @@ Files under the :file:`/etc/`, :file:`/home`, and :file:`/var` directories are
owned and managed by the user. A freshly installed |CL| system will only have
a minimal set of files in the :file:`/etc/` directory and software installed
by |CL| does not write to :file:`/etc`. This operating assumption allows |CL|
users to clearly identify the configuration that makes their system unique.
users to clearly identify the configuration that makes their system unique.
Software Configuration
Software configuration
**********************
With stateless separation, default software configurations are read in order
@@ -62,12 +61,12 @@ Default configurations
======================
Software in |CL| provides default configuration values so that it is
immediately functional, whenever it is appropriate to do so.
immediately functional, whenever it is appropriate to do so.
|CL| distributed software packages may be directly modified to include default
configuration values or default configuration files may be provided by |CL|
under :file:`/usr/share/defaults`. These files can be referenced as templates
for customization.
for customization.
For example, the default configuration that Apache uses when installed can be
found at :file:`/usr/share/defaults/httpd/httpd.conf` directory.
@@ -81,39 +80,37 @@ modified by the user under :file:`/etc/`. If the configuration file does not
already exist, it can be created in the appropriate location.
User defined configuration files should contain the minimal set of desired
changes and rely on default configuration for the rest.
changes and rely on default configuration for the rest.
For example, a customized Apache configuration can be used instead by:
#. Create the destination directory for the configuration:
.. code :: bash
.. code-block:: bash
sudo mkdir /etc/httpd
#. Copy the default configuration as a reference template:
.. code :: bash
.. code-block:: bash
sudo cp /usr/share/defaults/httpd/httpd.conf /etc/httpd/
#. Make any desired modifications to the configurations:
.. code :: bash
.. code-block:: bash
sudoedit /etc/httpd/httpd.conf
#. Reload the service or reboot the system to pickup any changes:
.. code :: bash
.. code-block:: bash
systemctl daemon-reload httpd && systemctl restart httpd
This pattern can be used to modify the configurations of other programs too.
The `stateless man page`_ has application-specific examples.
System reset
************
@@ -124,22 +121,19 @@ easily restored by simply deleting everything under :file:`/etc/` and
Running the commands below effectively performs a system reset as if it was
just installed:
.. code::
.. code-block:: bash
sudo rm -rf /etc
sudo rm -rf /var
In other Linux distributions, this can be a catastrophic action that renders a
system unable to boot.
In other Linux distributions, this can be a catastrophic action that renders
a system unable to boot.
Additional information
**********************
* `stateless man page`_
* `Where is /etc/fstab in Clear Linux? <https://clearlinux.org/news-blogs/where-etcfstab-clear-linux>`_
.. _`stateless man page`: https://github.com/clearlinux/clr-man-pages/blob/master/stateless.7.rst