DOCSLIB.ORG

Guide to the Secure Configuration of Red Hat Enterprise Linux 5

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Revision 4.2 August 26, 2011 Operating Systems Division Unix Team of the Systems and Network Analysis Center National Security Agency 9800 Savage Rd. Suite 6704 Ft. Meade, MD 20755-6704 2 Warnings Do not attempt to implement any of the recommendations in this guide without first testing in a non- production environment. This document is only a guide containing recommended security settings. It is not meant to replace well- structured policy or sound judgment. Furthermore this guide does not address site-specific configuration concerns. Care must be taken when implementing this guide to address local operational and policy concerns. The security changes described in this document apply only to Red Hat Enterprise Linux 5. They may not translate gracefully to other operating systems. Internet addresses referenced were valid as of 1 Dec 2009. Trademark Information Red Hat is a registered trademark of Red Hat, Inc. Any other trademarks referenced herein are the property of their respective owners. Change Log Revision 4.2 is an update of Revision 4.1 dated February 28, 2011. Added section 2.5.3.1.3, Disable Functionality of IPv6 Kernel Module Through Option. Added discussion to section 2.5.3.1.1, Disable Automatic Loading of IPv6 Kernel Module, indicating that this is no longer the preferred method for disabling IPv6. Added section 2.3.1.9, Set Accounts to Disable After Password Expiration. Revision 4.1 is an update of Revision 4 dated September 14, 2010. Added section 2.2.2.6, Disable All GNOME Thumbnailers if Possible. Added Common Configuration Enumeration (CCE) identifiers to associated sections within the guide, and a note about CCE in section 1.2.4, Formatting Conventions. Updated section 2.3.3.2, Set Lockouts for Failed Password Attempts. There is no longer the need to add the pam tally2 module into each program's PAM configuration file, or to comment out some lines from /etc/pam.d/system-auth. The pam tally2 module can now be referenced directly from /etc/pam.d/ system-auth. Corrected section 2.6.2.4.5 title from Ensure auditd Collects Logon and Logout Events to Record Attempts to Alter Logon and Logout Event Information. Corrected section 2.6.2.4.6 title from Ensure auditd Collects Process and Session Initiation Information to Record Attempts to Alter Process and Session Initiation Information Note: The above changes did not affect any of the existing section numbering. TABLE OF CONTENTS 3 Table of Contents 1 Introduction 13 1.1 General Principles............................................ 13 1.1.1 Encrypt Transmitted Data Whenever Possible........................ 13 1.1.2 Minimize Software to Minimize Vulnerability......................... 13 1.1.3 Run Different Network Services on Separate Systems..................... 13 1.1.4 Configure Security Tools to Improve System Robustness................... 14 1.1.5 Least Privilege.......................................... 14 1.2 How to Use This Guide......................................... 14 1.2.1 Read Sections Completely and in Order............................ 14 1.2.2 Test in Non-Production Environment............................. 14 1.2.3 Root Shell Environment Assumed............................... 14 1.2.4 Formatting Conventions..................................... 15 1.2.5 Reboot Required......................................... 15 2 System-wide Configuration 17 2.1 Installing and Maintaining Software.................................. 17 2.1.1 Initial Installation Recommendations.............................. 17 2.1.1.1 Disk Partitioning.................................... 17 2.1.1.2 Boot Loader Configuration.............................. 18 2.1.1.3 Network Devices.................................... 19 2.1.1.4 Root Password..................................... 19 2.1.1.5 Software Packages................................... 19 2.1.1.6 First-boot Configuration............................... 19 2.1.2 Updating Software........................................ 20 2.1.2.1 Configure Connection to the RHN RPM Repositories............... 20 2.1.2.2 Disable the rhnsd Daemon.............................. 21 2.1.2.3 Obtain Software Package Updates with yum ..................... 21 2.1.3 Software Integrity Checking................................... 22 2.1.3.1 Configure AIDE.................................... 23 2.1.3.2 Verify Package Integrity Using RPM......................... 24 2.2 File Permissions and Masks....................................... 25 2.2.1 Restrict Partition Mount Options................................ 25 2.2.1.1 Add nodev Option to Non-Root Local Partitions.................. 25 2.2.1.2 Add nodev, nosuid, and noexec Options to Removable Storage Partitions... 26 2.2.1.3 Add nodev, nosuid, and noexec Options to Temporary Storage Partitions... 26 2.2.1.4 Bind-mount /var/tmp to /tmp ............................ 26 2.2.2 Restrict Dynamic Mounting and Unmounting of Filesystems................ 27 2.2.2.1 Restrict Console Device Access............................ 27 2.2.2.2 Disable USB Device Support............................. 27 4 TABLE OF CONTENTS 2.2.2.3 Disable the Automounter if Possible......................... 28 2.2.2.4 Disable GNOME Automounting if Possible..................... 29 2.2.2.5 Disable Mounting of Uncommon Filesystem Types................. 29 2.2.2.6 Disable All GNOME Thumbnailers if Possible................... 30 2.2.3 Verify Permissions on Important Files and Directories.................... 30 2.2.3.1 Verify Permissions on passwd, shadow, group and gshadow Files......... 30 2.2.3.2 Verify that All World-Writable Directories Have Sticky Bits Set......... 31 2.2.3.3 Find Unauthorized World-Writable Files...................... 31 2.2.3.4 Find Unauthorized SUID/SGID System Executables................ 31 2.2.3.5 Find and Repair Unowned Files........................... 33 2.2.3.6 Verify that All World-Writable Directories Have Proper Ownership....... 33 2.2.4 Restrict Programs from Dangerous Execution Patterns.................... 33 2.2.4.1 Set Daemon umask ................................... 33 2.2.4.2 Disable Core Dumps.................................. 34 2.2.4.3 Enable ExecShield................................... 35 2.2.4.4 Enable Execute Disable (XD) or No Execute (NX) Support on 32-bit x86 Systems 35 2.2.4.5 Configure Prelink................................... 36 2.3 Account and Access Control....................................... 37 2.3.1 Protect Accounts by Restricting Password-Based Login................... 37 2.3.1.1 Restrict Root Logins to System Console....................... 37 2.3.1.2 Limit su Access to the Root Account........................ 38 2.3.1.3 Configure sudo to Improve Auditing of Root Access................ 39 2.3.1.4 Block Shell and Login Access for Non-Root System Accounts........... 39 2.3.1.5 Verify Proper Storage and Existence of Password Hashes............. 40 2.3.1.6 Verify that No Non-Root Accounts Have UID 0.................. 40 2.3.1.7 Set Password Expiration Parameters......................... 41 2.3.1.8 Remove Legacy '+' Entries from Password Files.................. 42 2.3.1.9 Set Accounts to Disable After Password Expiration................ 42 2.3.2 Use Unix Groups to Enhance Security............................. 42 2.3.2.1 Create a Unique Default Group for Each User................... 42 2.3.2.2 Create and Maintain a Group Containing All Human Users............ 43 2.3.3 Protect Accounts by Configuring PAM............................. 43 2.3.3.1 Set Password Quality Requirements......................... 44 2.3.3.2 Set Lockouts for Failed Password Attempts..................... 45 2.3.3.3 Use pam deny.so to Quickly Deny Access to a Service............... 45 2.3.3.4 Restrict Execution of userhelper to Console Users................ 46 2.3.3.5 Upgrade Password Hashing Algorithm to SHA-512................. 46 2.3.3.6 Limit Password Reuse................................. 47 2.3.3.7 Remove the pam ccreds Package if Possible..................... 47 2.3.4 Secure Session Configuration Files for Login Accounts.................... 47 2.3.4.1 Ensure that No Dangerous Directories Exist in Root's Path............ 47 2.3.4.2 Ensure that User Home Directories are not Group-Writable or World-Readable. 48 2.3.4.3 Ensure that User Dot-Files are not World-writable................. 49 2.3.4.4 Ensure that Users Have Sensible Umask Values................... 49 2.3.4.5 Ensure that Users do not Have .netrc Files.................... 50 2.3.5 Protect Physical Console Access................................ 50 2.3.5.1 Set BIOS Password.................................. 50 2.3.5.2 Set Boot Loader Password.............................. 50 2.3.5.3 Require Authentication for Single-User Mode.................... 51 2.3.5.4 Disable Interactive Boot................................ 51 2.3.5.5 Implement Inactivity Time-out for Login Shells................... 51 2.3.5.6 Configure Screen Locking............................... 52 TABLE OF CONTENTS 5 2.3.5.7 Disable Unnecessary Ports.............................. 53 2.3.6 Use a Centralized Authentication Service........................... 54 2.3.7 Warning Banners for System Accesses............................. 54 2.3.7.1 Modify the System Login Banner.......................... 54 2.3.7.2 Implement a GUI Warning Banner.......................... 55 2.4 SELinux.................................................. 55 2.4.1 How SELinux Works....................................... 56 2.4.2 Enable SELinux......................................... 56 2.4.2.1
Load more

Recommended publications
  • Address Space Layout Permutation (ASLP): Towards Fine-Grained Randomization of Commodity Software
    Address Space Layout Permutation (ASLP): Towards Fine-Grained Randomization of Commodity Software Chongkyung Kil,∗ Jinsuk Jun,∗ Christopher Bookholt,∗ Jun Xu,† Peng Ning∗ Department of Computer Science∗ Google, Inc.† North Carolina State University {ckil, jjun2, cgbookho, pning}@ncsu.edu [email protected] Abstract a memory corruption attack), an attacker attempts to alter program memory with the goal of causing that program to Address space randomization is an emerging and behave in a malicious way. The result of a successful at- promising method for stopping a broad range of memory tack ranges from system instability to execution of arbitrary corruption attacks. By randomly shifting critical memory code. A quick survey of US-CERT Cyber Security Alerts regions at process initialization time, address space ran- between mid-2005 and 2004 shows that at least 56% of the domization converts an otherwise successful malicious at- attacks have a memory corruption component [24]. tack into a benign process crash. However, existing ap- Memory corruption vulnerabilities are typically caused proaches either introduce insufficient randomness, or re- by the lack of input validation in the C programming lan- quire source code modification. While insufficient random- guage, with which the programmers are offered the free- ness allows successful brute-force attacks, as shown in re- dom to decide when and how to handle inputs. This flex- cent studies, the required source code modification prevents ibility often results in improved application performance. this effective method from being used for commodity soft- However, the number of vulnerabilities caused by failures ware, which is the major source of exploited vulnerabilities of input validation indicates that programming errors of this on the Internet.
    [Show full text]
  • Security Enhancements in Red Hat Enterprise Linux (Beside Selinux)
    Security Enhancements in Red Hat Enterprise Linux (beside SELinux) Ulrich Drepper Red Hat, Inc. [email protected] December 9, 2005 Abstract Bugs in programs are unavoidable. Programs developed using C and C++ are especially in danger. If bugs cannot be avoided the next best thing is to limit the damage. This article will show improvements in Red Hat Enterprise Linux which achieve just that. 1 Introduction These problems are harder to protect against since nor- mally2 all of the OS’s functionality is available and the Security problems are one of the biggest concerns in the attacker might even be able to use self-compiled code. industry today. Providing services on networked comput- ers which are accessible through the intranet and/or Inter- Remotely exploitable problems are more serious since net potentially to untrusted individuals puts the installa- the attacker can be anywhere if the machine is available tion at risk. A number of changes have been made to the through the Internet. On the plus side, only applications Linux OS1 which help a lot to mitigate the risks. Up- accessible through the network services provided by the coming Red Hat Enterprise Linux versions will feature machine can be exploited, which limits the range of ex- the SELinux extensions, originally developed by the Na- ploits. Further limitations are the attack vectors. Usually tional Security Agency (NSA), with whom Red Hat now remote attackers can influence applications only by pro- collaborates to productize the developed code. SELinux viding specially designed input. This often means cre- means a major change in Linux and is a completely sep- ating buffer overflows, i.e., situations where the data is arate topic by itself.
    [Show full text]
  • Version 7.8-Systemd
    Linux From Scratch Version 7.8-systemd Created by Gerard Beekmans Edited by Douglas R. Reno Linux From Scratch: Version 7.8-systemd by Created by Gerard Beekmans and Edited by Douglas R. Reno Copyright © 1999-2015 Gerard Beekmans Copyright © 1999-2015, Gerard Beekmans All rights reserved. This book is licensed under a Creative Commons License. Computer instructions may be extracted from the book under the MIT License. Linux® is a registered trademark of Linus Torvalds. Linux From Scratch - Version 7.8-systemd Table of Contents Preface .......................................................................................................................................................................... vii i. Foreword ............................................................................................................................................................. vii ii. Audience ............................................................................................................................................................ vii iii. LFS Target Architectures ................................................................................................................................ viii iv. LFS and Standards ............................................................................................................................................ ix v. Rationale for Packages in the Book .................................................................................................................... x vi. Prerequisites
    [Show full text]
  • Pluggable Authentication Modules
    Who this book is written for This book is for experienced system administrators and developers working with multiple Linux/UNIX servers or with both UNIX and Pluggable Authentication Windows servers. It assumes a good level of admin knowledge, and that developers are competent in C development on UNIX-based systems. Pluggable Authentication Modules PAM (Pluggable Authentication Modules) is a modular and flexible authentication management layer that sits between Linux applications and the native underlying authentication system. The PAM framework is widely used by most Linux distributions for authentication purposes. Modules Originating from Solaris 2.6 ten years ago, PAM is used today by most proprietary and free UNIX operating systems including GNU/Linux, FreeBSD, and Solaris, following both the design concept and the practical details. PAM is thus a unifying technology for authentication mechanisms in UNIX. This book provides a practical approach to UNIX/Linux authentication. The design principles are thoroughly explained, then illustrated through the examination of popular modules. It is intended as a one-stop introduction and reference to PAM. What you will learn from this book From Technologies to Solutions • Install, compile, and configure Linux-PAM on your system • Download and compile third-party modules • Understand the PAM framework and how it works • Learn to work with PAM’s management groups and control fl ags • Test and debug your PAM confi guration Pluggable Authentication Modules • Install and configure the pamtester utility
    [Show full text]
  • Telecom Sud Paris
    Sécurité des OS et des systèmes Telecom Sud Paris Aurélien Wailly, Emmanuel Gras Amazon Dublin ANSSI Paris 2 Juin 2017 Présentation des intervenants Emmanuel Gras I Agence nationale de la sécurité des systèmes d’information depuis trop longtemps I Bureau inspections en SSI I http://pro.emmanuelgras.com I [email protected] Aurélien Wailly I Amazon depuis 2 ans I Thèse : End-to-end Security Architecture and Self-Protection Mechanisms for Cloud Computing Environments I Sécurité OS, reverse-engineering, réponse à incidents I http://aurelien.wail.ly I [email protected] A. Wailly, E. Gras (Amazon / ANSSI) Sécurité des OS et des systèmes 2 Juin 2017 2 / 259 Sécurité des sysèmes et des OS Objectifs I Fonctionnement des OS modernes, notamment du point de vue de la sécurité I Failles, exploitation, compromission I Dans le domaine de la sécurité, il est indispensable de comprendre comment marche un système pour l’exploiter Cibles I Linux, les principes restent valables pour les UNIX I Windows A. Wailly, E. Gras (Amazon / ANSSI) Sécurité des OS et des systèmes 2 Juin 2017 3 / 259 Plan 1 Introduction 2 OS, CPU et sécurité 3 Mémoire, segmentation et pagination (et sécurité !) 4 Sécurité des utilisateurs - UNIX 5 Sécurité des utilisateurs - Windows 6 Analyse de binaires - Concepts et outils 7 Failles applicatives 8 Protection des OS A. Wailly, E. Gras (Amazon / ANSSI) Sécurité des OS et des systèmes 2 Juin 2017 4 / 259 Votre OS ? www.dilbert.com/ A. Wailly, E. Gras (Amazon / ANSSI) Sécurité des OS et des systèmes 2 Juin 2017 5 / 259 Ce qui ne sera pas abordé La sécurité est un sujet vaste ! Réseau Virus et malwares Techniques logicielles avancées I Shellcoding poussé I Protection logicielle Exploitation Web I Cross Site Scripting I Injections SQL A.
    [Show full text]
  • Linux-Professional-Institute-LPI-303
    LPIC-3: Linux Enterprise Professional Certification LPIC-3 303: Security LPIC-3 is a professional certification program program that covers enterprise Linux specialties. LPIC-3 303 covers administering Linux enterprise-wide with an emphasis on Security. To become LPIC-3 certified, a candidate with an active LPIC-1 and LPIC-2 certification must pass at least one of the following specialty exams. Upon successful completion of the requirements, they will be entitled to the specialty designation: LPIC-3 Specialty Name. For example, LPIC-3 Virtualization & High Availability. Specialties: • 300: Mixed Environment • 303: Security • 304: Virtualization and High Availability TOPIC 325: CRYPTOGRAPHY • Configure Apache HTTPD with mod_ssl to that performs DNSSEC validation on behalf of 325.1 X.509 Certificates and Public Key provide HTTPS service, including SNI and its clients Infrastructures (5) HSTS • Key Signing Key, Zone Signing Key, Key Tag Candidates should understand X.509 certificates • Configure Apache HTTPD with mod_ssl to • Key generation, key storage, key management and public key infrastructures. They should know authenticate users using certificates and key rollover how to configure and use OpenSSL to implement • Configure Apache HTTPD with mod_ssl to • Maintenance and re-signing of zones certification authorities and issue SSL certificates provide OCSP stapling • Use DANE to publish X.509 certificate for various purposes. • Use OpenSSL for SSL/TLS client and server information in DNS Key knowledge areas: tests • Use TSIG for secure communication with BIND • Understand X.509 certificates, X.509 certificate 325.3 Encrypted File Systems (3) TOPIC 326: HOST SECURITY lifecycle, X.509 certificate fields and X.509v3 Candidates should be able to setup and 326.1 Host Hardening (3) certificate extensions configure encrypted file systems.
    [Show full text]
  • Security Guide
    Fedora 19 Security Guide A Guide to Securing Fedora Linux Johnray Fuller John Ha David O'Brien Scott Radvan Eric Christensen Adam Ligas Murray McAllister Scott Radvan Daniel Walsh Security Guide Dominick Grift Eric Paris James Morris Fedora 19 Security Guide A Guide to Securing Fedora Linux Edition 19.1 Author Johnray Fuller [email protected] Author John Ha [email protected] Author David O'Brien [email protected] Author Scott Radvan [email protected] Author Eric Christensen [email protected] Author Adam Ligas [email protected] Author Murray McAllister [email protected] Author Scott Radvan [email protected] Author Daniel Walsh [email protected] Author Dominick Grift [email protected] Author Eric Paris [email protected] Author James Morris [email protected] Copyright © 2007-2013 Fedora Project Contributors. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
    [Show full text]
  • 6.2 Release Notes
    Red Hat Enterprise Linux 6 6.2 Release Notes Release Notes for Red Hat Enterprise Linux 6.2 Edition 2 Last Updated: 2017-10-24 Red Hat Enterprise Linux 6 6.2 Release Notes Release Notes for Red Hat Enterprise Linux 6.2 Edition 2 Red Hat Engineering Content Services Legal Notice Copyright © 2011 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • New Security Enhancements in Red Hat Enterprise Linux V.3, Update 3
    New Security Enhancements in Red Hat Enterprise Linux v.3, update 3 By Arjan van de Ven Abstract This whitepaper describes the new security features that have been added to update 3 of Red Hat Enterprise Linux v.3: ExecShield and support for NX technology. August 2004 Table of Contents Introduction 2 Types of Security Holes 2 Buffer Overflows 3 Countering Buffer Overflows 4 Randomization 6 Remaining Randomization: PIE Binaries 7 Compatibility 8 How Well Does it Work? 9 Future Work 10 ¢¡¤£¦¥¨§ © ¤ ¦ ¨¢ ¨ ! ¨! "¨ $#!© ¨%¦&¨¦ ¨! ¤' ¨¡(*)+¤-, ¡ ¡¤.!+ !£§ ¡¤%/ 01, © 02 ".§ + § ¨.)+.§ 3¦01¡.§4§ .© 02 .§ + § ¨.)+.§ 3¦01¡54¢! . !! !© 6¢'7.!"¡ .§.8¡.%¨¦ § © ¨0 #© %8&9© 0:§ ¨ ¨© 02 .§ ¨+ § ¨.)+¤§ 3;¡!54#!© %!0;<=¡.§ >!¨, ¨0 ¦?@BA$¨C.6B'ED8F ! Introduction The world of computer security has changed dramatically in the last few years. Network security used to be about one dedicated hacker trying to get into one government computer, but now it is often about automated mass attacks. The SQL Slammer and Code Red worms were the first wide-scale computer security incidents to get mainstream press coverage. Linux has had similar, less-invasive worms in the past, such as the Slapper worm of 2002. Another relatively new phenomenon is that compromised computers are primarily being used for other purposes, including sending spam or participating in Distributed Denial of Service (DDOS) attacks. A contributing factor to the mass-compromise problem is that a large portion1 of users and system administrators generally do not apply the security fixes that are provided by the operating system vendor. This leaves a significant number of vulnerable machines connected to the Internet at all times. Providing security updates after the fact, however, is not sufficient.
    [Show full text]
  • A Study of Gaps in Attack Analysis 5B
    This report is the result of studies performed at Lincoln Laboratory, a federally funded research and development center operated by Massachusetts Institute of Technology. This material is based on work supported by the Department of Defense under Air Force Contract No. FA8721-05-C-0002 and/or FA8702-15-D-0001. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the Department of Defense. © 2016 MASSACHUSETTS INSTITUTE OF TECHNOLOGY Delivered to the U.S. Government with Unlimited Rights, as defined in DFARS Part 252.227-7013 or 7014 (Feb 2014). Notwithstanding any copyright notice, U.S. Government rights in this work are defined by DFARS 252.227-7013 or DFARS 252.227-7014 as detailed above. Use of this work other than as specifically authorized by the U.S. Government may violate any copyrights that exist in this work. This page intentionally left blank. EXECUTIVE SUMMARY The ability of the defender to detect and identify cyber attacks reflects the \arms race" na- ture of the cyber domain. While defenders develop new and improved techniques to detect known attacks, attackers resort to more sophisticated and stealthy techniques to perform their intrusions and evade detection. In this study, we identify the major gaps that exist in today's attack detection systems and infrastructures that impede more efficient and effective attack analysis. Attack anal- ysis in this study refers to activities related to identification and understanding of attack methods and techniques, the capability to detect such attacks in USG, DoD, and general enterprise systems, the ability to attribute such attacks to adversaries, and the ability to predict them before they happen.
    [Show full text]
  • SUSE Linux Enterprise Server 15 SP2 Security and Hardening Guide Security and Hardening Guide SUSE Linux Enterprise Server 15 SP2
    SUSE Linux Enterprise Server 15 SP2 Security and Hardening Guide Security and Hardening Guide SUSE Linux Enterprise Server 15 SP2 Introduces basic concepts of system security, covering both local and network security aspects. Shows how to use the product inherent security software like AppArmor, SELinux, or the auditing system that reliably collects information about any security-relevant events. Supports the administrator with security-related choices and decisions in installing and setting up a secure SUSE Linux Enterprise Server and additional processes to further secure and harden that installation. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its
    [Show full text]
  • Enabling Address Space Layout Randomization for SGX Programs
    SGX-Shield: Enabling Address Space Layout Randomization for SGX Programs Jaebaek Seo∗x , Byounyoung Leeyx, Seongmin Kim∗, Ming-Wei Shihz, Insik Shin∗, Dongsu Han∗, Taesoo Kimz ∗KAIST yPurdue University zGeorgia Institute of Technology {jaebaek, dallas1004, ishin, dongsu_han}@kaist.ac.kr, [email protected], {mingwei.shih, taesoo}@gatech.edu Abstract—Traditional execution environments deploy Address system and hypervisor. It also offers hardware-based measure- Space Layout Randomization (ASLR) to defend against memory ment, attestation, and enclave page access control to verify the corruption attacks. However, Intel Software Guard Extension integrity of its application code. (SGX), a new trusted execution environment designed to serve security-critical applications on the cloud, lacks such an effective, Unfortunately, we observe that two properties, namely, well-studied feature. In fact, we find that applying ASLR to SGX confidentiality and integrity, do not guarantee the actual programs raises non-trivial issues beyond simple engineering for security of SGX programs, especially when traditional memory a number of reasons: 1) SGX is designed to defeat a stronger corruption vulnerabilities, such as buffer overflow, exist inside adversary than the traditional model, which requires the address space layout to be hidden from the kernel; 2) the limited memory SGX programs. Worse yet, many existing SGX-based systems uses in SGX programs present a new challenge in providing a tend to have a large code base: an entire operating system as sufficient degree of entropy; 3) remote attestation conflicts with library in Haven [12] and a default runtime library in SDKs the dynamic relocation required for ASLR; and 4) the SGX for Intel SGX [28, 29].
    [Show full text]