From 90bf8f6256b5b6c6cc240045c0f68e3d6031d544 Mon Sep 17 00:00:00 2001 From: puneetse <22071208+puneetse@users.noreply.github.com> Date: Thu, 23 May 2019 16:19:02 -0700 Subject: [PATCH 1/5] Add updating section to NVIDIA doc (#501) --- source/clear-linux/tutorials/nvidia.rst | 96 +++++++++++++++++++------ 1 file changed, 75 insertions(+), 21 deletions(-) diff --git a/source/clear-linux/tutorials/nvidia.rst b/source/clear-linux/tutorials/nvidia.rst index afccf20c..55c84a88 100644 --- a/source/clear-linux/tutorials/nvidia.rst +++ b/source/clear-linux/tutorials/nvidia.rst @@ -52,12 +52,12 @@ Install the appropriate DKMS bundle using the instructions below: :end-before: kernel-modules-dkms-install-end: -Download and install the NVIDIA Linux Driver -******************************************** +Download and install the NVIDIA Drivers +*************************************** -Download the NVIDIA Linux Driver -================================ +Download the NVIDIA Drivers for Linux +===================================== #. Identify the model of NVIDIA GPU that is installed. @@ -107,28 +107,35 @@ needs to be disabled before installation can continue. -Install the NVIDIA Linux Driver -=============================== +Configure the Dynamic Linker +============================ The NVIDIA installer will be directed to install files under :file:`/opt/nvidia` as much as possible to keep its contents isolated from the -rest of the |CL| files under :file:`/usr`. +rest of the |CL| system files under :file:`/usr`. The dynamic linker will +need to be configured to use the NVIDIA-provided libraries. + + +#. Configure the dynamic linker to look for and cache shared libraries under + :file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32`. + + .. code-block:: bash + + echo "include /etc/ld.so.conf.d/*.conf" | sudo tee --append /etc/ld.so.conf + + sudo mkdir /etc/ld.so.conf.d + printf "/opt/nvidia/lib \n/opt/nvidia/lib32 \n" | sudo tee --append /etc/ld.so.conf.d/nvidia.conf + + + +Install the NVIDIA Drivers +========================== #. A terminal not running on */dev/tty1* is useful to view uninterrupted installation progress. Switch to a secondary virtual terminal by pushing :command:`CTRL + ALT + F2` or remotely login over SSH. -#. Configure the dynamic linker to look for and cache shared libraries under - :file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32` where the NVIDIA - installer will place libraries. - - .. code-block:: bash - - echo "include /etc/ld.so.conf.d/*.conf" | sudo tee --append /etc/ld.so.conf - sudo mkdir /etc/ld.so.conf.d - printf "/opt/nvidia/lib \n/opt/nvidia/lib32 \n" | sudo tee --append /etc/ld.so.conf.d/nvidia.conf - #. Navigate into the directory where the NVIDIA installer was downloaded. @@ -183,8 +190,55 @@ rest of the |CL| files under :file:`/usr`. with the proprietary NVIDIA drivers installed. -Uninstalling the NVIDIA driver -****************************** + + +Updating the NVIDIA Drivers +*************************** + +The proprietary NVIDIA drivers are installed manually outside of :ref:`swupd +` and must be updated manually when needed. + +Updating the NVIDIA drivers follows the same steps as initial installation, +however the desktop environment must first be stopped so that the drivers are +not in use. + +#. Follow the steps in `Download the NVIDIA Drivers for Linux`_ section to get + the latest NVIDIA drivers. + +#. Temporarily set the default boot target to the *multi-user* which is + a non-graphical runtime. + + .. code-block:: bash + + sudo systemctl set-default multi-user.target + + +#. Reboot the system and log back in. It is normal for the graphical + environment to not start. + +#. Follow the steps in `Install the NVIDIA Drivers`_ section to update + the NVIDIA drivers. This installation will overwrite the previous NVIDIA + drivers and files. + +#. Set the default boot target back to the *graphical* target. + + .. code-block:: bash + + sudo systemctl set-default graphical.target + + +#. Reboot the system and log back in. + +#. Trigger a flatpak update which will download the runtime corresponding + with the new NVIDIA drivers for flatpak apps requiring it. + + .. code-block:: bash + + flatpak update + + +Uninstalling the NVIDIA Drivers +******************************* The NVIDIA drivers and associated software can be uninstalled and nouveau driver restored by: @@ -202,8 +256,8 @@ driver restored by: #. Follow the prompts on the screen and reboot the system. -Debugging NVIDIA driver installation -************************************ +Debugging Installation of NVIDIA Drivers +**************************************** * The NVIDIA driver places installer and uninstaller logs under :file:`/var/log/nvidia-install` and :file:`/var/log/nvidia-uninstall`. From 4b00a981d70b4d973b50891a441b57f227c0612d Mon Sep 17 00:00:00 2001 From: michael vincerra <37549381+mvincerx@users.noreply.github.com> Date: Fri, 24 May 2019 12:16:47 -0700 Subject: [PATCH 2/5] Removes mixin.rst and all references to it. (#506) - Closes #478 Signed-off-by: Michael Vincerra --- .../clear-linux/concepts/autospec-about.rst | 1 - source/clear-linux/concepts/mixer-about.rst | 30 +-- source/clear-linux/guides/deploy-at-scale.rst | 40 +--- source/clear-linux/guides/guides.rst | 1 + .../clear-linux/guides/tooling/autospec.rst | 3 +- source/clear-linux/guides/tooling/mixer.rst | 1 - source/clear-linux/guides/tooling/mixin.rst | 191 ------------------ 7 files changed, 8 insertions(+), 259 deletions(-) delete mode 100644 source/clear-linux/guides/tooling/mixin.rst diff --git a/source/clear-linux/concepts/autospec-about.rst b/source/clear-linux/concepts/autospec-about.rst index 61575fe2..ed3e03d9 100644 --- a/source/clear-linux/concepts/autospec-about.rst +++ b/source/clear-linux/concepts/autospec-about.rst @@ -102,6 +102,5 @@ Related topics * :ref:`autospec` * :ref:`mixer` -* :ref:`mixin` .. _autospec readme: https://github.com/clearlinux/autospec diff --git a/source/clear-linux/concepts/mixer-about.rst b/source/clear-linux/concepts/mixer-about.rst index 485ea846..0548ed50 100644 --- a/source/clear-linux/concepts/mixer-about.rst +++ b/source/clear-linux/concepts/mixer-about.rst @@ -11,10 +11,8 @@ needs. However, if you need additional customization or content, |CL| provides the mixer tool. Depending on your needs, the mixer tool allows you to: -1. :ref:`create-mix` to create a distinct derivative of the |CL| that +* :ref:`create-mix` to create a distinct derivative of the |CL| that contains your custom software. -2. :ref:`create-mixin` to add custom bundles but also keep updating the OS - from upstream. .. _create-mix: @@ -43,31 +41,6 @@ act as your own OSV. There is a greater level of responsibility, requiring more infrastructure and processes to adopt. However, with this approach, you have a higher degree of control and customization of your custom |CL|. - -.. _create-mixin: - -Create a mixin -============== - -The second option is to use the :command:`mixin` tool, a light wrapper for -mixer, to create custom bundles and sideload them into your upstream version -of |CL|. A mixin is useful when you need to add custom or 3rd -party content but want to keep on the upstream update cycle, as shown in -Figure 2. You can also create new bundles using upstream packages. - -.. figure:: figures/mixer-about-2.png - :scale: 75% - :alt: Creating a custom mix. - - Figure 2: With a mixin you can add custom bundles, but stay on upstream. - -Mixin is primarily intended for end users. It is easier to adopt as it does -not require breaking from upstream or acting as an OSV. With mixin - -* You are responsible for maintaining and testing your custom bundle(s). -* You retain access to all upstream bundles and updates. -* You can easily revert your system back to the upstream version. - Related topics ============== @@ -76,7 +49,6 @@ mixer and related topics to decide which customization approach is best for you. * :ref:`mixer` -* :ref:`mixin` * :ref:`bundles-about` * :ref:`swupd-about` * :ref:`deploy-at-scale` diff --git a/source/clear-linux/guides/deploy-at-scale.rst b/source/clear-linux/guides/deploy-at-scale.rst index 8488e1b0..6935f378 100644 --- a/source/clear-linux/guides/deploy-at-scale.rst +++ b/source/clear-linux/guides/deploy-at-scale.rst @@ -3,8 +3,8 @@ Deploy at Scale ############### -Once you are comfortable with |CL-ATTR| :ref:`concepts `, your next step -as a system administrator is to understand how to deploy |CL| +Once you are comfortable with |CL-ATTR| :ref:`concepts `, your +next step as a system administrator is to understand how to deploy |CL| at scale in your environment. In this document the term *endpoint* refers to a system targeted for @@ -32,39 +32,10 @@ Different business scenarios call for different deployment methodologies. distribution or the option to fork away from the |CL| distribution and act as your own :abbr:`OSV (Operating System Vendor)`. -Below are overviews of both approaches and some considerations. +Below is an overview of some considerations. -Option #1: Use the |CL| as the upstream origin (mixin) ------------------------------------------------------- - -This approach is *easier to adopt* by relying on the |CL| upstream for -packaging updates for you to deploy. - -Custom software or packages that are not available in a preformed bundle -can be added using the `mixin process`_ to form a custom bundle. -If custom bundles are needed, you will be responsible for maintaining -the custom bundle(s) and testing between |CL| releases in your environment, -while the rest of the operating system and preformed bundles come from the -|CL| upstream. - -#. Ensure |CL| systems are able to be inventoried, managed, and orchestrated - to coordinate software updates. - -#. With autoupdate enabled, |CL| is updated daily, however you may wish to - act as an intermediary buffer between the OS releases. If you do decide - to act as a gate to |CL| versions, define a desired release cadence for - yourself which is realistic with the operational expectations of your - environment. - -#. Use a web caching proxy for |CL| updates for devices connected to - a local area network (LAN), like a datacenter, to increase the speed - and resiliency of updates from the |CL| update servers. - - Your caching proxy server is just like any other web application. - |WEB-SERVER-SCALE| - -Option #2: Create your own Linux distribution (mix) ---------------------------------------------------- +Create your own Linux distribution (mix) +---------------------------------------- This approach forks away from the |CL| upstream and has you act as your own :abbr:`OSV (Operating System Vendor)` by leveraging the `mixer process`_ to @@ -267,7 +238,6 @@ Continuously test its use; Automate its use by redeploying |CL| and application on new hosts. This naturally minimizes configuration drift, challenges your monitoring systems, and business continuity plans. -.. _`mixin process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixin .. _`mixer process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixer .. _`downloads page`: https://clearlinux.org/downloads/ .. _`containers page`: https://clearlinux.org/downloads/containers diff --git a/source/clear-linux/guides/guides.rst b/source/clear-linux/guides/guides.rst index 96ec9bd6..d773743d 100644 --- a/source/clear-linux/guides/guides.rst +++ b/source/clear-linux/guides/guides.rst @@ -4,6 +4,7 @@ Guides ###### The following guides provide step-by-step instructions on using |CL|. +Note: As of 22 May 2019 :file:`mixin` is no longer supported. Tooling ======= diff --git a/source/clear-linux/guides/tooling/autospec.rst b/source/clear-linux/guides/tooling/autospec.rst index 864ee77e..0c0d8e42 100644 --- a/source/clear-linux/guides/tooling/autospec.rst +++ b/source/clear-linux/guides/tooling/autospec.rst @@ -327,7 +327,7 @@ Test packaged software After software has been packaged with autospec, the resulting RPMs can be tested for functionality before being integrated and deployed into a |CL| -image with the :ref:`Mixer tool ` or :ref:`Mixin tool `. +image with the :ref:`Mixer tool `. The |CL| development tooling offers two ways to quickly test autospec generated RPMs. @@ -500,7 +500,6 @@ Related topics ************** * :ref:`Mixer tool ` -* :ref:`Mixin tool ` .. _user-setup script: https://github.com/clearlinux/common/blob/master/user-setup.sh .. _`Makefile.common file on GitHub`: https://github.com/clearlinux/common/blob/master/Makefile.common diff --git a/source/clear-linux/guides/tooling/mixer.rst b/source/clear-linux/guides/tooling/mixer.rst index fefafa3e..4aa85479 100644 --- a/source/clear-linux/guides/tooling/mixer.rst +++ b/source/clear-linux/guides/tooling/mixer.rst @@ -829,7 +829,6 @@ Related topics ************** * :ref:`About mixer ` -* :ref:`mixin` * :ref:`autospec-about` * :ref:`bundles-about` * :ref:`swupd-about` diff --git a/source/clear-linux/guides/tooling/mixin.rst b/source/clear-linux/guides/tooling/mixin.rst deleted file mode 100644 index 37e47ef8..00000000 --- a/source/clear-linux/guides/tooling/mixin.rst +++ /dev/null @@ -1,191 +0,0 @@ -.. _mixin: - -mixin -##### - -mixin is a tool provided in the |CL-ATTR| that allows users to add custom -content to their client systems and still receive updates from their upstream OS -vendor. - -.. contents:: - :local: - :depth: 1 - -Description -*********** - -mixin uses the mixer tool to generate a local update for client systems. With -the mixin tool, a user can add remote RPM repositories or local RPMs and mix -them into their update stream, while continuing to get upstream bundles and -updates. The metadata generated from the mixin tool is merged with the upstream -metadata to provide a single source of update content, which swupd uses to -perform updates. - -The mixin tool is included in the :command:`mixer` bundle. - -How to use -********** - -Learn the mixin tool set up and workflow. - -.. contents:: - :local: - :depth: 1 - -Prerequisites -============= - -Install the :command:`mixer` bundle to add the mixin tool. Refer to -`Install a bundle`_ for more details. - -Workflow -======== - -The following steps show how to create and add a custom bundle with the mixin -tool: - -#. Add or create a new repo(s) - - mixin pulls packages to build your custom bundle from locations referred to - as repos. There are two default repos for mixin: - - * upstream - * local - - Additional repos can be added, such as other locations on your local system - or remote repos. - - RPMs must be built specifically for |CL| in order for them to work properly. - Refer to :ref:`autospec` for instruction on creating RPMs for |CL|. - -#. Create a custom bundle with desired RPMs - - Add the desired packages to your new bundle and build the bundle. By default, - the bundle will be named after its parent repo. - - The first time you build the bundle, mixer will create a new OS version by - taking your current upstream |CL| version and multiplying it by 1000. For - example, if your upstream version is 27650, your custom version will be - 27650000. For each subsequent call to mixin, mixer will increment the version - by 10. - - View the `mixin man page`_ for more information on mixin commands. - -#. Update system to make custom bundle available - - Update your system using swupd to make your custom bundle accessible. - - When you first create your mix, you will have to do a one-time migration to - your custom mix as part of the update. After you migrate, the system version - switches over to your last custom version number as noted in the previous - step. As long as you remain on your custom version of |CL| you can continue - to create and add new bundles to your mix with no extra migration step. - -#. Install custom bundles - - Install your custom bundle using the normal swupd :command:`bundle-add` - command. - - View the `swupd man page`_ for more information on swupd commands. - -Examples -******** - -Complete all `Prerequisites`_ before using these examples. - -Example 1: Add custom helloclear bundle -======================================= - -This example shows the basic steps of adding a custom bundle from a local repo. - -#. Check that :command:`helloclear` does not exist on your system: - - .. code-block:: bash - - helloclear - - .. code-block:: console - - helloclear: command not found - -#. Follow the "Build a new RPM" example from :ref:`autospec` to create a new - `helloclear` RPM. - - The resulting RPMs are in `~/clearlinux/packages/helloclear/rpms`. - -#. Create a new repo. - - #. Create a local repo folder and copy the new `helloclear` RPM files into - the repo: - - .. code-block:: bash - - mkdir ~/mixin-repo - cp ~/clearlinux/packages/helloclear/rpms/helloclear-v1.0-1.x86_64.rpm ~/mixin-repo - cp ~/clearlinux/packages/helloclear/rpms/helloclear-bin-v1.0-1.x86_64.rpm ~/mixin-repo - - #. Create the repo data: - - .. code-block:: bash - - cd ~/mixin-repo - createrepo_c . - - #. Add the repo name: - - .. code-block:: bash - - sudo mixin repo add mylocalrepo file://$HOME/mixin-repo/ - -#. Create custom bundle with the new `helloclear` RPM. Add `helloclear` to the - :command:`helloclear-bundle` bundle and build the bundle: - - .. code-block:: bash - - sudo mixin package add helloclear --bundle helloclear-bundle - sudo mixin build - -#. Migrate your |CL| to your custom mix. Check your version before and after the - update to see the switch to your custom mix: - - .. code-block:: bash - - sudo swupd check-update - sudo swupd update --migrate - sudo swupd check-update - -#. Install your custom bundle. Check that the `helloclear-bundle` is now - available and install it to your system: - - .. code-block:: bash - - sudo swupd bundle-list -a | grep helloclear-bundle - sudo swupd bundle-add helloclear-bundle - -#. Test for `helloclear` again to see that it is installed: - - .. code-block:: bash - - helloclear - -#. Revert your system back to upstream (optional). This example reverts back to - upstream version 27650: - - .. code-block:: console - - sudo swupd verify --fix --picky --force -m 27650 -C /usr/share/clear/update-ca/Swupd_Root.pem - sudo swupd clean --all - sudo swupd check-update - -Related topics -************** - -* :ref:`About mixer ` -* :ref:`mixer` -* :ref:`autospec-about` -* :ref:`bundles-about` -* :ref:`swupd-about` - -.. _mixin man page: https://github.com/clearlinux/mixer-tools/blob/master/docs/mixin.1.rst -.. _swupd man page: https://github.com/clearlinux/swupd-client/blob/master/docs/swupd.1.rst -.. _Install a bundle: https://clearlinux.org/documentation/clear-linux/guides/maintenance/swupd-guide#adding-a-bundle \ No newline at end of file From a8943625b1ad017e9c3809b7432fe0ef2d8954ab Mon Sep 17 00:00:00 2001 From: Beth Dean Date: Tue, 28 May 2019 13:59:39 -0700 Subject: [PATCH 3/5] Remove statement about dm-verity (#513) * Remove statement about dm-verity * Add * to first instance of Linux* --- source/clear-linux/concepts/security.rst | 128 +++++++++++------------ 1 file changed, 62 insertions(+), 66 deletions(-) diff --git a/source/clear-linux/concepts/security.rst b/source/clear-linux/concepts/security.rst index ee744db8..7c4b3d50 100644 --- a/source/clear-linux/concepts/security.rst +++ b/source/clear-linux/concepts/security.rst @@ -1,10 +1,10 @@ .. _security: -OS 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 +that are both performant and practical. This security philosophy is rooted within the project's codebase and operating culture. @@ -16,21 +16,21 @@ within the project's codebase and operating culture. Security in Updates =================== -The |CL| team believes in the benefits of -software security through open sourcing, incremental updates, and +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. +|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 ---------------------------- @@ -38,43 +38,43 @@ 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|. +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. +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 -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 +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 see +In |CL| updates are delivered automatically, efficiently, +and effectively. For more information see `documentation about Software Updates`_ in |CL|. - + 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 +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 -patches are deployed as soon as they are available. +Packages are automatically scanned against +:abbr:`CVEs (Common Vulnerabilities and Exposures)` daily, and security +patches are deployed as soon as they are available. -These combined practices minimize the amount of +These combined practices minimize the amount of time |CL| systems are exposed to unnecessary security risk. - + @@ -86,18 +86,18 @@ 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: +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 - avoid their accidental usage. +* `RC4`, `SSLv3`, `3DES`, and `SHA-1` ciphers which have had known + vulnerabilities, have been explicitly disabled within many |CL| packages to + avoid their accidental usage. -* Services and subsystems which expose sensitive system information +* 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 @@ -105,65 +105,62 @@ Verified trust |CL| encourages the use of secure practices such as encryption and digital signature verification throughout the system and discourages blind -trust. Below are some examples: +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`_ +* 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`_ -* Before being built, packages available from |CL| verify checksums and +* 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 - system-wide chains of trust, instead of ignoring foreign certificates. +* |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 + 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 + +* Kernels shipped with |CL| are signed and disallow the usage of custom kernel modules to maintain verifiable system integrity. -* `Address space layout randomization (ASLR)`_ and +* `Address space layout randomization (ASLR)`_ and `Kernel address space layout randomization (KASLR)`_ are kernel features - which defend against certain memory based attacks. + which defend against certain memory based attacks. More information can be found in a `blog post about PIE executables`_ . -* `dm-verity`_ is a kernel mechanism readily available in |CL| - which verifies integrity of the devices being written to, like hard disks, - to help ensure they have not been tampered with. - + Security in System Design ========================= -Simple, yet effective, techniques are used throughout the +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: +good security hygiene. Below are some examples: -* Full disk encryption using `Linux Unified Key Setup`_ (LUKS) is available +* Full disk encryption using `Linux Unified Key Setup`_ (LUKS) is available during installation. * |CL| uses the PAM cracklib module to harden user login and password - security resulting in: + security resulting in: - - No default username or root password set out of the box with + - No default username or root password set out of the box with |CL|, you will be asked to set your own password immediately. - Simple password schemes, which are known to be easily compromised, @@ -172,9 +169,9 @@ good security hygiene. Below are some examples: - A password blacklist, to avoid system passwords being set to passwords which have been compromised in the past. -* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH - login patterns, is installed with the :command:`openssh-server` bundle. - +* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH + login patterns, is installed with the :command:`openssh-server` bundle. + @@ -190,7 +187,7 @@ good security hygiene. Below are some examples: .. _`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 +.. _`blog post about PIE executables`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements .. _`Tallow`: https://github.com/clearlinux/tallow .. |NVD| raw:: html @@ -200,4 +197,3 @@ good security hygiene. Below are some examples: .. |MITRE| raw:: html https://cve.mitre.org/ - From ea0915365b46a265df30c38eb8cc6d127dba23c0 Mon Sep 17 00:00:00 2001 From: Kevin Putnam Date: Wed, 29 May 2019 17:44:54 -0400 Subject: [PATCH 4/5] Fixed header underline in security.rst that was causing build error. (#515) Signed-off-by: Kevin Putnam --- source/clear-linux/concepts/security.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/clear-linux/concepts/security.rst b/source/clear-linux/concepts/security.rst index 7c4b3d50..418b75f4 100644 --- a/source/clear-linux/concepts/security.rst +++ b/source/clear-linux/concepts/security.rst @@ -23,7 +23,7 @@ rapidly resolving known security advisories. 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, From 3d6e624aa533b216304d473b1b69584c879e2b6b Mon Sep 17 00:00:00 2001 From: puneetse <22071208+puneetse@users.noreply.github.com> Date: Wed, 29 May 2019 14:55:54 -0700 Subject: [PATCH 5/5] Fix license in autospec example. (#511) * Fix license in autospec example. The correct identifier for the Intel Open Source license is just "Intel" not "Intel Corporation" * Revert back to MIT license * Add link to SPDX license list * Specify opae-sdk example licenses. * Elaborate on why multiple licenses in the opae-sdk example --- source/clear-linux/guides/tooling/autospec.rst | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/source/clear-linux/guides/tooling/autospec.rst b/source/clear-linux/guides/tooling/autospec.rst index 0c0d8e42..3779e52c 100644 --- a/source/clear-linux/guides/tooling/autospec.rst +++ b/source/clear-linux/guides/tooling/autospec.rst @@ -238,11 +238,14 @@ and dependencies in order for autospec to complete a successful build. cd packages/opae-sdk -#. Add a license: +#. Add one or more valid license identifier from the + `SPDX License List `_. + In the example below, two different licenses are appropriate based on the + opae-sdk project licensing: .. code-block:: bash - echo "Intel Corporation" > opae-sdk.license + echo "BSD-3-Clause MIT" > opae-sdk.license #. Run autospec again: